Here is version 1.00 of pfth. This version supports writing to an SD card. It can create files and delete them. There are some limitations on the file system. It only support SD cards formatted with FAT16, which basically means they have to be 2G or smaller. Most of the code is there for FAT32, but I haven't completed that yet. Another limitation is that files must contain only one cluster, so files are limited to 16K or 32K depending on the cluster size. I haven't implemented cluster chaining yet. That will be in the next update along with FAT32.
I also ported a simple text editor that I used in spinix. It is a line-oriented text editor that implements a subset of the commands in the unix ED editor. I call it TED for Tiny EDitor. I implemented a few of the linux commands, which include cat, ls, rm and cp. The text editor is in ted.fth, and the linux commands are in linux.fth. These files can be compiled into the dictionary by first writing them to an SD card, and then using INCLUDE to load them.
Congratulations on pfth's ver 1.00. I just wired up my SD micro card reader in my Prop Demo board to take advantage of this. I barely had time to look at ver 0.83, but have been using list_primes to test my long-distance serial communications.... works like a charm.
Teaching Forth to rank beginners has been a personal goal since I got started. pfth certainly seems to make the teaching much easier, at least that was my experience with version 0.72.
There is a lot one might say and suggest, but the reality is that the Forth introductions are all for desktop applications, not for microcontroller work... and certainly never envisioned an 8 parallel processor device.
ANSI Forth is great for affirming the roots in Forth, but it is equally important to get quickly into to doing micro-controller projects that have their roots in BasicStamp simplicity. So I found it was extremely important to teach the i/o control early on with INPUT, OUTPUT, HIGH, and LOW. It is really simple stuff, but profound to someone new to microcontrollers. After than delays are extremely important as nearly everything happens to fast. And then branching forward and backward (aka looping). Within 30 minutes of useing pfth on the Propeller, it is obvious to the new user that they have a powerful terminal for remote control. This is made even more obvious if you provide a relay board of say 4 relays that can switch 110VAC lighting and such.
So at this point, it seem like using a teaching sequence like "Starting Forth" is good and handy, but one should have each chapter followed by a Propeller specific chapter that does something aside from numerical calculation and text manipulation.
That's about as far as I have gotten with a lesson plan for teaching Forth on the Propeller. My first attempts were to cram all the lexicon and try to figure out the story behind each word. I don't think that is very helpful, and certainly not fun or empowering... too dry. That is a great long-term goal and can be very rewarding eventually; but it is not necessary and maybe counter-productive to just learning to explore the Propeller comfortably with Forth.
With Forth, the beginner enjoys exploring, doesn't have to be buried in documentations, compilers, and code listings. Small fast paced productive projects just naturally evolve.
Because I was helping a fellow with a stepper motor controller and a large look up; we ended up with a very good intro through that project. A lookup table of 1067 data points was created to generate an acceleration curve over 2.5 seconds on the stepper motor, and start and stop sensing was included via hall-effect sensors. The project really lent itself to deeply exploring what ONE Cog would do and how to best exploit the Propeller's Hubram. We managed to get the lookup delays to conform within 0.02% of the original data with delays down to about 25 useconds.
It all worked so well, I am left wondering if I can find another stepper motor control project that would be so helpful to a complete beginner. I'll have to come up with something.
^^^^^^^^^
Controlling and programing the Propeller at a distance is a hardware passion of mine.
I really like RS-422 as it is easy to wire, cheap to use, and vastly out-performs RS232. I feel that USB can be overly complex, costly, and make people shy away from building their own micro-controller networks. Without repeaters, 4000 feet is very feasible, with building your own repeaters for a few dollars; one can easily go miles and miles. ... if you can afford the wire.
Suddenly it opens up micro-controllers to extremely rural applications ... maybe powered via solar.
But there are also simple items such as backyard lighting, a rooftop weather station, and so on. RS232 'might' work at 50 feet, but RS422 will surely work and will be easier to wire. So even the 10 to 50 foot distance is an RS422 candidate. Maybe you will want to later go wireless with an XBee setup, but you can iron out a lot of details with hardwire before you invest heavily in wireless.
RS422 is simple enough for kids as well. And so far, all my driver/ receiver chips are working fine in spite of a lot of hot swapping and nasty abuse. It seems you can even power one up that is unside-down in the DIP socket and it won't damage it. Just remove and set it in right and have another go. Very few chips will survive that.
PropForth has a Reboot command. pfth could easily generate the same as it is a PASM feature. It does come in handy to start over if you have created a big mess in the dictionary and the data stack. Of course, a proper Forth programmer used Forget to remove all the junk and can easily clear the stack with one ANSI word. But if you have 5 definitions that are all called Test, it is easier to just reboot and start afresh.
Lots to think about, I am finally using my Propellers frequently and creatively. It is all due to Forth, and in spite of my grumpiness, THANK YOU Sal Sanci and PropForth and Prof Braino. A lot of effort and some real vision was required to see that Forth is an excellent tool for the Propeller.
Still, I enjoy pfth as I can use all the published tutorials on Forth and follow more closely. You may get me to begin playing Chess on the Propeller as well.
Loopy, good to hear that things are going well with Forth. I would be interested in learning more about your experience in teaching Forth on the Prop to someone else. Maybe you could develop a tutorial about how to do pin I/O and delays on the Prop.
To be fair to Tachyon, it is still the king of speed on the Prop. I just happen to pick an example that I knew would do OK under pfth. I didn't know until I timed it under Tachyon that it would actually run slightly faster under pfth.
Programming the Prop at a distance is an interesting concept. It would simulate reprogramming a processor that's sitting in a satellite orbiting the earth, or located at some inaccessible location on the Earth. You would need some way for it to reboot if it got hung -- maybe a watchdog reset of some kind. I suppose with RS422 there may be a control line that could be used to reboot it.
@Loopy: I use a serial break condition to reboot the Prop remotely if everything has gone pear shaped. The break detection needs to be built into the receive cog for it to be effective. The tilde sequence of !~ is also accepted as a reboot but break detection works regardless of baud rate. Sometimes you also need a forced "cold start" too. Another thing is sometimes I don't want my autorun routines running so Tachyon performs an abort autorun key check after reboot. These tiny features amongst many others are all part of the necessary requirements of an embedded out-in-the-field system vs bench work. BTW, I do program my Forth systems remotely, very very remotely.......
@Dave: maybe that's something you can add (just for Loopy ! )
Peter, that sounds like a great idea. pfth currently doesn't use a dedicated cog for serial I/O, but I do plan on adding that. That way the serial cog can look for a reboot sequence like you suggested. During code development it's pretty easy to lock up the interpreter, so it would be good to be able to reboot the Prop from the serial cog.
I wonder how hard it would be to put a very simple Forth interpreter in the serial cog, which could be accessed by typing a special command. It could support a small dictionary that includes @ and DUMP for debugging purposes.
Peter, that sounds like a great idea. pfth currently doesn't use a dedicated cog for serial I/O, but I do plan on adding that. That way the serial cog can look for a reboot sequence like you suggested. During code development it's pretty easy to lock up the interpreter, so it would be good to be able to reboot the Prop from the serial cog.
I wonder how hard it would be to put a very simple Forth interpreter in the serial cog, which could be accessed by typing a special command. It could support a small dictionary that includes @ and DUMP for debugging purposes.
Well heck yeah, but just PASM routines for dumping examining or editing memory I guess. My transmit code is tied up in the console cog and as we know that's a problem because it will leave the transmit pin set high and the receive cog will not be able to control the pin (unless it stops the main cog). Perhaps if you handle full-duplex in a cog then it can do this sort of thing and even handle a hex load into EEPROM? This gets me thinking that if the serial cog were started first then it has control of the Forth cog so in effect you have control of the resources including the EEPROM if you do it this way so the serial cog could be receive only with the option to transmit in debug mode.
Hi all,
I have loaded pfth 1.00 for SDcard and wired may SDmicrocard interface to the Propeller Demo Board .. but got stuck for a day or so with what to do to create a file.
Today I just copied the whole pfth100 directory over th the SDmicrocard and used the LS command to see what came up. I was delighted. All the files are there. I can use CAT to view .txt files and .fth files. I can use TED to edit files line by line. And I can use include to load pfth Forth (or any ANSI Forth) into the Propeller if there is enough space.
This is beginning to look like a nice little OS that is Forth at its heart, buy Linux/Unix like in its utilities. It is far more than I expected for a Version 1.00.
Meanwhile, I am fooling with generating a UNIX Epoch timestamp via on Cog running as the resident RTC. The next thing to ponder is how to have files accumulate time stamped data in a data logging arrangement.
Thanks, and thanks again.
Those C programs just don't know what they are missing ;-)
Those C programs just don't know what they are missing ;-)
I have to say I find FORTH interesting. I have a robot set up with a Wixel for a wireless serial port to allow remote programming and commands. It's neat, I just wish I didn't find it so hard to program in.
@Loopy, keep us informed on how the RTC goes. You should be able to find C code on the internet that converts between unix time and the date and time of day. There may even be existing Forth code that does that. pfth is almost to the point where it can run as a stand-alone system. I just need to port the display driver from spinix and add a keyboard driver. Then it's just a matter of adding more unix/linux commands.
@Martin, the biggest challenge for me in programming in Forth is messing with the stack. I found that I can write Forth fairly quickly if I use variables instead of trying to keep everything on the stack. The problem with this approach is that all variables are global, so I add prefixes to my variables so they don't conflict with other words. This results in names like file_length or ted_first, where I would just like to use length or first. I think the solution to this is to implement a HIDE word so that I can remove a variable from the dictionary once I am done compiling words that use it. Hiding the variable will essentially make it a local variable.
Dave, I agree stack management is the hardest part, other than that I find it a reasonable language. I'm sure that global variables or static locals (the hide option) simplify programming. That works well if you don't need reentrancy which is reasonable in some cases, but not in others. So I've been trying to force myself to use the stack so I can write code that way when needed.
Another way I thought of doing local variables was to create a FRAME word that could increment the return pointer by a specified amount, and that space could be accessed using FRAME@ and FRAME! words. So it could would look like this.
: test
3 frame \ allocate space for 3 return stack variables
32 0 frame! \ write 32 to frame variable 0
12 1 frame! \ write 12 to frame variable 1
0 frame@ 1 frame@ + 2 frame! \ Add frame variable 0 to frame variable 1 and write to frame variable 2
2 frame@ . \ Print frame variable 2
unframe
;
These would need to be kernel words to be efficient, and it may be better to create individual words to access the frame variables, such as frame0@, frame0!, frame1@, etc.
This would be easy to implement, but would not be portable to other ANS Forths. I would like to have local stack variables, but I need to think about the best way to do it.
I suppose some people find the stack operation in Forth a challenge. I have been using RPN calculators for 3 decades, so it all seems quite natural now. For most things I don't use very deep stacks.. 5 or less items. Maybe one day I will get ambitious and need a stack that is 100 cells deep, but not now. pfth can do that if needed.
The interpreted language is the big payoff. For robotic projects or remote control, a lot of things need to be tweeked and observed to get a program right. Compiled languages can be very tedious with this phase of development .. especially if you are new programing as control.
It is also handy as the stacks are naturally a calculator that can help prepare code.
I need to do two things at this point.
A. Study Forth more. There is a lot of good material to read about ANSI Forth. And Taiwan has one of the last remaining active Forth Interest Groups.
B. Try to write some more about Forth on the Propeller. The more I use the Propeller, the more I see that legacy Forth is just half the fun. Controlling relays, controlling motors, sensing position, light, and more are quite easy. Doing things need more discussion.
In "Starting Forth", Mr. Brodie begins by explaining that Forth can do things like control a washing machine and provides example code. But with the Propeller, one can actually customize and control a real washing machine... it is no longer theory.
That's where it all gets very exciting. Think home automation, building your own micro-brewery, or having a rooftop weather station. Every time you want more, you just add a few words and revise.
I just built a Propeller programing interface that can be at the end of a very long wire so I can do these kinds of projects. And the parts easily cost me less than $10 USD. Now I need to get some Hall-effect sensors so that I can build a wind direction and wind speed set up if I want a weather station.. temperature and humidity are the easy part.
~~~~~~~~~~~~~~~~~~~~~`
There is another side to this as well. Forth is an excellent first step toward learning PASM. You can code words with PASM if you need to or want to. You don't have to write complete programs in assembler to use these. So one begins to explore lower and lower levels in a way that builds confidence by doing small useful tasks--- not huge programing projects.
pfth 1.02 is attached below. This version contains changes to support running under the Spinix operating system.
In addition to Spinix support, I added support for two simultaneous open files, and sub-directories. I also added the BYE, REBOOT and CD words.
I made CONSTANT and VALUE words more efficient by adding a kernel word to access their values instead of using DOES> with compiled code. I also modified the S" word so that it works in the interpreted mode in addition to the execution mode.
I've attached pfth 1.03 below. This version fixes a few bugs that were found recently. The U. word was not properly printing values that had the most significant bit set. I added UMOD and U/ words, and fixed the UDMOD, UD/ and # words, which also fixed the U. word.
I also fixed the PUTCH PASM routine that was writing to all the bits in OUTA. It now only writes to P30.
Dave, I read through this thread, downloaded pfth, read the readme, and installed it. It looks good, but do you have any examples of servo control using a background cog? The ability to save the workspace? I'd like to try my inverse kinematics code..
The toggle.fth example code is the demonstration of using a background cog, but just to blink an LED.
It should not be too hard to have an adaptation of the code run a servo with the millisec delay provide. But more precise timing of pulses is very possible. I have gotten down to 30usec delays with precision, but it takes some learning and tweeks.
Background cogs can be started to run independently, once all their activities are define in Forth words. if you can to pass information and confrom from the cog that actively communicates via the serial terminal, you wil have to establish variables in the Forth dictionary and to be share by both cogs.
Toggle.fth has 'Starttoggle' that demonstrates that the toggle is running on a separate cog. If you just call 'toggle', the same pin will be toggled with your current cog and you will be shut out of your interface to it by the infinite lop.
Once 'starttoggle' is running, you can use Cogstop to identify which cog it is running on (Probably cog 0). And after determining which cog, you can start and stop it from another cog.
It may help to revise the code to use coginit to specific which cog you want to run your code. In that way, there is no guess work as to which cog to stop.
Saving your code depends on your choice of pfth images. With an SDcard, you can have everything saved on the SDcard, and have an editor and a file system to support your development.
If you want a bare-bones pfth set up, you have to write your code to a .txt file and include it as a listing in the pfth.spin image. You can have a program autostart as well via the infile listing.
I haven't done any servo code for pfth, but Loopy has good suggestions for how to do this. I would suggest finding an appropriate driver in the OBEX and porting the Spin code to Forth. I'll look into this when I have a chance.
If you are using the stand-alone pfth.spin kernel you can use eesave to save the current workspace to EEPROM. I believe this should also work with the sdpfth.spin kernel as well. You will have to run "include i2c.fth" under sdpfth.spin to load the eesave command. When running under spinix I usually edit the Forth code under spinix using vi, and then test it by running pfth with the file, such as "pfth test.fth". You can also edit the source file under sdpfth by loading the tiny editor, TED, which is in ted.fth.
First, it looks like it doesn't implement the $ prefix to indicate the use of hexadecimal?
Second, I can interactively type forth into putty, but when I try to copy and paste my source into putty it hangs. There must be a problem with the usb driver because it also hangs my computer.
Third, I try to add a file "scara.fth" to work around but I get an error that the object exceeds runtime memory limit by 2047. My program isn't big, but it is commented heavily, so I removed all comments, but it is still about 600 bytes too big.
I really don't want to key in the whole program by hand, but I'm somewhat stumped.
pfth uses a simple serial driver that transmits and receive in the same cog as the interpreter. Because of this, it can't keep up with the data pasted into putty. You could try the buffered serial input driver by loading bufser.fth and running bufser to install it. However, I think it will still have trouble keeping up with the input from data pasted into putty. bufser.fth contains some other words that buffer data into memory, and then you can interpret it later, but I haven't tested it very much.
If you can add an SD card I would suggest running sdpfth. This will allow you to load files from an SD card. It would be even better if you ran pfth under spinix. This will give you Linux-like OS to edit files and then run them on pfth.
pfth doesn't support the $ prefix for hexadecimal. There is a standard way to define hexadecimal numbers in Forth, but I haven't implemented that either. You will have to run in the hex mode, or toggle back and forth between hex and decimal modes if you want to use numbers in both bases.
Attached is a HOWTO document for starting and using multiple cogs in pfth.
I've learned quite a bit that I haven't had time to properly write up for sharing. So it is time to give back to Dave Hein.. just in time for Thanksgiving.
I actually have a todo list of five more HOWTO documents for pfth.. so more will be forth coming.
Please be advised that I switched the text file with a later much better revision. My first posting was the wrong one.
As soon as I write something, there always seems to be more that could be said or done.
If you evoke a colon word that you want to just run for a limited time and then stop, you have to [a] know which cog it will run on and then place that cog id number on the stack and call Cogstop.
This can be done internally in the colon definition if the same cog will alway be used, or there are quite a few options of how to do it externally.
The main point is that you can have a task run and then end and free up the cog for other uses or just stop it to reduce power. You are not limited to creation of infinite loops on other cogs, though they are very handy in some cases.
Learning a bit more everyday... it really helps to write tutorials for others.
And so, if you are disappointed with the fact that Toggle.fth only provides an infinite loop example (I was.), here is an excellent method to run start a cog, run a task, and to stop a cog in pfth.
When you define your Forth word that is going to be a replacement for Toggle, at the end of the code include Cogid Cogstop.
Cogid works to locate the right cog in this instance because it is inside the Forth word that is being run of that cog. Cogstop will take the id number off the top of the stack and stop the cog.
If you just did something in code that ended, the cog would still be running and wasting power while doing nothing. It this way, you have a cleaner exit and it is easier to use the cog again for something else.
pfth uses a simple serial driver that transmits and receive in the same cog as the interpreter. Because of this, it can't keep up with the data pasted into putty. You could try the buffered serial input driver by loading bufser.fth and running bufser to install it. However, I think it will still have trouble keeping up with the input from data pasted into putty. bufser.fth contains some other words that buffer data into memory, and then you can interpret it later, but I haven't tested it very much.
If you can add an SD card I would suggest running sdpfth. This will allow you to load files from an SD card. It would be even better if you ran pfth under spinix. This will give you Linux-like OS to edit files and then run them on pfth.
pfth doesn't support the $ prefix for hexadecimal. There is a standard way to define hexadecimal numbers in Forth, but I haven't implemented that either. You will have to run in the hex mode, or toggle back and forth between hex and decimal modes if you want to use numbers in both bases.
So pfth doesn't have propforth "fl", how would one load a .fth file into the interpreter interactively?
I am looking at J1 forth and thinking, if this is possible: one the PC (one side of the serial connection) side, forth code (interactively) gets "cross-compiled" into forth VM machine code (this time J1 forth CPU machine code), and gets send to the Propeller (the other side of the serial connection) for execution.
Pros:
Propeller is essentially a J1 CPU emulator. PC runs the J1 forth compiler. That way the forth programming can still be interactive, since the PC forth compiler is super fast. And it won't burden the serial connection link, because only machine codes are sent forward.
Cons:
an extra program needs to run on the PC as the forth compiler
Compiled Forth code usually references absolute addresses, so I'm not sure if J1 code compiled on a PC would work on a J1 VM running on the Prop. It would be a completely different Forth interpreter than pfth, so it would require quite a bit of work to get it running on the Prop.
In my view, the best way to use pfth is under spinix where there is an OS for editing Forth source files and downloading from a PC. You could also run sdpfth, which works with an SD card, but is a stand-alone system.
As I mentioned in post #261, bufser.fth will provide a similar functionality as PropForth's fl command. If you are using pfth without an SD card you would need to include bufser.fth in the Spin file using the FILE directive. You would then run bufser to load the buffered serial driver. When you want to download some code you would first run bufferit, and then paste the code into the serial terminal. After the code is pasted in type the ESC key to terminate bufferit. You then have to run evalbuf to compile the buffered text. I haven't used this in a while, so I'll check it to make sure it still works.
Here's a version of pfth that starts the buffered serial driver and implements the fl command. Type fl, and the paste the source code into the serial terminal. You then need to press the ESC key to exit the buffering mode and interpret the pasted text. It works OK if I type in code after running the fl command, but I get garbled characters if I paste into putty. Maybe you'll have better luck with your PC. Let me know if it works.
I found the problem with the fl command in my previous code. The buffered serial cog doesn't have enough time between each received byte to store the byte and increment the index. The buffered serial cog runs the following code:
\ This word runs in a separate cog and writes input characters into the buffer
: bufsercog
bufserbuffer
begin
getchar over bufserwrindex @ + c!
bufserwrindex dup @ 1 + 31 and swap !
again ;
It has to execute 16 words every loop, which have to be done during the stop bit time. At a baud rate of 115200 the bit time is 8.7 usecs, or 543 nsecs per word. I have attached a new version of pfth that runs at a baud rate of 19200. The fl commands seems to work fine at this rate.
In the next version of pfth I'll implement a PASM buffered serial driver so it won't have this limitation, and fl should be able to operate at baud rates above 115200.
"What is the real Forth?".....
Programability at its utmost.
I have discovered that with pfth, I can have Forth words that start on their own cog run, and stop the cog when done.
So now I am in awe of this feature. It allows all sorts of interesting fast one-shot programing.. great stuff for robots. It really isn't that Forth is the 'one and only' computer language out their. It is just that it lets me explore and discover in a very different way than what else is available.... it adds to the experience of learning the Propeller.
An awful lot of users seem to depend too heavily on someone else's code. Forth tends to reinforce one's ability to think for one's self.
C will point you into libraries.
Spin will point you into OBEX.
Forth will point you toward what the hardware does and the PASM.
~~~~~~~~~~~~~~~~~~
BTW, Even though Dave Hein feels the need to accomodate 'Fast Load' bia a serial cut and paste, I am not fond of the feature. I have been using pfth with the INFILE feature to load code and it works well. Occassionally, I cut and paste one definition at a time.
If you want to archive code, using SPINX and having it all on a SDcard is more than adequate. I have a Propeller Demo Bord loaded with a micro SDcard and it does all this quite nicely. But I also, am collaborating with a guy that wants his code to control stepper motors and sensors in a complex fashion and that is a non-SDcard setup -- infile is working fine in that context.
Getting into faster and faster baud rates for the serial i/o has seemed another oddity for me. The Propeller can only fit 32K, so what is the need to feed it code at 115,200 baud? Are we just getting too greedy? Are users just naively demanding faster and faster speeds when they don't really know that what they have is adequate?
A slower baud rate for the sake of loading will not lower the speed at which the program runs internally. If your serial port is only used as a user interface, why bother with 115,200 baud and crashes? 19200 baud is adequate until you have a true need for higher rates.
If the Propeller is being overrun by the data feed, PuTTY and other serial terminal programs (TerraTerm or Minicom) do offer the ability to add delays after each sent character and after each sent line. I suspect that these delays might help some increases in load speed.
Above all, I like pfth as pfth. I certainly don't see the need to have it clone PropForth or Tachyon Forth features to be a success. I am deeply grateful that it has a more conservative vision of what Forth on the Propeller should be. I think that makes it easier for the new learner to assimilate. (of course, some will always balk at Forth for other reasons)
Comments
I also ported a simple text editor that I used in spinix. It is a line-oriented text editor that implements a subset of the commands in the unix ED editor. I call it TED for Tiny EDitor. I implemented a few of the linux commands, which include cat, ls, rm and cp. The text editor is in ted.fth, and the linux commands are in linux.fth. These files can be compiled into the dictionary by first writing them to an SD card, and then using INCLUDE to load them.
There is a lot one might say and suggest, but the reality is that the Forth introductions are all for desktop applications, not for microcontroller work... and certainly never envisioned an 8 parallel processor device.
ANSI Forth is great for affirming the roots in Forth, but it is equally important to get quickly into to doing micro-controller projects that have their roots in BasicStamp simplicity. So I found it was extremely important to teach the i/o control early on with INPUT, OUTPUT, HIGH, and LOW. It is really simple stuff, but profound to someone new to microcontrollers. After than delays are extremely important as nearly everything happens to fast. And then branching forward and backward (aka looping). Within 30 minutes of useing pfth on the Propeller, it is obvious to the new user that they have a powerful terminal for remote control. This is made even more obvious if you provide a relay board of say 4 relays that can switch 110VAC lighting and such.
So at this point, it seem like using a teaching sequence like "Starting Forth" is good and handy, but one should have each chapter followed by a Propeller specific chapter that does something aside from numerical calculation and text manipulation.
That's about as far as I have gotten with a lesson plan for teaching Forth on the Propeller. My first attempts were to cram all the lexicon and try to figure out the story behind each word. I don't think that is very helpful, and certainly not fun or empowering... too dry. That is a great long-term goal and can be very rewarding eventually; but it is not necessary and maybe counter-productive to just learning to explore the Propeller comfortably with Forth.
With Forth, the beginner enjoys exploring, doesn't have to be buried in documentations, compilers, and code listings. Small fast paced productive projects just naturally evolve.
Because I was helping a fellow with a stepper motor controller and a large look up; we ended up with a very good intro through that project. A lookup table of 1067 data points was created to generate an acceleration curve over 2.5 seconds on the stepper motor, and start and stop sensing was included via hall-effect sensors. The project really lent itself to deeply exploring what ONE Cog would do and how to best exploit the Propeller's Hubram. We managed to get the lookup delays to conform within 0.02% of the original data with delays down to about 25 useconds.
It all worked so well, I am left wondering if I can find another stepper motor control project that would be so helpful to a complete beginner. I'll have to come up with something.
^^^^^^^^^
Controlling and programing the Propeller at a distance is a hardware passion of mine.
I really like RS-422 as it is easy to wire, cheap to use, and vastly out-performs RS232. I feel that USB can be overly complex, costly, and make people shy away from building their own micro-controller networks. Without repeaters, 4000 feet is very feasible, with building your own repeaters for a few dollars; one can easily go miles and miles. ... if you can afford the wire.
Suddenly it opens up micro-controllers to extremely rural applications ... maybe powered via solar.
But there are also simple items such as backyard lighting, a rooftop weather station, and so on. RS232 'might' work at 50 feet, but RS422 will surely work and will be easier to wire. So even the 10 to 50 foot distance is an RS422 candidate. Maybe you will want to later go wireless with an XBee setup, but you can iron out a lot of details with hardwire before you invest heavily in wireless.
RS422 is simple enough for kids as well. And so far, all my driver/ receiver chips are working fine in spite of a lot of hot swapping and nasty abuse. It seems you can even power one up that is unside-down in the DIP socket and it won't damage it. Just remove and set it in right and have another go. Very few chips will survive that.
PropForth has a Reboot command. pfth could easily generate the same as it is a PASM feature. It does come in handy to start over if you have created a big mess in the dictionary and the data stack. Of course, a proper Forth programmer used Forget to remove all the junk and can easily clear the stack with one ANSI word. But if you have 5 definitions that are all called Test, it is easier to just reboot and start afresh.
Lots to think about, I am finally using my Propellers frequently and creatively. It is all due to Forth, and in spite of my grumpiness, THANK YOU Sal Sanci and PropForth and Prof Braino. A lot of effort and some real vision was required to see that Forth is an excellent tool for the Propeller.
Still, I enjoy pfth as I can use all the published tutorials on Forth and follow more closely. You may get me to begin playing Chess on the Propeller as well.
@Dave: maybe that's something you can add (just for Loopy
I wonder how hard it would be to put a very simple Forth interpreter in the serial cog, which could be accessed by typing a special command. It could support a small dictionary that includes @ and DUMP for debugging purposes.
Well heck yeah, but just PASM routines for dumping examining or editing memory I guess. My transmit code is tied up in the console cog and as we know that's a problem because it will leave the transmit pin set high and the receive cog will not be able to control the pin (unless it stops the main cog). Perhaps if you handle full-duplex in a cog then it can do this sort of thing and even handle a hex load into EEPROM? This gets me thinking that if the serial cog were started first then it has control of the Forth cog so in effect you have control of the resources including the EEPROM if you do it this way so the serial cog could be receive only with the option to transmit in debug mode.
I have loaded pfth 1.00 for SDcard and wired may SDmicrocard interface to the Propeller Demo Board .. but got stuck for a day or so with what to do to create a file.
Today I just copied the whole pfth100 directory over th the SDmicrocard and used the LS command to see what came up. I was delighted. All the files are there. I can use CAT to view .txt files and .fth files. I can use TED to edit files line by line. And I can use include to load pfth Forth (or any ANSI Forth) into the Propeller if there is enough space.
This is beginning to look like a nice little OS that is Forth at its heart, buy Linux/Unix like in its utilities. It is far more than I expected for a Version 1.00.
Meanwhile, I am fooling with generating a UNIX Epoch timestamp via on Cog running as the resident RTC. The next thing to ponder is how to have files accumulate time stamped data in a data logging arrangement.
Thanks, and thanks again.
Those C programs just don't know what they are missing ;-)
I have to say I find FORTH interesting. I have a robot set up with a Wixel for a wireless serial port to allow remote programming and commands. It's neat, I just wish I didn't find it so hard to program in.
@Martin, the biggest challenge for me in programming in Forth is messing with the stack. I found that I can write Forth fairly quickly if I use variables instead of trying to keep everything on the stack. The problem with this approach is that all variables are global, so I add prefixes to my variables so they don't conflict with other words. This results in names like file_length or ted_first, where I would just like to use length or first. I think the solution to this is to implement a HIDE word so that I can remove a variable from the dictionary once I am done compiling words that use it. Hiding the variable will essentially make it a local variable.
This would be easy to implement, but would not be portable to other ANS Forths. I would like to have local stack variables, but I need to think about the best way to do it.
The interpreted language is the big payoff. For robotic projects or remote control, a lot of things need to be tweeked and observed to get a program right. Compiled languages can be very tedious with this phase of development .. especially if you are new programing as control.
It is also handy as the stacks are naturally a calculator that can help prepare code.
I need to do two things at this point.
A. Study Forth more. There is a lot of good material to read about ANSI Forth. And Taiwan has one of the last remaining active Forth Interest Groups.
B. Try to write some more about Forth on the Propeller. The more I use the Propeller, the more I see that legacy Forth is just half the fun. Controlling relays, controlling motors, sensing position, light, and more are quite easy. Doing things need more discussion.
In "Starting Forth", Mr. Brodie begins by explaining that Forth can do things like control a washing machine and provides example code. But with the Propeller, one can actually customize and control a real washing machine... it is no longer theory.
That's where it all gets very exciting. Think home automation, building your own micro-brewery, or having a rooftop weather station. Every time you want more, you just add a few words and revise.
I just built a Propeller programing interface that can be at the end of a very long wire so I can do these kinds of projects. And the parts easily cost me less than $10 USD. Now I need to get some Hall-effect sensors so that I can build a wind direction and wind speed set up if I want a weather station.. temperature and humidity are the easy part.
~~~~~~~~~~~~~~~~~~~~~`
There is another side to this as well. Forth is an excellent first step toward learning PASM. You can code words with PASM if you need to or want to. You don't have to write complete programs in assembler to use these. So one begins to explore lower and lower levels in a way that builds confidence by doing small useful tasks--- not huge programing projects.
In addition to Spinix support, I added support for two simultaneous open files, and sub-directories. I also added the BYE, REBOOT and CD words.
I made CONSTANT and VALUE words more efficient by adding a kernel word to access their values instead of using DOES> with compiled code. I also modified the S" word so that it works in the interpreted mode in addition to the execution mode.
I also fixed the PUTCH PASM routine that was writing to all the bits in OUTA. It now only writes to P30.
It should not be too hard to have an adaptation of the code run a servo with the millisec delay provide. But more precise timing of pulses is very possible. I have gotten down to 30usec delays with precision, but it takes some learning and tweeks.
Background cogs can be started to run independently, once all their activities are define in Forth words. if you can to pass information and confrom from the cog that actively communicates via the serial terminal, you wil have to establish variables in the Forth dictionary and to be share by both cogs.
Toggle.fth has 'Starttoggle' that demonstrates that the toggle is running on a separate cog. If you just call 'toggle', the same pin will be toggled with your current cog and you will be shut out of your interface to it by the infinite lop.
Once 'starttoggle' is running, you can use Cogstop to identify which cog it is running on (Probably cog 0). And after determining which cog, you can start and stop it from another cog.
It may help to revise the code to use coginit to specific which cog you want to run your code. In that way, there is no guess work as to which cog to stop.
Saving your code depends on your choice of pfth images. With an SDcard, you can have everything saved on the SDcard, and have an editor and a file system to support your development.
If you want a bare-bones pfth set up, you have to write your code to a .txt file and include it as a listing in the pfth.spin image. You can have a program autostart as well via the infile listing.
If you are using the stand-alone pfth.spin kernel you can use eesave to save the current workspace to EEPROM. I believe this should also work with the sdpfth.spin kernel as well. You will have to run "include i2c.fth" under sdpfth.spin to load the eesave command. When running under spinix I usually edit the Forth code under spinix using vi, and then test it by running pfth with the file, such as "pfth test.fth". You can also edit the source file under sdpfth by loading the tiny editor, TED, which is in ted.fth.
First, it looks like it doesn't implement the $ prefix to indicate the use of hexadecimal?
Second, I can interactively type forth into putty, but when I try to copy and paste my source into putty it hangs. There must be a problem with the usb driver because it also hangs my computer.
Third, I try to add a file "scara.fth" to work around but I get an error that the object exceeds runtime memory limit by 2047. My program isn't big, but it is commented heavily, so I removed all comments, but it is still about 600 bytes too big.
I really don't want to key in the whole program by hand, but I'm somewhat stumped.
If you can add an SD card I would suggest running sdpfth. This will allow you to load files from an SD card. It would be even better if you ran pfth under spinix. This will give you Linux-like OS to edit files and then run them on pfth.
pfth doesn't support the $ prefix for hexadecimal. There is a standard way to define hexadecimal numbers in Forth, but I haven't implemented that either. You will have to run in the hex mode, or toggle back and forth between hex and decimal modes if you want to use numbers in both bases.
I've learned quite a bit that I haven't had time to properly write up for sharing. So it is time to give back to Dave Hein.. just in time for Thanksgiving.
I actually have a todo list of five more HOWTO documents for pfth.. so more will be forth coming.
Please be advised that I switched the text file with a later much better revision. My first posting was the wrong one.
If you evoke a colon word that you want to just run for a limited time and then stop, you have to [a] know which cog it will run on and then place that cog id number on the stack and call Cogstop.
This can be done internally in the colon definition if the same cog will alway be used, or there are quite a few options of how to do it externally.
The main point is that you can have a task run and then end and free up the cog for other uses or just stop it to reduce power. You are not limited to creation of infinite loops on other cogs, though they are very handy in some cases.
I posted the wrong file the first time.
Here is the right version, much better info.. clearer.
And so, if you are disappointed with the fact that Toggle.fth only provides an infinite loop example (I was.), here is an excellent method to run start a cog, run a task, and to stop a cog in pfth.
When you define your Forth word that is going to be a replacement for Toggle, at the end of the code include Cogid Cogstop.
Cogid works to locate the right cog in this instance because it is inside the Forth word that is being run of that cog. Cogstop will take the id number off the top of the stack and stop the cog.
If you just did something in code that ended, the cog would still be running and wasting power while doing nothing. It this way, you have a cleaner exit and it is easier to use the cog again for something else.
Very handy.
So pfth doesn't have propforth "fl", how would one load a .fth file into the interpreter interactively?
I am looking at J1 forth and thinking, if this is possible: one the PC (one side of the serial connection) side, forth code (interactively) gets "cross-compiled" into forth VM machine code (this time J1 forth CPU machine code), and gets send to the Propeller (the other side of the serial connection) for execution.
Pros:
Propeller is essentially a J1 CPU emulator. PC runs the J1 forth compiler. That way the forth programming can still be interactive, since the PC forth compiler is super fast. And it won't burden the serial connection link, because only machine codes are sent forward.
Cons:
an extra program needs to run on the PC as the forth compiler
What do you think?
In my view, the best way to use pfth is under spinix where there is an OS for editing Forth source files and downloading from a PC. You could also run sdpfth, which works with an SD card, but is a stand-alone system.
As I mentioned in post #261, bufser.fth will provide a similar functionality as PropForth's fl command. If you are using pfth without an SD card you would need to include bufser.fth in the Spin file using the FILE directive. You would then run bufser to load the buffered serial driver. When you want to download some code you would first run bufferit, and then paste the code into the serial terminal. After the code is pasted in type the ESC key to terminate bufferit. You then have to run evalbuf to compile the buffered text. I haven't used this in a while, so I'll check it to make sure it still works.
\ This word runs in a separate cog and writes input characters into the buffer : bufsercog bufserbuffer begin getchar over bufserwrindex @ + c! bufserwrindex dup @ 1 + 31 and swap ! again ;It has to execute 16 words every loop, which have to be done during the stop bit time. At a baud rate of 115200 the bit time is 8.7 usecs, or 543 nsecs per word. I have attached a new version of pfth that runs at a baud rate of 19200. The fl commands seems to work fine at this rate.In the next version of pfth I'll implement a PASM buffered serial driver so it won't have this limitation, and fl should be able to operate at baud rates above 115200.
Programability at its utmost.
I have discovered that with pfth, I can have Forth words that start on their own cog run, and stop the cog when done.
So now I am in awe of this feature. It allows all sorts of interesting fast one-shot programing.. great stuff for robots. It really isn't that Forth is the 'one and only' computer language out their. It is just that it lets me explore and discover in a very different way than what else is available.... it adds to the experience of learning the Propeller.
An awful lot of users seem to depend too heavily on someone else's code. Forth tends to reinforce one's ability to think for one's self.
C will point you into libraries.
Spin will point you into OBEX.
Forth will point you toward what the hardware does and the PASM.
~~~~~~~~~~~~~~~~~~
BTW, Even though Dave Hein feels the need to accomodate 'Fast Load' bia a serial cut and paste, I am not fond of the feature. I have been using pfth with the INFILE feature to load code and it works well. Occassionally, I cut and paste one definition at a time.
If you want to archive code, using SPINX and having it all on a SDcard is more than adequate. I have a Propeller Demo Bord loaded with a micro SDcard and it does all this quite nicely. But I also, am collaborating with a guy that wants his code to control stepper motors and sensors in a complex fashion and that is a non-SDcard setup -- infile is working fine in that context.
Getting into faster and faster baud rates for the serial i/o has seemed another oddity for me. The Propeller can only fit 32K, so what is the need to feed it code at 115,200 baud? Are we just getting too greedy? Are users just naively demanding faster and faster speeds when they don't really know that what they have is adequate?
A slower baud rate for the sake of loading will not lower the speed at which the program runs internally. If your serial port is only used as a user interface, why bother with 115,200 baud and crashes? 19200 baud is adequate until you have a true need for higher rates.
If the Propeller is being overrun by the data feed, PuTTY and other serial terminal programs (TerraTerm or Minicom) do offer the ability to add delays after each sent character and after each sent line. I suspect that these delays might help some increases in load speed.
Above all, I like pfth as pfth. I certainly don't see the need to have it clone PropForth or Tachyon Forth features to be a success. I am deeply grateful that it has a more conservative vision of what Forth on the Propeller should be. I think that makes it easier for the new learner to assimilate. (of course, some will always balk at Forth for other reasons)