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...