Scripting during runtime

tuxman

I am now trying to make prop as a realtime processing engine for my current project, that receives raw UART, converts it to format acceptable by "host" connected via serial, while at the same time waiting for that "host" to eventually send packet representing which output lines to pull

I thought it would be nice if signals that repeat often and have the same outcome could be processed inside prop, but that would require some sort of scripting method, so that on bootup "host" could specify reactions beforehand, but how to do that in C or PASM?

ersmith

Forth is probably the best scripting language for the Prop; there are a number of implementations, the most active of which these days seems to be Tachyon Forth.

For scripting in C I've written two different small scripting languages: TinyScript and PropLisp. Both are easy to extend in C and quite small, but they're also pretty slow compared to Forth (although of course since they're extensible you can handle speed critical things in C).

PaulRowntree

To echo ersmith's comment, Tachyon Forth's 'scripting' is already built in, no need to create a parser etc, and it follows exactly the syntax of the existing code resident on the machine, with access all the way down to the base codes and all variables. I have written codes for my lab where I can get most of the code working at home, tweak a few top-level routines in the lab, then routinely send the commands via USB/serial to direct the instrument and collect results. Something goes awry ... open a terminal and interrogate the system as it runs.

DavidZemon

I wrote an app for the Propeller using C++ that did something similar. It was the slave in a master/slave configuration for running a pick 'n' place machine. The propeller drove seven stepper motors and some random GPIO for vacuum/leds/etc. The steppers each consumed a cog by themselves, so the remaining cog was in charge of listening over a serial line for commands from a PC or other more powerful board. I wrote a very simple, though proprietary and non-ASCII, protocol for that communication. Each message from the master to the slave was defined as 5 bytes (I think... don't quote me ) and the slave would respond with one byte response, either 0 for success or non-zero for error code. The first byte of the packet from the master would be the message type (allowing up to 255 different messages) and the next four bytes were the message body size. I don't really remember all the details for sure, but you can imagine how a reasonably simple messaging system can be built in this fashion. Use enums in both the master and slave code so that it's easier to read.

This is no where near as powerful or flexible as Tachyon or ersmith's TinyScript and PropLisp, but it's small, easy, compact, fast, and best of all, you don't have to translate your entire project to Forth .

JonnyMac

I don't know if this applies, but I wrote a simple text parsing object so that I could act on commands over a serial port, or even from lines read from a text file. I used text to keep it very generic, though for specialty projects like David's pick-and-place app I think that his strategy is the way to go.

I've attached a simple demo of the parser.

MJB

tuxman wrote: »

I am now trying to make prop as a realtime processing engine for my current project, that receives raw UART, converts it to format acceptable by "host" connected via serial, while at the same time waiting for that "host" to eventually send packet representing which output lines to pull

I thought it would be nice if signals that repeat often and have the same outcome could be processed inside prop, but that would require some sort of scripting method, so that on bootup "host" could specify reactions beforehand, but how to do that in C or PASM?

If you get a bit more specific we can show you how to start this in Tachyon
in just a few lines of code on top of an already existing Tachyon image like the EXPLORER ...

tuxman

Looks like DavidZemon understood the problem
So, current protocol prototype has 5 bytes for input address, same for reaction address.
But those are limited to <200 iops, while propeller is capable of at least 300.
I would like to have two features that would limit host dependency:
- preloading reactions from host (after program boot) so that prop would process most often used switch combinations on its own (some sort of lookup table)
- preloading chains of outputs (with timing)
I know forth has facilities to support such features, but then there would be a massive problem of integrating it into the rest of the system.
Also, i was looking into using remaining 4 pins and 2 cogs somehow, maybe there is a way of loading new code after the one from eeprom has loaded?