Hi guys, Looks nice, though I don't catch every details ! (is this about amforth: http://amforth.sourceforge.net/ ?) When I build a board/program, I almost always implement a Read-Eval-Print-Loop through serial, used to configure and act on the board. Kind of high level, program specific interpreter. Going lower (ie. close to PIC peripherals, I don't know exactly how much and how) can give a nice dynamic interpreter.
I'm not saying this can be used in serious application, I'm just thinking it can be fun to develop, hopefully fun to use, and can open nice opportunities (eg. a GUI to dynamically control a PIC), and may be of interrest for educational purpose. Cheers, Seb > Hi guys, > > I took a look at fifth, but only found one relevant hit and that was > an reference only to an article... > > This thread however inspired me to spend (spoil?) some time on this > concept again. I mentioned the huge footprint of the forth > interpreter. I now build a small forth interpreter with some basic > words and without the option to add words from scratch. It is running > now and is (with serial and i2c routines) about 13k in size. Not in > Jal but in C for Atmel, but this is mainly for practical reasons (test > code on pc first, a larger atmel board at hand). > > My idea is to add a finit state machine engine. All basic functions > (interrupts, serial comms, i2c comms with slave processors) is done in > C. At the top level, the FSM runs. The FSM consists of states, where > each state has multibple actions (onentry, onexit, dostate) and > multiple conditions (with a new state when true and oncondition > action). The forth engine is used for the condition evaluation and > actions. The fsm (fsm structure, forth code and some logical names) is > defined in an editor and converted by a perl script into data. This > data is loaded into an i2c eeprom. > And why forth? Since it is simple to build (got it up and running from > scratch within one day!) and can hande complex conditions and actions. > And it can be easily extended if required. > > Let me know what you think of this! > > Joep > > > 2009/5/7 [email protected] <[email protected]>: > > > > Hi Seb & Joep, > > I have more or less the same feeling as Joep, interperters are nice > > for flexibility and to test (hardware) without the need of a > > development environment. > > At Philips (where I work) , we mainly use a forth like language > > (called Fifth) to test new hardware (FPGAs, ASICS) > > In one point in time I've tried to port it to a PIC, but I ran in too > > much issue to make it usable (mainly footprint), so I switched to JAL, > > In my opinion the PICs 12/16/18 series are too small (both computation > > time and memory/storage space) to make it really usable > > for an interperter language to build serious applications. Therefore I > > think the focus should be on a good set of easy to use well documented > > libraries with lots of samples, improving the compiler/libraries for > > speed and footprint, and have an easy to use development enviroment. > > Albert > > > > > > > > > > > -- Sébastien Lelong http://www.sirloon.net http://sirbot.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
