Propeller Forth Interest Group
nglordi
Posts: 114
Greetings!
As a former host of a local forth interest group, my interest in forth has been revitalized by Sal Sanci's PropForth. I have started this thread as a base for sharing and discussing propforth applications (not the propforth source code which is covered by Prof. Braino's thread), which might encourage others to try forth for their applications.
I have attached my first forth application to the thread: PropFACS (ver. 1.1), a forth analog computer simulator, and its user manual (pdf file). One of my objectives in this project was to eliminate the need to use a pc terminal simulator. The attachment termbrd.jpg shows the hardware I am using to accomplish this objective. It consists of a Gadget Gangster propeller platform running propforth and a terminal shield containing a second propeller which interfaces to a keyboard, tv, and sd-card module. Note that all pins of both propellers are separately available. The two propellers communicate through a two-wire serial interface. The terminal software is a combination of OBC's terminal object and mpark's ed object. The attachment terminal.jpg shows the opening screen. The user can access a full screen editor to define new forth words which can be downloaded into forth, tested, modified and saved on the sd card.
An analog comoputer emulation requires a graphic display. This was accomplished using a separate program based on Eric Ball's GreyTV object. The small board attached to the terminal shield can hold up to 4 eeproms, which are individually selectable. The first one on the board contains the terminal/editor program and the second the graphics program. The last attached image shows one example of a FACs solution to the Van Der Pol equation. Other examples as well as a description of how these plots were obtained are in the user manual. Full details of the hardware design and associated software, which is still in the alpha stage, will be pasted at a later date (probably in the Projects section of the forum).
nickL
As a former host of a local forth interest group, my interest in forth has been revitalized by Sal Sanci's PropForth. I have started this thread as a base for sharing and discussing propforth applications (not the propforth source code which is covered by Prof. Braino's thread), which might encourage others to try forth for their applications.
I have attached my first forth application to the thread: PropFACS (ver. 1.1), a forth analog computer simulator, and its user manual (pdf file). One of my objectives in this project was to eliminate the need to use a pc terminal simulator. The attachment termbrd.jpg shows the hardware I am using to accomplish this objective. It consists of a Gadget Gangster propeller platform running propforth and a terminal shield containing a second propeller which interfaces to a keyboard, tv, and sd-card module. Note that all pins of both propellers are separately available. The two propellers communicate through a two-wire serial interface. The terminal software is a combination of OBC's terminal object and mpark's ed object. The attachment terminal.jpg shows the opening screen. The user can access a full screen editor to define new forth words which can be downloaded into forth, tested, modified and saved on the sd card.
An analog comoputer emulation requires a graphic display. This was accomplished using a separate program based on Eric Ball's GreyTV object. The small board attached to the terminal shield can hold up to 4 eeproms, which are individually selectable. The first one on the board contains the terminal/editor program and the second the graphics program. The last attached image shows one example of a FACs solution to the Van Der Pol equation. Other examples as well as a description of how these plots were obtained are in the user manual. Full details of the hardware design and associated software, which is still in the alpha stage, will be pasted at a later date (probably in the Projects section of the forum).
nickL
Comments
nice work. I am just walking my first steps with FORTH on the Propeller. Its a nice peace of software, but i am fighting a little bit with the docs.
My task now is to realize a 2nd serial port on the Propeller to handle some external hardware.
With
decimal
cogstop 2
4 5 9600 2 startserialcog
: test c" hallo Test " 2 cogx ;
test
i can send a string to port 4 with 9600 baud, ok.
With
2 >con
i can send all data from port 5 to the user terminal, but i can't switch off this anymore.
I would like to get the data from the serial port into a buffer , stack or string.
Any ideas?
(This is an English crossposting from the German HIVE project group
http://hive-project.de/board/viewforum.php?f=6 )
Kind Regards
Markus
\communication to the serialcog 2 on channel 1, CTRL+F exit term.
2 1 term
works great. It transmit date from and to the serial interface from the terminal.
Markus
( http://forums.parallax.com/showthread.php?117202-Fast-Hartley-Transform) IMHO the FHT is the preferred approach to doing Fourier analysis and synthesis on the propeller. Attached to this post is a PropForth version of the FHT and some examples showing how the FHT vocabulary can be used. Although this particular forth version runs about 3x slower than the spin version, for most problems this is not significant. The pasm version is available if analysis time is an issue. Otherwise the forth version has the advantage of easy data manipulation and extensibility, which I hope is apparent in the selected examples.
NickL
PF_SFM is an interface to SPI Flash Memory, SRAM and PCM. The Digilent PmodSF2 breakout board for the Numonyx (now owned by Micron) Omneo P5Q PCM (Phase Change Memory) is particularly interesting. It is a 16 Megabyte chip with 1 million write cycles and, unlike flash memory, it has a bit-alterable page (64 byte) write. No erasure of memory is required before write operations. It is also capable of fast dual & quad reads and writes. It is easily interfaced to the propeller.
C3SPI is a set of PropForth spi apis for the C3 module.
NickL
Nice combination! Would you mind posting a copy of that morph between PropComm and Ed?
I've got a project that this would be useful with as well.
OBC
Good work! What is the size of the TV?
@Humanoido I use a 7 inch tv.
NickL
OBC
http://code.google.com/p/propforth/wiki/Propforth50FAQ
The scripting sounds very cool!
Having spent some time trying to understand the programming of the non-propeller components of the Chameleons, I finally realized (as a consequence of my "forth" reawakening) that the optimal approach to programming the Chameleon PIC and AVR was to install forth. This would eliminate the need to use tool chains, fuses, etc. I have installed Matthias Trute's amforth (4.5) on the Chameleon AVR and Mikael Nordman's FlashForth (4.7) on the Chameleon PIC. In the latter case, I replaced the original PIC24HJ128GP502 with the pin equivalent dsPIC33FJGP802.
Both installations are mature forth versions which have many features currently absent in PropForth, e.g., does>, [.....], inline assembly language coding, and word lists. However, unlike PropForth, program loading is slow since the forth system is largely in the flash memory.
There are many options to interfacing PIC/AVR forth to the propeller. We might use a propeller terminal emulation to talk to the PIC/AVR. However, I have installed PropForth on the propellers and intend to explore communication between the different forths.
NickL
What made you choose the Chameleon and the particular models your selected, would these be you general purpose recommendations as well? My focus is on kids' robotics, any insights on hardware appropriate for this? I'm interested in working on interfacing to other forths on other hardware.
EDIT - OK, I just searched and discovered the chameleon on the Prop Third party page. Starting to make a little sense.
I should also open function requests for PF5.0. In-line assembly shoud be already working in 5.0; I'm open a request for DOES> , and I'll start the discussion with Sal about word lists (I'll need input from you how to handle this). Is there anything else to add?
Added Issue 51: DOES>
http://code.google.com/p/propforth/issues/detail?id=51
Added Issue 52: WORDS
http://code.google.com/p/propforth/issues/detail?id=52
Please clarify that WORDS list refers to defining different "VOCABULARIES" that is limit various sets of words from the dictionary search? My understanding might be way outdated.
Word lists does refer to different vocabularies. As I explore the differences in the forths, I will probably find other words that could be added to PropForth.
I have also installed Amforth on the Digilent Cerebot Nano Pmod which is an Atmega 168. This is a small board which can easily be interfaced to any propeller board.
Just joking...sorry, I'm in a weird mood today.:)
To say honest, I think your joke is true.
In PropForth's thread, few post comments. Always same persons.
Every likes Propeller, but many is not interesting in PropForth.
I like PropForth, so I made many junk-codes although no reply.
Even if Sal and prof_braino retire from PropForth, I will want to develop it.
There is one problem.
I don't have skill to develop it.
I have tried to get into Forth a few times over the years, attracted by it's promise of compact and speedy code. Somehow my brain just does not accept it and pages of Forth source still don't click for me. There would have to be some overwhelming technical advantages (codes size/speed/whatever) or ease of use advantages to Forth to get me to look at it again I'm afraid as life is short and pressure is on to learn or at least be familiar with a bunch of other languages and systems. As an old block structured, strongly typed language kind of guy I'm not so happy with some of those new languages either:)
Sal and prof_braino and all, don't let me discourage you. Which I'm sure I won't, programming languages are things people take to heart and get passionate about no matter what. I'm glad to see developments for the Prop in all directions.
I track all in Forth threads carefully.
BUT have no time to post comments even if I test Forth.
Forth is more than a language and I never have so much fun with hardware without Forth, that is, a Forth system resident on the embedded target. All too often someone "tries" Forth and as usual they fail to grasp the significance of being able to interact with hardware and test concepts and what might be possible and doing so in an interactive manner that is not foreign because you project your personality onto the Forth system. It becomes you, the Forth is with you.
Don't worry, Sal develops propforth for his own personal use, and tolerates my "input" as it occasionally triggers an interesting idea.
As for myself, I document propforth because I will need some sort of reference if I ever get around to actually doing something with it.
Any advantages (or not) will be evident in 5.0. The execution speed should be measurably faster than previous versions; the scripting and paged assembler should allow unlimited program and data size* (* to the size of the SD), and the multiprop should allow unlimited cogs and pins. If these could be considered advantages despite their constraints, (we have to be careful how we craft the program so the parts still fit in 32k Hub or 2K cog, and SD access speed limits the speed of storage access), then 5.0 might be interesting.
What is still needed is an application those shows how to use these features. I'm still working on that one.
The 27th (2011) EuroForth Conference is scheduled to take place in Vienna, Austria on Sept. 23-25.
nickL
Whereas Forth is engineer friendly, it's what we need to access the hardware directly, in an interactive and incremental development manner. I can load Forth onto a new board and through the serial coms "talk" to the board. An example here I had a new board this morning and the very first thing I did was simply exercise the leds interactively first and then added that functionality to the the Forth kernel so that I could type in "ON ErrorLed" for instance or just incorporate that into another higher level definition that dealt with system faults. Testing of connected solenoids and motors was a cinch too.
To test the led the first time using PropForth I typed "25 pinout 25 pinhi" which made pin 25 an output and took the pin high to turn on the led. Next I created a definition for this ": ErrorLed 25 pinout 25 px ;" which compiles onto the kernel and allowed me to then type in interactively "1 ErrorLed" which looks a bit dumb so I defined constants for ON and OFF so you end up with "ON ErrorLed", that simple!
It has always seemed to me that Forth is the most logical language to use on embedded systems other than those itty-bitty jobs where it is just as easy to write a little assembler code. Forth doesn't really port easily to the Prop though and it takes a lot of extra effort to get it to run on this architecture and with the software tools that are available. But Sal has put the effort into it and come up with a very usable Forth for serious embedded projects and I believe that V5 will be the bee's knees too.
While I agree with much of what you said, I disagree with a couple bits.
1) if you think the conference is boring, don't go; but no need to dis' it. Or go change it and make it better, but please don't dis' it. Some of those eggheads put a LOT of effort into it so you and I DON'T have to muddle through the material we find boring.
2) The reason why you don't see discussions about standards etc in the context of propforth is because Sal and I did this work off-line, in the beginning, when it did some good.
We (Sal and I initially, more recently caskaz, brian, and nick) beat the snot out of the standards to determine what was applicable. We determined that propforth:
- is Sal's tool for his personal use, first and formost. Sal has final say on his tool, which is the kernel.
- can be modified by any user for any purpose. You have final say on your tool, the result of which may or may not enjoy direct support.
- follows the existing standards wherever possible, and any deviations or departures are defined
- does not need to support all words or in the same way, example is the absence of DOES>
- is tailored to best suit the prop's architecture, according to Sal's interpretation
- accepts kernel architecture modification suggestions from users, at Sal's discretion
- uses that same labels as spin and pasm when these functions are used in the same way
- supports mixed case labels
- uses a specific set of labels for internal purposed (example embedded underscores) so users know not to mess with them unless prepared
- all kernel words follow other sets of "standards" such as lowercase only designating words that the user will commonly access during development
- has "standard interfaces" so it is transparent to connect to serial terminal or other cog, etc
- support BLOCK storage access by kernel default, but allow for FAT support as an extension (if caskaz wants to implement it)
- etc. There's tons more, but I forgot most of it.
Sorry for the lecture, I get carried way as I was supposed to put this on the wiki about a year ago.
Point is, that when standards are resolved before any coding starts, there is very little discussion, since no one has to defend a conflicting position. "Generic" forth evolved, propforth was engineered based on knowledge of that evolution. If it appears compliance to standards is a non-issue because its so easy, then we have done our job correctly. But don't misunderstand, "compliance to standards" looks easy because we worked hard on it for a year and a half.
Now we are soliciting standards and "best practices" for public and/or sharable code for experienced users like Nick and caskaz. This will become increasingly important as we move focus from kernel development to extensions for supporting various hardware options. Less work will be done by Sal directly, and more work will be contributed based on individual's implementation of specific hardware.
Hopefully, you and others will continue to contribute to the discussion, the code base and thus the standards. If we do it right, new users will find the "standards" are obvious and logical, and require no effort. If we make it look easy, we are doing well.
Man, I would love to go see Vienna. If anybody gets bought out by Google and needs a a vulgar display of wealth, I volunteer to be sponsored to attend this conference.
http://www.forth.org/memory.html
http://www.ultratechnology.com/
Prof Braino ... it's all your fault !!! I followed these links and then the links they had and so on ... you all know the drill ... emerging two and a half hours later with a treasure trove of very interesting Forth files, essays, tutorials, etc by Charles Moore, Jeff Fox, Leo Brodie, etc ... I made an open directory for them. The total of the over two dozen files is 10-11MB. The files are mostly in PDF, some are text, and one is an HTML folder. You can find it at http://www.wulfden.org/downloads/Forth_Resources/ ... enjoy ... BBR
I saw the analog computer in the first post. What other sorts of projects are people building using it? Can Fourth call Spin objects or if not does PropFourth have servo and sensor libraries?
Sure, I could write some Spin or PASM code, no problem at all, and it might work, but if it doesn't then it becomes a pain to find out what's going on and to develop the functions further. Interactively I can just test out each function incrementally and vary the parameters on the fly as well as build in some diagnostics within seconds (really). For instance, right at the moment I am talking to the accelerometer chip and it only took a few moments to type two one-liners that provide basic access to the guts of the chip so I type in a few different parameters and see what happens. So what's a servo or sensor library anyway, it's just a few lines of code that are tacked into a program.
Peter, I always find it quick to write the initial bit of code to integrate with a sensor or a serial protocol. But then spend most of my time dealing with all the messy edge cases and error conditions. A good library usually has all those bases covered. But as you state perhaps Fourth's interactive nature makes extending to handle all the messy edges less painful. I should probably give it a try just to see.
Usually, one does not need the entire library, and only SOME of the edge cases ever come into play. If you have enough room for all permutations of every possible event to be anticipated in code, them its cool; but on a micro, usually there is less room and we only need to worry about the events that can actually happen. So code is smaller and to the point.
The servo code is in the download archive: up to 32 servos per prop, eight servos per counter, two counters per cog, two cogs total; assuming 2.5 ms max pulse width. We figure 16 servos on one cog would be about right if you want to use pins for inputs as well, and using the multi-prop link if you need more than 16/32 servos total. If don't have that many so I haven't tested any huge configurations, but mutli-prop allow unlimited pins and cogs.
Sensors are being added as they are implemented, mostly by caskaz the moment, but in theory anybody should be able to make a driver in the time it takes to read and understand the datasheet for any given part. When the final kernel release is done (next month) I intend to start in on this task for my projects.
Propforth CAN call SPIN, just as SPIN and any assembler function can work; but the interfaces to the actual spin OBJECTS are not standard. So you end up having to spend time "standardizing" your interfaces for objects, which is more work than using the spin as an example an just coding the parts you need in forth. Sal says it takes something like a tenth the time to "just do it in forth", but that's Sal.
@brian - thanks for the link. I am always worried that somebody is going to die and the work will be lost, like tears in rain.