Concurrency and multi-core MCUs (GA144) in my house monitor

My house monitoring system monitors lots of sensors. This suggests a multi-core approach, doesn't it?

The problem with (the current concept of)  multi-cores is that they are typically ruled by a monolithic operating system. Despite what goes on in each core, there is one single point of failure: the operating system. Plus, without core affinity, our code may be moved around.  In a 8 core Intel processor, you are NOT guaranteed to be running a task per core (likely, for execution efficiency, your task is load balanced among the cores).  Each core is beefy too. Dedicating a whole core to a single sensor sounds very wasteful.

This, I believe, is flawed think  in our current concurrency model (at least as far as embedded systems go).

I want multiple "nodes" for computation. I want each node to be  isolated and self reliant.  (I'm talking from an embedded perspective here -- I understand the impracticality of doing this on general purpose computers).

If I have a dozen sensors, I want to connect them directly to a dozen nodes that independently manage them.  This isn't just about data collection. The nodes should be able to perform some high level functions.  I essentially want one monitoring app per node.

For example: I should be able to instruct a PIR motion-sensor node to watch for a particular motion pattern before it notifies another node to disperse an alert. There may be some averaging or more sophisticated logic to detect the interesting pattern.

Normally, you would have a bunch of physically separate sensor nodes (MCU + RF),  but RF is not very reliable. Plus, to change the behavior of the sensor nodes you would have to collect and program each MCU.

So, consider for this "use case" that the sensors are either wired or that the sensors are RF modules with very little intelligence built in (i.e. you never touch the RF sensor's firmware): RF is just a "wire".  Now we can focus on the nodes.

The Green Arrays GA144 and Parallax Propeller are the first widely-available MCUs (I know of) to encourage this "one app per node" approach.  But, the Propeller doesn't have enough cores (8) and the GA144  (with 144 cores) doesn't have enough I/O (for sake of this discussion, since the GA144 has so many cores I am willing to consider a node to be a "group of core").

Now, let's consider a concession...
With the GA144, I could fall back to the RF approach.  I'll can emulate more I/O by feeding the nodes from edge nodes that actually collect the data (via RF).  I can support dozens of sensors that way.

But, what does that buy me over a beefy single core Cortex-M processing dozens of sensors?

With the Cortex-M, I am going to have to deal with interrupts and either state machines or coroutines. (although polling is possible to replace the interrupts, the need for a state machine or coroutines remain the same).  This is essentially "tasking".

This can become heinous. So,  I start to think about using an OS (for task management).  Now I've introduced more software (and more problems).  But can I run dozens of "threads" on the Cortex-M? What's my context switching overhead?  Do I have a programming language that lets me do green threads?  (Do I use an RTOS instead?)

All of this begins to smell of  anti-concurrency (or at least one step back from our march towards seamless concurrency oriented programming).

So, let's say I go back to the GA144. The sensor monitoring tasks are pretty lightweight and independent. When I code them I don't need to think about interrupts or state machines. Each monitor sits in a loop, waiting for sensor input and  a "request status" message from any other node.
In C psuedo-code :

while (1) { 
  switch(wait_for_msg()) {
    case SENSOR: 
       if (compute_status(get_sensor_data()) == ALERT_NOW)
          send_status(alert_monitor);
       break;
    case REQUEST:
       send_status(requester);
       break;
  }
}

This loop is all there is.  The "compute_status" may talk to other sensor nodes or do averaging, etc.
What about timer events? What if the sensor needs a concept of time or time intervals?  That can be done outside of the node by having a periodic REQUEST trigger.

(This, by the way, is very similar to what an Erlang app would strive for (see my previous post GA144 as a low level, low energy Erlang).

Now, the above code would need to be in Forth to work on the GA144 (ideally arrayForth or PolyForth), but you get the idea (hopefully ;-)

Multi-computers (GA144) vs multitasking (ARM) vs interrupts (8051/MSP430)

You've got a system to design.  It is a multi-sensor network that ties to a small, efficient battery run base station. The sensor nodes are straightforward. You start thinking about the base station:

I've got a barrage of data coming at me over the air at 433Mhz.  I have a simple 2 byte buffer on the SPI connected transceiver so I don't have a lot of time to waste on the MCU. I must be there to receive the bytes as they arrive.
Once I've received the data, it must be parsed into a message, validated, logged (to persistent storage) and perhaps correlated with other data to determine if an action must be taken. An action can also be timer based (scheduled). Oh, and I must eventually acknowledge the message receipt or else the sender will keep sending the same data.
Additionally (and unfortunately), the action I need to perform may involve dialing a GSM modem and sending a text message. This can take some time. Meanwhile, data is flowing in.  What if a scheduled event must take place and I'm in the middle or processing a new message?

Now, this is the sort of thing that you would throw a nice hefty ARM at with a decent  OS (maybe linux) to do multitasking and work queue management.  But, let's think a second... Most of what I've just described works out to a nice simple flow diagram: Receive data -> parse data into message -> reject duplicate messages -> log message -> correlate message with previous "events" -> determine if we need to send a text message -> send text messages at specific times -> start over.

Each task is pretty straight forward.  The work is not CPU bound.  You really don't need a beefy ARM to do each task. What we want the ARM to do is to coordinate a bunch of concurrent tasks. Well that will require a preemptive OS.  And then we start down that road...  time to boot, link in a bunch of generic libraries, think about using something a little more high level than C, etc. We now have a fairly complex system.

And, oh... did I mention that this must all run nicely on a rechargeable battery for weeks?  And, yank the battery at any time -- the system must recover and pick up where it left off.   So, just having a bunch of preemptive tasks communicating via OS queues isn't quite enough. We will probably need to persistent all queued communication.  But I am getting distracted here.  The big system eats a little bit too much power...

Okay, so we get a bit smaller. Maybe a nice ARM Cortex-M3 or M0.  Okay, the memory size is reduced and its a bit slower than a classic ARM.  A preemptive OS starts to seem a bit weight-y.

So, how about a nice MSP430 (a big fat one with lots of RAM and program space).  Now start to think about how to do all of that without a preemptive OS (yes, I know you can run a preemptive time-sliced OS on the MSP430, but that is a learning curve and besides you are constraining your space even further).  Do you go with a cooperative OS?  Well, now you have to start thinking about a states... how do you partition the tasks into explicit steps?  At this point you start thinking about rolling your own event loop.

So, then there are the interrupts:

Oh, I forgot about that.  The SPI between the MSP430 and transceiver. The UART to the GSM modem. And the flash. Don't forget the persistent storage.  And  check pointing, the system needs to start where we left off if the battery runs out.

Okay, you are getting desperate. You start thinking:

 What if I had one MCU (MSP430, C8051, whatever) dedicated to the transceiver and one dedicated to the GSM modem.  The code starts to get simpler.  They'll communicate via the persistent storage.... But, who handles the persistent storage?  Can the transceiver MCU handle that too?  

This is where thoughts of multi-computers  come in. Not multi-cores (we are not CPU bound!), but multi-computers.  What if I had enough computers that I could dedicate each fully to a task? What if I didn't have to deal with interrupts?  What would these computers do?

- Computer A  handles the transceiver
- Computer B  handles logging (persistent storage interface, indexing, etc)
- Computer C  handles the GSM modem (AT commands, etc)
- Computer D  handles parsing and validating the messages
- Computer E  handles "scheduling" (time based) events
- Computer F handles check pointing the system (for system reboot recovery)
etc etc etc

This is where I start really, really thinking that I've found a use for my GA144 board: Performing and coordinating lots of really simple tasks.

It becomes GA144 vs ARM/Cortex + Linux.

Now if I can only figure out how to do SPI in arrayForth...

Inspiration... Knuth & TeX

My interests are odd (for a computer geek). I don't think I'm retro, but I've learned Ruby, Lua, Erlang, ML, OCaml and a bit of haskell in the the past 7-8 years (yep, I first picked up on Ruby in 2000). I really haven't learned a new language (or done any real programming in the above languages) in the past 4 years.

I'm interested in [La]TeX again. A couple of posts ago I mentioned working on AFT. That could be fun, but (if I had the CFT) I'd rather hack around with TeX. In particular, I am interested in learning MetaPost (look it up). There is a nice $50 LaTeX graphics book that covers MetaPost.

So, I am thinking to myself, wouldn't it be fun to do some hardcore typesetting? (Remember, my interests are odd.)

Fundamentally, I love the idea of TeX (and LaTeX). The end result is very tangible: A (potentially) beautiful typeset document. Maybe make a book out of my kids' artwork or something. TeX (and LaTeX) is a complex enough system that it would be fun just to get lost hacking in it.

Emacs is a large hackable system too, but the end result is some editing tools.

Unix is a large hackable system, but the end result is doing some process/text manipulation.

With TeX, the end result is a piece of paper. A well typeset piece of paper.

AFT Stuff

It's been a couple of years since I've done anything with AFT. I have a few ideas I've wanted to implement for a while, but I am tiring with mucking with the core of AFT and causing distress with any of my (few) users who wonder if they should upgrade. Sometimes a new feature may break old stuff or sometimes I roll in fixes with the new features.

As far as I can tell, AFT users install the version of AFT current to when they discovered it, use it and then resist upgrading (why upgrade when the tool does what you want)?

So, I am going to freeze AFT against any new features and add features by way of AFT add-ons.
These add-ons will be separately download-able and work with the AFT you have installed.

Here are some of the potential AFT add-ons:

• aft-indexer -- Create an index on an AFT file against words in a separate document, write out a new AFT file that includes AFT markup for an index and run AFT against that.
• aft-fixtabs -- Take an AFT document and smartly fix any tabstop errors. Output a new AFT document with tabs or N spaces for tabs.
  
• aft-ft -- Convert "free text" (somewhat intelligently) to AFT format.
• aft-simple -- A newer, simpler markup format (influenced by lessons learned) that produce standard AFT output.

The add-ons will be written in Perl or C and conform to AFT's current policy of not requiring any additional Perl modules outside of a standard 5.x distribution.

Idea of the week #1: Scramble Box

This would be a small handheld device powered by a AAA battery that has 1 SD slot, two buttons and 1 tri-color LED.

Let's say you've just taken some prize-winning pictures and want to "secure" the SD card from copyright thieves.

You just pop in the SD card, press the "scramble" button and all content on the SD card is encrypted (in place) using AES-256. The LED lights yellow while this is happening and then turns green when done.

(The key was crafted by you and programmed into the device earlier by putting it into a file called "CFG/KEY.CFG" on a blank SD card).

When you want to unscramble the SD, you pop it in and press the "descramble" button. The LED lights yellow while this is happening and then turns green when done.

The device holds onto the "key" in flash memory. You can use a different key anytime by placing CFG/KEY.CFG on either the enrypted or yet-to-be-encrypted SD card. At the end of encryption/decryption the CFG/KEY.CFG is securely deleted (don't want to store keys in the clear, now do we?). If the CFG/KEY.CFG is supplied on a blank SD card, the flashed key is changed.

This is less secure (if someone steals your Scramble Box AND your encrypted SD cards then they can decrypt the cards so as long as they were encrypted with the currently flashed key). However, this at least allows encryption/decryption to occur without creating the key file
(so you can go directly from camera to Scramble Box).

Now, photos are probably not the best use case here. A better, although less dramatic, example would be to put a bunch of "important" documents on the SD card and run it through the Scrambler.

However, since we are just using a fairly standard AES-256 technique (CBC w/ CTS), you could always do the encryption/decryption on a PC (with the right software).

In this case, the Scramble Box can be used for batch encryption/decryption.

Oh, and for usability, the key is a simple password/passphrase that is run through a hash function, so you don't have to memorize a 32 bit key ;-)

Cutting Code in a Coffee House

I need to remind myself that its all about creative problem solving. The Web and internet is all just a facade. Software is all about a manifestation of concepts. It's a tool for creative thinking. If you can web-enable it then you are trendy.

While doing embedded development, I am limited by what can be physically rendered. I can only get things smaller up to a point. I can only do what physics deem possible (for today at least). I can be creative, but I can't fly.

Current thinking in Web technology threaten to clip my wings too. I left IT development for the embedded world because I felt bogged down by XML, HTML and the Web programming juggernauts (Java, Javascript, Ruby, etc).

The effort of putting things on the Web didn't seem all that sexy anymore.

The effort of building complicated backend servers was no longer appealing.

Building embedded thingies gives me some immediate satisfaction. People use the stuff I build. I can measure the impact. It's real. It is physical. It has a form.

But, I kinda miss pure software. Coding in coffee houses is fun. Developing something useful while sipping on coffee and eating sweet breads (doughnuts, danishes, pie, oh my) is heaven. I just need an idea.

At times, when I got wrapped up in just hacking for the sake of hacking (e.g. getting awk/ksh/bash to do things they really weren't meant to do), I didn't feel like I was contributing much. Hey, I was a member of the language-of-the-week club (Erlang, Haskell, ML, etc)!

In reality, the languages I am the most productive in has been (in no particular order): C, Tcl, Awk and Perl. I've built production systems in Tcl/C and have written my only contribution to open source in Perl (see AFT). So, why do I insist on learning new languages? Why can't I just cut code in what I know best?

I need to take the time to visit a coffee house. Just me, my laptop and some ideas.

(Simple) Single Wire Protocols

My current favorite MCU is the MSP430. In particular, I like the ones that stretch the longest lifetime out of small batteries (like a CR2032 coin cell). Unfortunately, there aren't a lot of "communication" options for such a low power design (think: how do we get logged data out of a tiny low power processor?). RS-232 is too heavy, SPI/I2C is too complex, Bluetooth and other RF is too expensive (money and power-wise).

How about a simple single wire protocol?

Dallas/Maxim has such a protocol (called One-Wire) that is very interesting, but its very proprietary (you can't legally create a slave -- they reserve the right to be the sole provider of slaves that are compliant to the protocol). Among other things, this protocol supports multiple slaves and can even be used to power them. You just need a single wire (normally pulled up) and a common ground. The single wire is used for *all* communication (bi-directional).

I'm looking at doing something similiar to this, but greatly simplified: Only one slave supported.

(Random) Copious Free Ideas

A few random ideas for someone's Copious Free Time: (All of these projects involve very low power circuits -- the idea is that these things will run a long, long time without changing batteries).

Cold Bot

Augment a Roomba (or iRobot Create) with a temperature sensing parasite that navigates the Roomba to the coldest spot(s) in a room. If the temperature sensor was mounted on a small probe/arm, then you could pin point insulation leaks. The parasite also controls the power to the roomba thereby extending runtime by shutting the roomba off when the coldest spot has been reached.

For extra credit, make it a warm bot, place a gold fish bowl on top and let it take the fish to the warmest part of the room ;-)


Temperature Throwies


Tape a MSP430F2012 to a coin cell battery and use the internal temperature sensor to log temperature data to its internal flash. Make a bunch of them and place them in parts of the room or house that you are interested in monitoring for temperature trends. Create a single wire interface (data) to transfer data to a collector. The collector has two probes (ground and data) that you touch against the sensor in order to transfer logged data (along with an associated sensor ID).

Plot collected data on a PC.

Mom, my little sisters are messing with my stuff!

Couple a tilt sensor (accelerometer) with an MSP (or AVR) to make a small alarm. Use a piezo buzzer and coin cell battery. Make it small enough not to be easily noticed. Put on top of (or inside of) the item you want to monitor. If someone moves the item, the piezo screams.... for a long time.

Alternatively: Remove buzzer and use a watch crystal to build a fairly accurate RTC. Silently log the time the item was jostled. Collect this info later with single wire interface.

Never power down

Low power consumption computing is an interest of mine. While we have things plugged into AC that never really go off, they still consume a fairly high amount of power.

No, I'm talking about devices that never truly cut off. Or, at least, some portion of a device that never cuts off. How about a pico power AVR or MSP430 that runs off of a small coin cell battery for months/years. Running while quietly collecting data or waiting for a command from you to turn on it's host (we are still talking about parasitic computing here).

What useful things can we do actively under 1mA, while periodically sleeping at under 10uA?

... or is this more appropriate?

Someone at work (thanks, Rob K.) pointed out how maybe my "Biotrophic Parasitic Computing" idea is similar to the relationship between Remy and Linguini in the movie Ratatouille.

Does that sound more pleasant?

Biotrophic parasitism as a computing strategy

Biotrophic parasitism is a form of symbiosis between a parasite and it's host. The parasitic organism doesn't destroy it's host, but co-exists with it.

This presents an interesting strategy for embedded computing, or more precisely, the augmentation of existing embedded computing devices. This has, lately, become a consuming interest of mine. But, before I dive into that, here is something a bit more lurid.

This was the basis for my original line of thought: Parasitic fungi that control the behavior of the host. Unfortunately, this is not symbiotic, as the host is ultimately consumed or destroyed. I don't seek to replicate that type of relationship in my embedded augmentation experiments. But, outside of the grisly demise, it's pretty close to what I am talking about.

Consider this: You want to modify the behavior of your Roomba. You attach a microcontroller that feeds off of the Roomba's power and augments the Roomba's behavior through the "Open" serial interace. That microcontroller can be said to be parasitic. If the microcontroller is small enough (e.g. consumes little power from the host) and is well behaved (e.g. won't cause the Roomba to ignore it's cliff sensors), then it is a Biotrophic Parasite.

There are some microcontrollers (and of greater interest: microcontroller boards) that are well suited to biotrophic parasitism. For example: the Lilypad and this (3 for $10) board from TI, that can be programmed by this $20 development board.

Interestingly, I've been doing something along the lines of parasitic computing at my day job.

As I play with my iRobot Create (and forthcoming Roomba), I hope to exploit this technique further.

I like to call it Biotrophic Parasitic Computing.

Crypto for Everyone: Scripting and truly transparent systems

The idea of writing tools using standard unix scripting facilities (e.g. sh, awk, sed) may seem like a exercise for idle minds, but it has certain qualities that may make it beneficial to the end user at large.

That benefit is transparency.

For example, consider a simple blowfish encrypt/decrypt application. There are dozens of implementations in C, Perl, Tcl, Python, Ruby, etc. But, each comes with a certain amount of baggage. For Perl, Tcl et al, you have to make sure you have the right version of the interpreter installed as well as the right libraries. With C and C++ you have to make sure you have the compiler on hand with the correct libraries (unless you are willing to install an opaque binary).

However, a blowfish application that is written using always available OS facilities (under the assumption that your OS comes loaded with standard GNU utilities) is both portable and transparent. A blowfish implemented in gawk and bash/sh is very transparent. The user can see what is going on and even make modifications. Beyond that, adopting the "unix way" could make the usage of such an application transparent: it operates as a typical unix filter command where you can use pipes (and redirection).

This is an interesting idea (to me at least). Download blowfish.sh and you have an encrypt/decrypt solution (assuming you have gawk installed). Now, just use it. Pipe to it. Put it in /usr/local/bin (or some other convenient path) and use it as often as you would "cat" or "ls". It's not terribly fast, nor is it terribly efficient, but you can see what it does and can change it, play with it and make it do what you want it to.

This is all part of a copious free time deep thinking effort I've been up to. I am trying to figure out how to offer the simplest tools (simple in terms of installation, configuration and modification) to environments that lack such tools. It seems that everytime I (we?) think of an easy (usually GUI based) way of doing things, such as encryption, I (we?) get caught up in trying to provide the most sophisticated solution. Either that solution is never completed or simply doesn't "take".

Sure, blowfish.sh has vulnerabilities (mostly regarding typing passwords on command lines and buffering decrypted output), but for most users who do not do encryption, this offers some level of protection.

Now, you could argue that most "users" don't know how to use the unix shell or simply don't use unix (MS Windows is used by most of the computing world). But, you could wrap blowfish.sh in a BAT file or simply add a little more scripting to automatically encrypt samba mounted directories from a unix box (see my last post). This too sounds unsafe, but it is much safer than keeping your currently unencrypted list of credit cards, bank account numbers and passwords sitting around on a laptop drive.

Never underestimate the power of a small unix + lots of shell scripts

I've been wondering how to solve some home "IT" problems. You know, things like backup, password management, picture management, encryption of financial documents, etc.

I wonder what the combination of FreeBSD, bash (or ksh93!), gawk and samba would do for me.

Well...

If I could samba mount all of the primary Windoze harddisks (kitchen, guest room, etc), I could write a few scripts to do all of the dirty work. There is quite a bit of power and flexibility in having a smallish unix server controlling all of the MS beasts.

This would solve so many problems...

Mailsavant

My current CFT activities have been consumed by Mailsavant. Mailsavant is a dual purpose CFT project. On the one hand, it wants to be a haven for email junkies like me. On the other hand it is meant to be the manifestation of some ideas I have regarding writing software.

As a haven for email junkies, I am building Mailsavant to offer what may be regarded as a retro interface for the internet. I already use email to post/manage content to my other blog. But, I would like to leverage email as a replacement for other casual web site interactions. In particular, I am building an event notification service that can be fed primarily via an email interface (no clicking on calendars, when I want to be notified "next Tuesday at 3pm" of a particular event, I *say* exactly that in an email subject line. The system acknowledges that it received my notification request and then dutifully notifies me of that event as it nears.

The idea that such software would not only be useful, but well designed/implemented is the other focus of this CFT. I am taking a very minimalistic "Software Tools" approach to development. Most of the software will be written in a combination of AWK and (posix compliant) Unix shell (along with stock programs that come with Unix -- ls, grep, find, etc). My programming methodology will follow the "Unix Way" (small tools with each tool accomplishing just one thing). I have my own bizarre reasons for doing this, one of which I want to avoid software bloat and *seriously* contemplate how to build an internet service from scratch with no preconceived notions or shortcuts.
Yes, everything will be written in AWK, including the SMPT mail server and mail delivery agent. And it will be built to be robust and stable (with decent performance too).

Very few open source libraries will be utilized. I expect the calendaring app will take less than a couple thousand lines of code.

Stay tuned.

Tiny, tiny interpreter

I've yet to find a suitable scripting language for the Turtle. Its probably about time to consider rolling one of my own. I will probably use Tcl (circa 6.7) as a model. Rather than be "string" based, this language will be "array of byte" based, which will require some additional parsing. However, parse-on-the-fly model of early Tcl will be used (i.e. no intermediate byte code, no complex parse tree).

(Re)Kickstarting the Turtle

I've been taking a break from the Turtle (the iCreate robotic platform). But, now I'm trying to get myself back into the groove.

The way my mind works: I'm not motivated very much by hobbyist pursuits. That is, my CFT is usually grounded in building something practical. This is not a criticism of the wonderful Maker mentality. It's just that I don't seem to possess that gene (the one where you hack/make for just the intellectual gratification).

Now, mind you, when I draw or paint I am doing it solely for my own gratification. But, these days, with such limited CFT, I tend to want to make stuff that has some practical purpose (even if it is just to further my knowledge -- so I can do greater things). Maybe its my 40 year old brain screaming "do something useful".

I am working on some C functions to allow the AVR chip to control the Turtle. Of course, there is nothing special about this. I just really need to get something running so I can start programming the Turtle to do something "interesting".

Over the next few days, I need to determine what "interesting" is.

BLOGnBOX

I've been spending time bouncing between here and BLOGnBOX (a blog about blog software).

I've obviously have too much Copious Free Time ;-)

Simplicity

Software is tricky stuff. I do it for a living. Integrating lots of open source code is very tricky stuff. Nothing ever quite configures the way you exactly need it.

Circuit design and soldering is tricky stuff to. Even breadboarding gets tricky when you have to hunt down that 48 ohm resistor and mail order it. Then, half way through the delivery time you realize that you need a 22pf cap too.

I'm going to try and minimized the tricky stuff for my iRobot (turtle) hacking. Where I can buy a "module" I will (rather than code up work-a-rounds or do any major soldering).

For example, I decided to go with a simple ATmega128 board rather than the butterfly. Why? Well, the butterfly already required me to solder header pins (for UART, JTAG and ISP to start). Plus the UART has a voltage converter (14v RS232) where the turtle wants TTL level serial. I would have to hack the butterfly (either with solder: put another level converter in or through software: utilize the SPI ports for UART). Hacking the butterfly was starting to look ugly.

With the ATmega128, so far everything is about jumper cables. This is simple and clean. I should be able to just hook it up directly to the turtle.

Now, regarding software...
I want the turtle's brain (the ATmega128) to be able to take instruction from files on an SD card. I need an SD card holder that has header pins I can connect to the SPI on the ATMega128. Okay, that was simple. But... How do I interface the SD and 128? Well, I need an SD driver and a FAT file system. There are some free implementations out there (of varying quality), but the real question is whether or not I want to take the time to "port and integrate" as well as if I want to suck away a significant portion of my precious 4K RAM (on the ATmega128).

Sigh. Money to the rescue? I am looking at this. It does everything I would normally do on the ATmega128 (regarding filesystem and driver mgmt). I have to think about this. Simplicity = Money? Complexity = Time/Effort?

The Butterfly has been set free.

The Butterfly will be freed to work on other projects. The new brain for the turtle is an ATmega128 from MicroController Pros:

Alternates to the Butterfly

Creating a decent DSL that consumes no more than 1K RAM is a challenge (for me at least). Certainly coding the runtime/VM in C adds to the challenge (and bloat).

However, all I really need is a looping facility, conditionals and some primitive form of global variable creation (1K is not a lot of space to get fancy and do closures, recursion and other forms of state capture).

First, thing is first: I need to study the iRobot Create Open Interface and see what kind of commands I need to send and responses I need to react to.

In the meantime, I stumbled upon this ATMega128 board. Nice price, more memory (4K RAM) and perhaps more suited to my task than the Butterfly.