I'm making a pocket pc and I want to use Propforth
super_tnt
Posts: 9
I am making a pocket pc using an arduino with a screen and a Chatpad as a terminal, I want the propeller to interact with this via serial and I want to use propforth as it looks very interesting. I'd also like to extend with I2C capabilities since I will have a SRAM chip connected. I would also like to be able to send to my serial raw numbers as it has other functionality such as plotting pixels. I was wondering if you could answer my concerns.
Can I extend it with I2C capabilities?
Can I send raw data (non ascii) to my terminal?
Can I add new functionality into the kernel directly via modifying the spin document?
Can I extend it with I2C capabilities?
Can I send raw data (non ascii) to my terminal?
Can I add new functionality into the kernel directly via modifying the spin document?
Comments
Can I extend it with I2C capabilities? Yes, the propeller has I2C objects in the obex.
Can I send raw data (non ascii) to my terminal? Yes. The propeller can be programmed to handle a variety of serial formats.
Can I add new functionality into the kernel directly via modifying the spin document? Yes. The source code is available so you could add to or modify it.
the OP wants to use PropForth, not Spin and Obex.
Prof. Braino needs to reply for PropForth. But the fact that PropForth loads all the Cogs with a Forth kernel might get in the way of getting all the features wanted.
On the other hand, pfth Forth loads the Forth kernel in only one cog and there might be a clear path to having other cogs tasked with non-Forth code. This is a topic I've been pondering for awhile. Dave Hein would likely know.
Propforth will be perfectly happy to talk across a serial link.
Propforth already has I2C capabilities. Caskaz has been quite busy with I2C lately in the PropForth thread.
Sure, just use the word emit instead of . for example: '42 emit' sends a byte with a value equal to 42 out the serial port - the terminal program interprets this as a '*'
'42 .' converts the value 42 to the ascii characters 4 and 2 and sends those to your terminal, so it displays 42'
The very core of the kernel is written in Spin/PASM but the majority of PropForth is written in PropForth and should be extended in PropForth. As you develop your application or extend your kernel in forth, you save it while you work. If at some point, you decide you want to take what you have built and turn it into a new kernel, there is a build process you go through. This build process ends up creating a .spin file which contains the very core kernel in legible spin and then has hex representations of the forth dictionary as it existed when you ran the utility. Rather than building their own kernels, most people start with one of the standard release kernels and then add their extensions to create their application image in eeprom. You can also store your extensions in eeprom or on an SD card and when your Propeller boots, it can rebuild your application image from eeprom or SD card.
{Ignore this: This typical of forth systems, they are mostly extended in forth and not in the language native to the host processor. PropForth has been very determined to get to the point where it is as much forth as possible with only the smallest amount of Spin or PASM. I haven't checked on Tachyon or pfth lately to see where they are in terms of Spin/PASM code to forth code. For both of them, there still isn't a whole lot of code that is in forth versus Spin/PASM.- The last two sentences got very chopped up in editing}
What I meant to say is: This is typical of Forth systems, they are mostly extended in Forth and not in the language native to the host processor. PropForth has bee very determined to get to the point where the kernel is written in mostly Forth. If you go back to version 4.6, you can see a version with most of the core kernel written in PASM. Tachyon has always had a small PASM core and is extended in Forth. Pfth has been through several iterations and now has a PASM core and gets to forth extensions once you are beyond the core. It probably has the most PASM code to look at.
Since PropForth is your first choice and appears to support what you want, continue on.
Just an FYI, there are Tachyon and pfth for other alternative Forths on the Propeller. All are good. The style of support in all three is a bit different due to developer's personal style.
Excuse for barging in, I was surprised to come across this comment from you re Tachyon. There is 2K of kernel code which is written in PASM (of course), plus some itty-bitty modules (<18 longs each), the rest is all Forth, even the bytecode that is compiled in the Spin kernel using all those byte DUP,etc statements. As for Forth code I think I have mountains of it including the FAT32 virtual memory filesystem and network servers, with not one bit of PASM or machine code in any of it. The I2C was one of the first things I got up and running and there's no rocket science in it, it just works. Remember, one of my goals with Tachyon was so that other than the tiny bit in the precompiled kernel I would never have to code in assembler, Tachyon would be that fast, which it is. In fact, and more far more compact than PASM or C or even Spin.
Sorry, Peter, I think that last sentence fell victim to poor re-editing. I know Tachyon has a very small tight PASM kernel and then quickly goes to a ton of Forth for everything else...and I've looked at your forth code enough to know that. Pfth probably has the largest readable PASM kernel but still very quickly gets to Forth also.
I'll go fix that statement, I seem to have had a bad day communicating yesterday. can I have a "do over"?
Please barge in to keep me honest!