An interpreter need not be more than a case statement with a loop around it. I've written just such an interpreter for Teensy starting with a variation of Paul's USB Serial example. I'm finding it very handy. If I need a 1.5 millisecond pulse I would type:
This example uses three single letter commands, each proceeded by a sequence of digits that loads data that any command can use or modify. Here is what the commands above mean:
Other commands include:
Putting these all together we get a program that samples pin A4 at 5 Hz and writes what it finds to standard out:
I've put the project up on GitHub. Look for Txtzyme which means "text that catalyzes action". My fork there will be accumulating operations I find handy in my sensor network and, of course, as a utility device on my workbench.
Comments
Open the USB Device for Read/Write
An improved version of my second example would open the USB device once for read and write, rather than opening it separately on the two commands. The rarely used shell syntax would look like this:
This opens the device as file descriptor 3 then runs the two commands in turn, first writing to 3, then reading from 3.
end of file
Hi Ward,
I woke up this morning thinking about the end-of-file issue! Remember how only the "cu" device works, but not the "tty", because it requires modem-like control signals? Maybe if you made the device act more like a modem.... maybe (a big maybe) dropping the carrier detect or DSR or some other handshake signal might cause the "tty" device to generate an end-of-file indication which might work for "cat"... ??
Truth is, I haven't really explored that. All I know is the "tty" device is really problematic if the Teensy isn't generating those handshake protocols, which nobody does, and the main problem is it will stall during open() without the proper handshake signal from the device, unless you specifically set non-blocking mode when calling open(), which is easy in C but pretty much impossible from the shell.