As I look at eLua (on an mbed for one of my robot projects), my mind wanders... have I stumbled into another monolithic system approach?
eLua embedded systems are Lua and (maybe) some C. I like Lua, but am I just trading one language ( Forth, C, etc) for another?
This line of thinking keeps bringing me back to Unix. Under (traditional) Unix, I have a multi-process environment connected by pipes. I choose the appropriate language (or existing app) for the task at hand and glue it together with a shell.
Now, this would (most likely) be overkill for a small embedded device, especially in regards to power consumption. But, assume for the moment, that I had all of the Unix resources at hand and didn't concern myself with power consumption. What would my robot controller design look like?
I design and build GPS trackers during the day. I use C and (sometimes) Forth. I've thought about eLua, but I'd still have to write a NMEA sentence parser and fencing algorithm in a language not necessarily perfect for parsing. How would I go about doing this if I had awk at my disposal? Or grep/sed? Or... the whole unix environment tied together with pipes under a shell. Would something like BusyBox be a good foundation?
What is the smallest MCU (or embedded SBC) that I could run something like uCLinux and BusyBox on?
Could I do development under a fairly modest laptop Linux and port down to uCLinux and BusyBox?
Right now I am looking (again) at CSP (perhaps built upon Lua co-routines) as a mechanism for architecting embedded systems that integrate multiple (sensor) inputs. You can also build CSP upon Unix processes (and pipes). This is the way I've done it for 25+ years. Do I really need to cast my architecture into another monolith?
This is just me bring up Unix as a Programming Language again (but this time under the constraints of embedded computing)
No comments:
Post a Comment