I was somewhat thinking how it would seem fairly easy in pascal, but then I= started hashing things out and had to wonder a few things. 1. Your code w= ill be in rom/EPROM/EEPROM, and you don't want someone stealing your code. = So where will the script be stored? How will the user upload it? Memory = card? I could possibly write it in a unit, but then you would need pic pas= cal to use it. If I wrote it like a program, the only way it'd be valuable= to you is if you use one pic to interpret the script and the other to do w= hatever you wanted to do.... I could actually see it having potential to ev= en market something like that. Put a memory card slot and pic chip on a ca= rd with pins to interface to your main board, and allow you to mount it on = one side of a plastic case, and run a ribbon cable to your board. =20 -- KF5QEO John Guillory westlakegeek@yahoo.com Cell: 601-754-9233 Pinger: 337-240-7890 Google Voice: 601-265-1307 > On May 28, 2014, at 7:59 AM, Isaac Marino Bavaresco wrote: >=20 > Em 28/05/2014 08:58, Byron Jeff escreveu: >> Actually this sort of changes my mind on it (which is why I prefaced the >> entire statement with "may or may not" to begin with...). Since tokens w= ere >> in a different space than values, it's trivial to determine that the fir= st >> token after an end is a variable if the top bit is not set.=20 >>=20 >> That would make the LET redundant, and clearly occupying valuable space. >>=20 >> BTW I too wish that I had come across FORTH early on instead of 6 or so >> years ago. I'm in the process of putting together a completely self host= ed >> FORTH development system for the PIC24F series of chips. It would have >> saved me the trouble of trying to write my own tokenized C-like >> cross-compiler oh so many years ago. >=20 >=20 > I too am in a pursuit for some sort of interpreted/scripting language > for embedded systems for a long time. >=20 > My motivation it to allow the users of my boards to customize their > operation or write their own routines. The problem is that I don't want > them to be able to run native code because it would allow someone to > steal my own code. > That protection could be done with dsPIC's CodeGuard, but it is not > available for other platforms, and I don't know how secure it is indeed. >=20 > Some years ago, I tried XPL0 (). It is a language > created in 1976 by Peter J. R. Boyle and maintained by Loren Blaney. > There is a compiler that generates 80x86 code and another that generates > a psudo-code called I2L. The original I2L interpreter was written in > 80x86 assembly and I wrote a very portable new one in C to use in my > boards. The performance was acceptable, although not great. > It worked, but I wasn't satisfied with the fact that it is one more > language to be learned and it is very obscure. That would prevent its > adoption by my customers. >=20 > I'm working now in a Thumb emulator written in C, that can be compiled > for a lot of platforms (even 8-bit, although the performance would be > awful). This emulator creates a virtual ARM processor (Thumb1 > instructions only) that won't allow any access outside its private > memory pool. System calls, common library functions and other predefined > operations are implemented natively and called with the Thumb "svc" > instruction. >=20 > I managed to convince the ARM-GCC to generate code for this virtual > processor and it seems very promising. The user's applications can be > written in any language with a compiler that generates Thumb code. >=20 > Right now I don't have time to polish it, but I'm excited about the > possibilities. >=20 > Isaac >=20 >=20 >=20 >=20 > --=20 > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .