Pages: 1 
|
 |
|
Author
|
Topic: General questions about RetroForth, RxCore, etc (Read 2227 times)
|
jpn
Newbie
Karma: +0/-0
 Offline
Posts: 1
|
I'm new to Forth in general, and I'm thinking that retroForth might be workable into just the kind of thing I need. I tried looking through the forums here, but the banter is way over my head, so I'm hoping someone can let me know if I'm in the right universe here. First off, I have a device with a keypad, a basic LCD, and some LED blinkers. The actual device is more complicated, but this should be sufficient to get the point across.
I'm trying to keep this vague for a reason -- I have an NDA -- but I think I can manage to say that the device uses an ARM7 microcontroller with 64K of SRAM and 256K of Flash memory (program memory). It runs eCos. When the time comes, it won't be a problem to release any source code affected by open source legalities, but for now everything is a little sensitive.
What I ultimately want is essentially a Forth thin-client that accepts "compiled" Forth code (i.e. threaded code). Having a built-in interpreter as well would be a plus, but is not necessary. Each thread corresponds to some action that takes place on the device. For example, you could send the device a bunch of threads that blink the LEDs in a certain way and put some text on the screen. I assume I'd have to introduce some new words to the library to the tune of "blinkLED", "putonscreen", etc. The words would ideally link to device drivers that I have written in C.
So far it might seem kind of extravagant to use Forth here, but remember that I also have an input -- the keypad. With Forth I could potentially script blinking and display behavior based on different keypad input, and so on. If I were to do this in the typical fashion, which is to use a master-slave / command-response protocol, it can add a lot of transmission latency that some of the unlisted features of the device cannot afford.
If anyone would chime in and let me know if this kind of stuff is something that RetroForth is suited for, I'd be tremendously grateful. If so, I'll be happy to support the project, which will inevitably include porting to eCos and potentially writing an optimized binary for embedded ARM devices. Thanks!
|
|
|
|
|
Logged
|
|
|
|
Charles Childers
Administrator
Sr. Member
Karma: +2/-0
Offline
Posts: 745
|
RetroForth is probably not the best choice for your project. It is closely tied to the x86 processor; to support ARM would require a nearly complete rewrite. I have written a virtual machine that runs compiled token-threaded forth code in C. It's possible that this could be adapted for your project. If you want, I'll send you a tarball of it.
You might find Riscy Pygness (http://pygmy.utoh.org/riscy/), a port of PygmyForth to ARM, to be a better starting point. I haven't used it personally though.
|
|
|
|
|
Logged
|
|
|
|
batu
Newbie
Karma: +0/-0
Offline
Posts: 2
|
Hello Guys,
I am new to Forth language, and I find it quite interesting. I hope you can answer this. I have a book with some Forth examples and one of them is linked list creation. I see that linked list nodes are allocated from PAD, but I could not find anywhere how things get deallocated. In C it would be free(), but how about in Forth? DELETE? And if node gets deleted where it goes? Back to PAD? Does Forth have something like memory manager or GC? If Forth is used without underlying OS, how does memory management happens there?
Thanks in advance for your answers.
|
|
|
|
|
Logged
|
|
|
|
Charles Childers
Administrator
Sr. Member
Karma: +2/-0
Offline
Posts: 745
|
RetroForth 9.3 has malloc/free, like in C for dynamic memory. (Normal Forth allocations come off of a preallocated heap, this is done in both hosted and native versions). My other language, Toka, has a garbage collector.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
Pages: 1 
|
|
|
|
|
