@Prof Braino,
Thanks, but no thanks. You don't seem to comprehend what I have written.
I have been testing an SX28 coded in SX/B via a USB interface to Minicom.
Emit 2 or Emit 3 are nothing that Minicom or SX/B will comprehend. Minicom does convert a Cntl-B to a <stx> and a Cntl-C to a <etx>. Then the SX28 does indeed see these and respond with some sort of behavior.
Besides... Emit 2 with send an ASCII character 2, not 0000_0010. This is not useful. That is actually a binary equivalent of decimal 50. You are off into the weeds.
I say some sort of behavior as the printer cartridge does appear defective. There are on-board diagnoistic LEDs to verify the board is working and I am getting them to light. So it seems the electronics is good to go, but I may not get a printer cartridge in time for the the contest deadline.
No need to worry. Peter and TachyonForth have his December 4th contest deadline, so I will continue to try. I am learning quite a bit. Project goals do help, rather than dealing in the abstract with what a language has or doesn't have.
~~~~~~~~~~~~~~~~~~~~~
In order for this project to go forward, I have had to verify the Serial Inkjet Printer Board is operational. I have yet to get any interface with a Forth platform established as it seems that all the Forths on Propeller just provide an RS232 port for console communication.
The only instances of using that RS232 port for other purposes seem to require actually removing wiring and plugging in something else. Not a particularly useful solution. Parallax generally has software support multiple RS232 connections as a communications hub, Forth seems to have not gotten that far.
I am near confirming the Serial Inkjet Printer Board is completely operational via direct RS232 with only that board. But I will at the very least have to redirect Pin 31 and Pin 30 TX/RX to another pin to handshake and then send data to the Serial Inkjet Printer Board. The single, by-directional RS232 is a bit of a challenge as each time I send something, the board confirms it is ready for more with a prompt character. So I need both directions on one Propeller I/O pin with full 9600 8n1 support.
To do so, I am digging in the .spin and .f source code for the Serial i/o.
It would seem that I have to change the baud rate to 9600 8n1 and back again, change the i/o pins and back again. At least that currently seems the easier path.
The other alternative is to set up another parallel serial i/o structure, maybe in another cog. That would be ideal... maybe a new long-term goal for Forths on the Propeller.
@Prof Braino,
Besides... Emit 2 with send an ASCII character 2, not 0000_0010. This is not useful. That is actually a binary equivalent of decimal 50. You are off into the weeds.
I am sorry Loopy, but you are wrong. 2 EMIT emits a binary two and "2" EMIT emits an ASCII two.
Speaking of Projects. I was working on mine and needed TF code for a rotary Encoder. I had several Grayhill 2 bit encoders on hand (Parallax p/n 27805) and wired one up. 20 minutes later I had the code written, an hour later I ripped out the 5-6 lines of code to determine direction and started again from scratch, 20 minutes later it was working.
I thought I would post the code in case any Thanksgiving Challengers have a use for it. The code seems solid, but I am sure one of our gurus could shave a few words off.
I am sorry Loopy, but you are wrong. 2 EMIT emits a binary two and "2" EMIT emits an ASCII two.
"2" is a shortform that Tachyon uses but AFAIK PF doesn't support smart numbers beyond the simple hdb prefixes.
$32 EMIT will print the digit 2 on a terminal. The equivalents for this are "2" or #50 or 50d or 32h or even %%00110010 as well as 00110010b
Speaking of Projects. I was working on mine and needed TF code for a rotary Encoder. I had several Grayhill 2 bit encoders on hand (Parallax p/n 27805) and wired one up. 20 minutes later I had the code written, an hour later I ripped out the 5-6 lines of code to determine direction and started again from scratch, 20 minutes later it was working.
I thought I would post the code in case any Thanksgiving Challengers have a use for it. The code seems solid, but I am sure one of our gurus could shave a few words off.
.... enjoy
Hi Brian,
Hopefully you have this encoder tied in as part of your project!
Don't forget you can use the Spin-like syntax as well for variables. Instead of:
VARIABLE oldBits
VARIABLE newBits
VARIABLE counter
You can write:
LONG oldBits,newBits,counter
Also these sequences can be optimized:
newBits @ 1 AND can be reduced to 0 newBits SET?
oldBits @ 1 SHR can be reduced to oldBits @ 2/
counter @ + counter ! can be reduced to counter +!
I also see the sequence IN@ A0 SHR 3 AND could do with a nice input instruction that I could add to the Tachyon VM that would take a mask, read those bits, and right justify it.
I am sorry Loopy, but you are wrong. 2 EMIT emits a binary two and "2" EMIT emits an ASCII two.
Thanks. That is extremely helpful..... a typical beginner's error. And I do understand that the quotations will only work in Tachyon, not PF.
I am still stuck as it seems the serial driver is only a full duplex that requires separate Tx and Rx pins.
I am using a Parallax product that requires what I believe is a half-duplex RS232 that can listen for a prompt and only then transmit. This is easy to do with a BasicStamp or with a conventional .spin object. But it seems that Forth has just presumed all RS232 with be full-duplex and PropForth seems to presume only 8n1 configuration.
Thanks. That is extremely helpful..... a typical beginner's error.
I am still stuck as it seems the serial driver is only a full duplex that requires separate Tx and Rx pins.
I am using a Parallax product that requires what I believe is a half-duplex RS232 that can listen for a prompt and only then transmit. This is easy to do with a BasicStamp or with a conventional .spin object. But it seems that Forth has just presumed all RS232 with be full-duplex and PropForth seems to presume only 8n1 configuration.
PBASIC Style serial I/O in Tachyon in built into the EXTEND.fth words:
[FONT=courier new]( *** PBASIC STYLE SERIAL I/O *** )
\ Set the baudrate for SEROUT and SERIN
\ baudcnt is a task register so each cog can have it's own baudrate (if used)
pub SERBAUD ( baud -- )
CLKFREQ SWAP / baudcnt !
;
\ Bit-bashed Serial output - transmit asynchronous data
\ Fixed start bit timing
\ Code size: 18 bytes
\ Tested to 250K baud
pub SEROUT ( data pin -- )
MASK DUP OUTSET SWAP \ ensure pin is an output (very first time perhaps)
2* \ Include start bit (0)
baudcnt @ DELTA \ setup delay and wait
9 FOR WAITCNT SHROUT NEXT \ data bits
DROP WAITCNT OUTSET \ final stop bit
;
\ Bit-bashed Serial input - receive asynchronous data
pub SERIN ( pin -- data )
MASK DUP INPUTS DUP
baudcnt @ 2/ SWAP WAITPNE DELTA
baudcnt @ DELTA \ delay to sample 1 bit later in 1st data bit
0 #8 FOR SHRINP WAITCNT NEXT
NIP #24 SHR \ right justify 8-bit data
;[/FONT]
Thanks to Peter I was able to shave a few more words off and add some additional functionality. We have a dial capability to 'dial in' parameter settings on my project, but one needs to know where on the dial so-to-speak one is located. So I added a serial LCD and redirected the console output to it, thus making .NUM, .BYTE, etc available for formatted display.
Here is a pic and the code. I am using TF v2.1 - 121114.1330 and EXTEND 121113.1200.
Progress Report.
PropForth doesn't support half-duplex bi-directional serial or at least there is nothing that clearly shows that it does. There is only serial and _serial words with machine code attached to them. I've been told that I should write the code myself, but that isn't exactly a weekend project for me.
Since my Chopstick printer requires half-duplex bi-directional serial, I am pretty much at an impasse in PropForth. Go good luck to all of you and may the best project win.
We still have the Dec 4 competition and Tachyon may just support my hardware.
Keep plugging away! So far, you are the only two projects I've seen any progress reports on. I know I'm out of the running on this one. Maybe there are some folks holding off their "reveal" until the packaging is done and the marketing plan is in place......
Remember, tomorrow is probably the last day....unless I get distracted and don't start judging until Monday!!
One more CARE package to share with the Thanksgiving Challenge-critters ... then off to put it together into something presentable, coherent, functional, and, most of all, useful!
Since I delivered the last file I cobbled together indirect addressing to allow reuse of the QDEC@ module to set multiple parameters (look for "varptr" and how it is used in QDEC@ and in QE1 demo). The ability to set Min/Max for parameter inputs.
Any questions, best to get ahold of me at <brianbr@wulfden.org>
Ahhh, but my friend erco, is not a C junkie, he's just an honest man calling an honest contest!
Perhaps my hopes exceeded reality!
No, the aim of the thread was to get Forthers to focus on projects, however small. Next month it's another challenge and then another .... and so Forth! http://www.youtube.com/watch?v=6_ndC07C2qw
Nice to see the C junkies come out for their hate fix.
"Hate", no that was just a gentle ribbing. "C junkie" perhaps, but if you program in any language long enough you will eventually realize they all suck, to use the modern vernacular, just google for "xxxx sucks", where xxx is any language name, and you will see why. That's why programmers keep inventing new languages. That is why I have been junkie of the new Go language for two weeks, eventually I'll find out how bad that is as well:)
I am trying to make code work. Having wiring set backs as well as I assumed the wiring harness was all good.
So I need a clear deadline time to be fair to all. Let us say Ohio time as that is where Mindrobots is located.
So it it noon, midnight, 6pm, or whatever.
If it is 6pm Ohio time, I might just be up all night trying to squeak in an entry... but that is okay. And I am still trying to use PropForth 5.03.
If I submit a photo of PropForth printed on a chopstick and code, that should be enough. Never got a fresh printer cartridge, but the old one tries to do something. The new cartridge is due to arrive later... after this contest is over.
@Erco....
Trying to make me feel like the Lone Ranger without Tonto? We will see.... Forth is fun, the Propeller is fun, and whatever I do --- I think Forth is here to say and grow better.
....and remember, since the Mayan Apocolypse is coming in December, you could put 'learning Forth' on you post-apocalyptic plans....your calendar should be pretty open! Maybe we need a Forth Doomsday Contest!!
My weekends never end until I sit down at my desk and start working at my paying gig. I don't let my work life flow into my non-work life....that rule works just like a diode!! :0)
The Serial Inkjet Printer Board is a bit unusual in that it has no +5 voltage regulator on board. The +5 goes straight in to the SX28 and up until now I thought I was being very careful about not reversing polarity.
The board also has a chip that converts +5 to +24 for the printhead.
Now it seems I may have reversed polarity on the +5 and that is certain death to an SX28, not sure about the +24 chip. If that is so, I would have remove a surface mount SX28, install a new one, and download the SX/B code from the pdf file.
IOW, unless I can get a prompt form the board and some signs of function, all the code in the world is not going to drive the printer head.
I won't bother with a long explaination about how polarity may have gotten reversed.
I do see you posted a deadline time and we will see what's what. Even if the SX28 chip can be swapped, the +24V supply may be no more.
The PropForth stepper code works. But I need that board to verify the serial AND to use the serial.
Let's see 8am EST is 12 hours difference from here.
BTW, Prof Braino mentioned that he may have an entry.
A further look that the Serial Inkjet Printer Board shows me it has a rather substantial EEPROM for the character set that may also suffer damage from reverse polarity. So there is not going to be a last minute attempt to replace an SX28.
If I can get a prompt, I will try to print. If not, I will just try to pull together my stepper code and accept that I have learned quite a bit.
My project is the simplest forth project, just a POV example using a quickstart on a pendulum. All I need is a circuit to fire a solenoid to make the pendulum swing. After that, it would be simple, just read the bit patterns of the parallax font from the rom table, and flash the bits on the quckstart LEDs as it swings. They say anybody can do it.
Well, I am not just anybody, apparently.
To get started, I needed to clear a spot on the table. There was this big old Dell in the way, and rather than just move it to collect dust in a different spot for another year, I cleaned it off, installed linux, and got Steam installed and got as far as updating the drivers. Then I had to paint the kitchen.
As far as the original project goes, I did find two transistors, and got the solenoid to move. But it seems weak at 5 volts. I might have to find some big capacitor to give it a little more oomph. I wish I had an EE handy.
So now neither project is done, but I'm still having fun, and the kitchen is painted. I still have 23 hours till the deadline, maybe if I get started now, and nothing else comes up....
Well extending the deadline won't likely revive hardware. I am letting the Serial Inkjet Printer Board rest for now, but it might truly be rest in peace.
Any entry is appreciated. Hands on with the junk is part of the competition. It just won't work unless you really touch the stuff.
I fear that I have lacked 'due diligence' in maintaining my junkbox. So far, I discovered that the Propeller Proto Board that I have used for studying Forth has several bad I/O pins, so I had to grab a fresh one, solder headers on it, test the i/o, and swap out the old very beat up one.
Meanwhile, I moved over to the stepper code. As all good Forthers know, you can code in bits and pieces, verify functioning hardware, and calibrate.
So the two steppers I have -- 5 wire 5 volt 200ma Uni-polar steppers driven one ULN2803 at about 7.5volts input have proven good and working.
I am enclosing a file of that code for anyone that desires in the future to use the same in PropForth.
This is not the whole of what I intended to do, but at least it is verified working code from Loopy Byteloose. I love the buzz of steppers as things move back and forth with exact precision.
It is about time to investigate the Serial Inkjet Printer Board and see if I can actually squeeze bi-directional half-duplex out of PropForth. But if there is no prompt, this bit of code may not get a full real life verification until I can rig a BasicStamp2 or SX28 to mimic the broken board.... days away.
BTW, there is the remote possibility of building a clone for the damaged board. One day, the chopstick printer may actually succeed in a different incarnation.
~~~~~~~~~~~
Darn, I already found I have typos. The first loops are not endless, but 30 cycle of 4 steps. The timing was changed to 5 ms low 15ms high (which works smoothly), the TRIAL series of words are 120 steps and return a number 66, 77, 88. 99 to confirm with observed rotation as code and directions get confusing.
The TL# series are 30x4x5 steps for a total of 600 steps with code numbers returned on each 120 step cycle.
Game back on..... The Serial Inkjet Printer Board is working.
I did have reversed polarity, but I also knew I had the board turned off just in case. I was beginning to think that some odd wandering of the reversed polarity crept in via the USB port that supplies its own +5 and ground -- all very mental.
I had forgotten to switch the baud rate from 57600 to 9600 baud. So the board was fine, just ignoring the 57600 baud.
And so, we will just have to see if I can get this board to play with a Propeller in PropForth. I still am uncertain if the Inkjet catridge will print clearly, but we can try. Something comes out, but I can't verify all 12 jets without a rotating chopstick under the head.
Forth reallly is rather fast paced deployment. It is a great piece of software for an evening or weekend project.
"Hate", no that was just a gentle ribbing. "C junkie" perhaps, but if you program in any language long enough you will eventually realize they all suck, to use the modern vernacular, just google for "xxxx sucks", where xxx is any language name, and you will see why. That's why programmers keep inventing new languages. That is why I have been junkie of the new Go language for two weeks, eventually I'll find out how bad that is as well:)
Erco,
ALGOL, yes, but that would really tax my memory.
Language wars just get me, I'll take Chuck Moore's advice here, not that any language is better than the other, I'm just trying to solve some problems and not have to recreate the "world" each time I do it.
Attached is a picture of a re-worked 941 pressure cooker that is automated, note the PPBD in the forground. These are my poor man's steroclave to help those less fortunate sterilize water, instuments... They will run on propane and also via a hot oil loop from solar collectors. I can get the 941 at a very reasonable rate but automation and simplicity is the key. The project will not be completed today, it has been a long process because I have a full time job being the IT department for a small rapidly growing company. Currently porting a custom backend software solution to SAP, arg.
"
Moore:
A simple solution is one that does not obscure the problem with irrelevancies. Its conceivable that something about the problem requires a unique interpreter. But every time you see a unique interpreter, it implies that there is something particularly awkward about the problem. And that is almost never the case.
If you write your own interpreter, the interpreter is almost certainly the most complex, elaborate part of your entire application. You have switched from solving a problem to writing an interpreter.
I think that programmers like to write interpreters. They like to do these elaborate difficult things. But there comes a time when the world is going to have to quit programming keypads and converting numbers to binary, and start solving problems.
"
Moore:
A simple solution is one that does not obscure the problem with irrelevancies. It’s conceivable that something about the problem requires a unique interpreter. But every time you see a unique interpreter, it implies that there is something particularly awkward about the problem. And that is almost never the case.
If you write your own interpreter, the interpreter is almost certainly the most complex, elaborate part of your entire application. You have switched from solving a problem to writing an interpreter.
I think that programmers like to write interpreters. They like to do these elaborate difficult things. But there comes a time when the world is going to have to quit programming keypads and converting numbers to binary, and start solving problems.
"
Thank you. I dying in complexity. i've got the good ol' obcured with irrelevancies blues... big time.
Whomever wrote the Tutorial 3.2 Serial loop-back test has no less than 5 cogs passing i/o hither and thither to arrive back from whence it came. This is the anti-thesis of keep it simple. I guess that it works, but as an introductory tutorial it is way over the top.
And I have no physical way to remove the loop-back and verify when it is there and when it is not. Another one of those very creative solutions that I'd never try to teach to anybody.
If I can't get a full-duplex loop-back of the simple genre, I doubt it I can get a half-duplex bi-directional set up established to the outside world.
The whole purpose of a loop-back is to not run circles around on the interior of the device, but to demonstrate that the device is ready to send and receive to the outside world. There is more loopy than Loopy Byteloose can handle. This should have been two or three tutorials about setting up internal serial links and simple connections to the outside world - not all one bailey-wick.
It is 4:03AM here in old Taiwan and I am just trying to take the 57600 baud serial console interface to another cog to connect to a 9600 baud serial to the outside world. The console runs at 57600 baud, so some sort of buffering is required and buffers seem there. I figured I can just run a wire from one i/o pin to another for a simple loopback test and proof of at least a full-duplex serial port to the world beyond is doable AS I need to reach the outside world and not bounce of the walls of the Propeller's interior.
This is very difficult stuff, Grasshopper.
If I had to, I could make the whole setup 9600 baud as my minicom doesn't have to be in 57600 baud.
A. I can set up a serial port connected to two pins and have a wire between the two pins to create an echo.
B. Everytime I hook into it and I try to initialize and connect, the keyboard seems to output, but nothing comes back. There should be an echo..
At least the chopstick printer may actually print chopsticks one day soon. But this Serial Loop-back Tutorial is brutal. The PropForth.htm Section 6 is not working very well for me either. And I have located several serial related words in the long listing of lexicon that remain unmentioned.
Whatever happened to comprehensive overview. ;0(
try try again... and again
I am rambling on and tired. Maybe tomorrow will give me a fresh view.
"Less is Moore, and more is less." Mies Van der Roe, architect.
In the real world of human languages it has sometimes been deadly serious with countries and empires doing their best to stamp out local languages and assert power by imposing their own.
Hopefully in the world of programming languages things are not so serious. However I do get the feeling that sometimes languages are an attempt to gain and/or maintain "turf" by some organisations. Java and C# being classic examples here.
In a work environment often the language you are using day to day is often not of your own choice but rather dictated by company or project standards. Clearly if that language is causing you difficulty you are going to grumble and/or, if you are lucky, move on to something more agreeable/productive.
Getting proficient at a language and all it's idioms and libraries and IDE's etc etc takes a large investment of
time, effort and sheer mental space, no wonder people sometimes get heated about them.
Here we are mostly independent operators with our own little projects going on and have the luxury now to choose from many programming languages for the Propeller and other devices. Sometimes a little friendly gibing might go on, nothing too serious I hope.
That's an iteresting quote from Moore, programmers do like to write interpreters/compilers and design their own languages. Especially, it seems, after the languages they have been using start to annoy them enough or
become a limiting factor in some way. At some point programmers have to not do that but solve the problems at hand. However Moore is a bit cheeky saying that as he had just created his own language and interpreter.
Interesting project you have going on there with the steroclave, good luck with that.
Comments
Thanks, but no thanks. You don't seem to comprehend what I have written.
I have been testing an SX28 coded in SX/B via a USB interface to Minicom.
Emit 2 or Emit 3 are nothing that Minicom or SX/B will comprehend. Minicom does convert a Cntl-B to a <stx> and a Cntl-C to a <etx>. Then the SX28 does indeed see these and respond with some sort of behavior.
Besides... Emit 2 with send an ASCII character 2, not 0000_0010. This is not useful. That is actually a binary equivalent of decimal 50. You are off into the weeds.
I say some sort of behavior as the printer cartridge does appear defective. There are on-board diagnoistic LEDs to verify the board is working and I am getting them to light. So it seems the electronics is good to go, but I may not get a printer cartridge in time for the the contest deadline.
No need to worry. Peter and TachyonForth have his December 4th contest deadline, so I will continue to try. I am learning quite a bit. Project goals do help, rather than dealing in the abstract with what a language has or doesn't have.
~~~~~~~~~~~~~~~~~~~~~
In order for this project to go forward, I have had to verify the Serial Inkjet Printer Board is operational. I have yet to get any interface with a Forth platform established as it seems that all the Forths on Propeller just provide an RS232 port for console communication.
The only instances of using that RS232 port for other purposes seem to require actually removing wiring and plugging in something else. Not a particularly useful solution. Parallax generally has software support multiple RS232 connections as a communications hub, Forth seems to have not gotten that far.
I am near confirming the Serial Inkjet Printer Board is completely operational via direct RS232 with only that board. But I will at the very least have to redirect Pin 31 and Pin 30 TX/RX to another pin to handshake and then send data to the Serial Inkjet Printer Board. The single, by-directional RS232 is a bit of a challenge as each time I send something, the board confirms it is ready for more with a prompt character. So I need both directions on one Propeller I/O pin with full 9600 8n1 support.
To do so, I am digging in the .spin and .f source code for the Serial i/o.
It would seem that I have to change the baud rate to 9600 8n1 and back again, change the i/o pins and back again. At least that currently seems the easier path.
The other alternative is to set up another parallel serial i/o structure, maybe in another cog. That would be ideal... maybe a new long-term goal for Forths on the Propeller.
I am sorry Loopy, but you are wrong. 2 EMIT emits a binary two and "2" EMIT emits an ASCII two.
I thought I would post the code in case any Thanksgiving Challengers have a use for it. The code seems solid, but I am sure one of our gurus could shave a few words off.
.... enjoy
$32 EMIT will print the digit 2 on a terminal. The equivalents for this are "2" or #50 or 50d or 32h or even %%00110010 as well as 00110010b
Hi Brian,
Hopefully you have this encoder tied in as part of your project!
Don't forget you can use the Spin-like syntax as well for variables. Instead of:
VARIABLE oldBits
VARIABLE newBits
VARIABLE counter
You can write:
LONG oldBits,newBits,counter
Also these sequences can be optimized:
newBits @ 1 AND can be reduced to 0 newBits SET?
oldBits @ 1 SHR can be reduced to oldBits @ 2/
counter @ + counter ! can be reduced to counter +!
I also see the sequence IN@ A0 SHR 3 AND could do with a nice input instruction that I could add to the Tachyon VM that would take a mask, read those bits, and right justify it.
Thanks. That is extremely helpful..... a typical beginner's error. And I do understand that the quotations will only work in Tachyon, not PF.
I am still stuck as it seems the serial driver is only a full duplex that requires separate Tx and Rx pins.
I am using a Parallax product that requires what I believe is a half-duplex RS232 that can listen for a prompt and only then transmit. This is easy to do with a BasicStamp or with a conventional .spin object. But it seems that Forth has just presumed all RS232 with be full-duplex and PropForth seems to presume only 8n1 configuration.
[FONT=courier new]( *** PBASIC STYLE SERIAL I/O *** ) \ Set the baudrate for SEROUT and SERIN \ baudcnt is a task register so each cog can have it's own baudrate (if used) pub SERBAUD ( baud -- ) CLKFREQ SWAP / baudcnt ! ; \ Bit-bashed Serial output - transmit asynchronous data \ Fixed start bit timing \ Code size: 18 bytes \ Tested to 250K baud pub SEROUT ( data pin -- ) MASK DUP OUTSET SWAP \ ensure pin is an output (very first time perhaps) 2* \ Include start bit (0) baudcnt @ DELTA \ setup delay and wait 9 FOR WAITCNT SHROUT NEXT \ data bits DROP WAITCNT OUTSET \ final stop bit ; \ Bit-bashed Serial input - receive asynchronous data pub SERIN ( pin -- data ) MASK DUP INPUTS DUP baudcnt @ 2/ SWAP WAITPNE DELTA baudcnt @ DELTA \ delay to sample 1 bit later in 1st data bit 0 #8 FOR SHRINP WAITCNT NEXT NIP #24 SHR \ right justify 8-bit data ;[/FONT]Hi, thanks for mentioning that. I may be eating a lot of humble pie soon and have to shift to TachyonForth to get this to work.
Enjoy this. I do realize how much of a rank beginner I am. Still, I am moving forward.
Prof Braino has been much abused by my frustrations....
Here is a pic and the code. I am using TF v2.1 - 121114.1330 and EXTEND 121113.1200.
... enjoy
PropForth doesn't support half-duplex bi-directional serial or at least there is nothing that clearly shows that it does. There is only serial and _serial words with machine code attached to them. I've been told that I should write the code myself, but that isn't exactly a weekend project for me.
Since my Chopstick printer requires half-duplex bi-directional serial, I am pretty much at an impasse in PropForth. Go good luck to all of you and may the best project win.
We still have the Dec 4 competition and Tachyon may just support my hardware.
Keep plugging away! So far, you are the only two projects I've seen any progress reports on. I know I'm out of the running on this one. Maybe there are some folks holding off their "reveal" until the packaging is done and the marketing plan is in place......
Remember, tomorrow is probably the last day....unless I get distracted and don't start judging until Monday!!
Since I delivered the last file I cobbled together indirect addressing to allow reuse of the QDEC@ module to set multiple parameters (look for "varptr" and how it is used in QDEC@ and in QE1 demo). The ability to set Min/Max for parameter inputs.
Any questions, best to get ahold of me at <brianbr@wulfden.org>
Time is running out !!
The clock in my house just crossed over into SUNDAY.....time to finish up those projects and get them posted!
The judge could be showing up on Monday!!! Not done??? Post your progress, you could win for style points!
Don't forget, your project is also eligible for Peter's December FORTH contest!!
May the Forth be with them.
Now when do the COBOL and ALGOL contests start?
Nice to see the C junkies come out for their hate fix.
Ahhh, but my friend erco, is not a C junkie, he's just an honest man calling an honest contest!
Perhaps my hopes exceeded reality!
http://www.youtube.com/watch?v=6_ndC07C2qw
Erco,
ALGOL, yes, but that would really tax my memory.
So I need a clear deadline time to be fair to all. Let us say Ohio time as that is where Mindrobots is located.
So it it noon, midnight, 6pm, or whatever.
If it is 6pm Ohio time, I might just be up all night trying to squeak in an entry... but that is okay. And I am still trying to use PropForth 5.03.
If I submit a photo of PropForth printed on a chopstick and code, that should be enough. Never got a fresh printer cartridge, but the old one tries to do something. The new cartridge is due to arrive later... after this contest is over.
@Erco....
Trying to make me feel like the Lone Ranger without Tonto? We will see.... Forth is fun, the Propeller is fun, and whatever I do --- I think Forth is here to say and grow better.
I'll check in later for the dealine time.
8 AM EST, Monday, November 26th
My weekends never end until I sit down at my desk and start working at my paying gig. I don't let my work life flow into my non-work life....that rule works just like a diode!! :0)
The Serial Inkjet Printer Board is a bit unusual in that it has no +5 voltage regulator on board. The +5 goes straight in to the SX28 and up until now I thought I was being very careful about not reversing polarity.
The board also has a chip that converts +5 to +24 for the printhead.
Now it seems I may have reversed polarity on the +5 and that is certain death to an SX28, not sure about the +24 chip. If that is so, I would have remove a surface mount SX28, install a new one, and download the SX/B code from the pdf file.
IOW, unless I can get a prompt form the board and some signs of function, all the code in the world is not going to drive the printer head.
I won't bother with a long explaination about how polarity may have gotten reversed.
I do see you posted a deadline time and we will see what's what. Even if the SX28 chip can be swapped, the +24V supply may be no more.
The PropForth stepper code works. But I need that board to verify the serial AND to use the serial.
Let's see 8am EST is 12 hours difference from here.
A further look that the Serial Inkjet Printer Board shows me it has a rather substantial EEPROM for the character set that may also suffer damage from reverse polarity. So there is not going to be a last minute attempt to replace an SX28.
If I can get a prompt, I will try to print. If not, I will just try to pull together my stepper code and accept that I have learned quite a bit.
Well, I am not just anybody, apparently.
To get started, I needed to clear a spot on the table. There was this big old Dell in the way, and rather than just move it to collect dust in a different spot for another year, I cleaned it off, installed linux, and got Steam installed and got as far as updating the drivers. Then I had to paint the kitchen.
As far as the original project goes, I did find two transistors, and got the solenoid to move. But it seems weak at 5 volts. I might have to find some big capacitor to give it a little more oomph. I wish I had an EE handy.
So now neither project is done, but I'm still having fun, and the kitchen is painted. I still have 23 hours till the deadline, maybe if I get started now, and nothing else comes up....
Any entry is appreciated. Hands on with the junk is part of the competition. It just won't work unless you really touch the stuff.
I fear that I have lacked 'due diligence' in maintaining my junkbox. So far, I discovered that the Propeller Proto Board that I have used for studying Forth has several bad I/O pins, so I had to grab a fresh one, solder headers on it, test the i/o, and swap out the old very beat up one.
Meanwhile, I moved over to the stepper code. As all good Forthers know, you can code in bits and pieces, verify functioning hardware, and calibrate.
So the two steppers I have -- 5 wire 5 volt 200ma Uni-polar steppers driven one ULN2803 at about 7.5volts input have proven good and working.
I am enclosing a file of that code for anyone that desires in the future to use the same in PropForth.
This is not the whole of what I intended to do, but at least it is verified working code from Loopy Byteloose. I love the buzz of steppers as things move back and forth with exact precision.
It is about time to investigate the Serial Inkjet Printer Board and see if I can actually squeeze bi-directional half-duplex out of PropForth. But if there is no prompt, this bit of code may not get a full real life verification until I can rig a BasicStamp2 or SX28 to mimic the broken board.... days away.
BTW, there is the remote possibility of building a clone for the damaged board. One day, the chopstick printer may actually succeed in a different incarnation.
~~~~~~~~~~~
Darn, I already found I have typos. The first loops are not endless, but 30 cycle of 4 steps. The timing was changed to 5 ms low 15ms high (which works smoothly), the TRIAL series of words are 120 steps and return a number 66, 77, 88. 99 to confirm with observed rotation as code and directions get confusing.
The TL# series are 30x4x5 steps for a total of 600 steps with code numbers returned on each 120 step cycle.
I did have reversed polarity, but I also knew I had the board turned off just in case. I was beginning to think that some odd wandering of the reversed polarity crept in via the USB port that supplies its own +5 and ground -- all very mental.
I had forgotten to switch the baud rate from 57600 to 9600 baud. So the board was fine, just ignoring the 57600 baud.
And so, we will just have to see if I can get this board to play with a Propeller in PropForth. I still am uncertain if the Inkjet catridge will print clearly, but we can try. Something comes out, but I can't verify all 12 jets without a rotating chopstick under the head.
Forth reallly is rather fast paced deployment. It is a great piece of software for an evening or weekend project.
Language wars just get me, I'll take Chuck Moore's advice here, not that any language is better than the other, I'm just trying to solve some problems and not have to recreate the "world" each time I do it.
Attached is a picture of a re-worked 941 pressure cooker that is automated, note the PPBD in the forground. These are my poor man's steroclave to help those less fortunate sterilize water, instuments... They will run on propane and also via a hot oil loop from solar collectors. I can get the 941 at a very reasonable rate but automation and simplicity is the key. The project will not be completed today, it has been a long process because I have a full time job being the IT department for a small rapidly growing company. Currently porting a custom backend software solution to SAP, arg.
"
Moore:
A simple solution is one that does not obscure the problem with irrelevancies. Its conceivable that something about the problem requires a unique interpreter. But every time you see a unique interpreter, it implies that there is something particularly awkward about the problem. And that is almost never the case.
If you write your own interpreter, the interpreter is almost certainly the most complex, elaborate part of your entire application. You have switched from solving a problem to writing an interpreter.
I think that programmers like to write interpreters. They like to do these elaborate difficult things. But there comes a time when the world is going to have to quit programming keypads and converting numbers to binary, and start solving problems.
"
Thank you. I dying in complexity. i've got the good ol' obcured with irrelevancies blues... big time.
Whomever wrote the Tutorial 3.2 Serial loop-back test has no less than 5 cogs passing i/o hither and thither to arrive back from whence it came. This is the anti-thesis of keep it simple. I guess that it works, but as an introductory tutorial it is way over the top.
And I have no physical way to remove the loop-back and verify when it is there and when it is not. Another one of those very creative solutions that I'd never try to teach to anybody.
If I can't get a full-duplex loop-back of the simple genre, I doubt it I can get a half-duplex bi-directional set up established to the outside world.
The whole purpose of a loop-back is to not run circles around on the interior of the device, but to demonstrate that the device is ready to send and receive to the outside world. There is more loopy than Loopy Byteloose can handle. This should have been two or three tutorials about setting up internal serial links and simple connections to the outside world - not all one bailey-wick.
It is 4:03AM here in old Taiwan and I am just trying to take the 57600 baud serial console interface to another cog to connect to a 9600 baud serial to the outside world. The console runs at 57600 baud, so some sort of buffering is required and buffers seem there. I figured I can just run a wire from one i/o pin to another for a simple loopback test and proof of at least a full-duplex serial port to the world beyond is doable AS I need to reach the outside world and not bounce of the walls of the Propeller's interior.
This is very difficult stuff, Grasshopper.
If I had to, I could make the whole setup 9600 baud as my minicom doesn't have to be in 57600 baud.
A. I can set up a serial port connected to two pins and have a wire between the two pins to create an echo.
B. Everytime I hook into it and I try to initialize and connect, the keyboard seems to output, but nothing comes back. There should be an echo..
At least the chopstick printer may actually print chopsticks one day soon. But this Serial Loop-back Tutorial is brutal. The PropForth.htm Section 6 is not working very well for me either. And I have located several serial related words in the long listing of lexicon that remain unmentioned.
Whatever happened to comprehensive overview. ;0(
try try again... and again
I am rambling on and tired. Maybe tomorrow will give me a fresh view.
"Less is Moore, and more is less." Mies Van der Roe, architect.
There are many levels of "language war".
In the real world of human languages it has sometimes been deadly serious with countries and empires doing their best to stamp out local languages and assert power by imposing their own.
Hopefully in the world of programming languages things are not so serious. However I do get the feeling that sometimes languages are an attempt to gain and/or maintain "turf" by some organisations. Java and C# being classic examples here.
In a work environment often the language you are using day to day is often not of your own choice but rather dictated by company or project standards. Clearly if that language is causing you difficulty you are going to grumble and/or, if you are lucky, move on to something more agreeable/productive.
Getting proficient at a language and all it's idioms and libraries and IDE's etc etc takes a large investment of
time, effort and sheer mental space, no wonder people sometimes get heated about them.
Here we are mostly independent operators with our own little projects going on and have the luxury now to choose from many programming languages for the Propeller and other devices. Sometimes a little friendly gibing might go on, nothing too serious I hope.
That's an iteresting quote from Moore, programmers do like to write interpreters/compilers and design their own languages. Especially, it seems, after the languages they have been using start to annoy them enough or
become a limiting factor in some way. At some point programmers have to not do that but solve the problems at hand. However Moore is a bit cheeky saying that as he had just created his own language and interpreter.
Interesting project you have going on there with the steroclave, good luck with that.