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:
echo 1o 1500u 0o >/dev/cu.usbmodem
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:
1o -- output high on the selected pin (LED pin by default) 1500u -- delay for 1500 microseconds 0o -- output low to finish the pulse
Other commands include:
200m -- delay 200 milliseconds
4a -- select pin 4 of port A
i -- input from the selected pin
p -- print data that the host can read
100{} -- repeat commands within braces 100 times
Putting these all together we get a program that samples pin A4 at 5 Hz and writes what it finds to standard out:
echo 4a100{ip200m} >/dev/cu.usbmodem
cat /dev/cu.usbmodemI'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.
Mon, 06/07/2010 - 21:02
Comments
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:
echo 4a100{ip200m} >/dev/cu.usbmodem cat /dev/cu.usbmodem
This opens the device as file descriptor 3 then runs the two commands in turn, first writing to 3, then reading from 3. — WardCunningham
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. — paul