The 8051 won't die... will it?

The 8051 8-bit MCU architecture was introduced, by Intel, in 1980. It is still in wide production by at least a half dozen vendors (including my fave -- Silabs) at prices as low as a half a buck.  My current favorite is the C8051F988 (currently used as the brains behind my sensor nodes). This MCU costs about $1.60 (for low volume purchases) and is essentially an 8-bit SoC.

The C8051F988 comes in a couple of packages, one of which is hand solderable. It requires no additional passive components (an internal oscillator can run at 25Mhz), but I usually throw a capacitor on the power supply pin and a 4K resistor pulls up the RST line.  It has a mere 512 bytes of RAM and 4K of flash (a beefier version can be had for around 1 dollar more). I program it in Charley Shattuck's MyForth, so the memory doesn't feel so constrained.

The C8051F988 has an ADC, internal temperature sensor, a UART, SPI, I2C, etc.  It executes 70% of its instructions in 1 or 2 clock cycles.

Here is the power specs (from the datasheet):

Ultra Low Power Consumption
- 150 µA/MHz in active mode (24.5 MHz clock)
- 2 µs wakeup time
- 10 nA sleep mode with memory retention
- 50 nA sleep mode with brownout detector
- 300 nA sleep mode with LFO
- 600 nA sleep mode with external crystal

I'm impressed. But, of course, why bother with this when an ARM Cortex blows it away? (Ultra low power consumption 32 bitters are starting to arrive.)

A couple of things keep me interested in this chip (and other 8051 variants), and that gets us to what this blog post is about.

First, look at the part count: For under $2 (hobbyist pricing): the 8051 chip, an (ebay provided) SOP board, a resistor and a capacitor.  I have the old Silabs serial ec2 programmer (for initial flashing of a forth bootloader) and use Silabs free programmer under Linux WINE.  No ARM I know of has this simplicity.

Second, and most interestingly, the 8051 architecture doesn't seem to want to die.  Its a relatively simple chip (low gate count) and can be easily implemented as an FPGA core.  When you want to do simple things, it is very handy. It is built into *everything*: Keyboards, microwaves, the new Bluetooth LE chips (like the popular TI CC254x chips).

Start taking stuff apart and you are likely to run into an 8051.

They don't want to die. Somewhere there are engineers who sniff at the new 32-bit Cortex M series (meant to replace those old 8-bit 8051/AVR/etc processors) and then get their job done with assembly or C code that has run solid for the past 30+ years.

Scale if you must, but don't forget reliability

My home sensor base station is using STOMP to transfer sensor node messages into an AWS cloud instance (running RabbitMQ).  I am using STOMP because I can't find an AMQP binding that supports SSL (outside of Java and Erlang).  Or, more to the point: the sensor base station runs Lua and my AMQP binding for Lua is with  amqplib (which doesn't support SSL).  My pure Lua STOMP binding runs over SSL. But I digress...

The STOMP client runs 24x7, pumping messages into the cloud hosted RabbitMQ at a rate of 2-3 messages per minute.  This is not a lot of traffic, but I expect it to scale.

In order to develop (and test) the "server/logic" side of the system, I am running the consumer of messages on my laptop (it connects to the AWS RabbitMQ as a consumer).  The consumer is also talking STOMP.

However, when my laptop lid is closed, all consumption stops. So, for example, overnight I can accumulate a few thousand sensor messages.  Firing up the consumer in the morning should just suck all those messages down and pick up where it left off. Unfortunately, there is a glitch (in RabbitMQ?) where after a few hundred messages (all ACK based -- fault tolerance, baby!) it stops receiving new messages and the remaining messages are marked by RabbitMQ as "unacked".  Restarting the consumer happily consumes a few hundred messages before the same glitch re-occurs.

This is a serious problem and I need to figure out if RabbitMQ is the culprit.  Interestingly, I found that by slowing down my consumption rate (read/respond every 100ms) the problem is fixed. Argh.  Well, that won't scale, now will it?

So, until I figure out what the real problem is, I'll keep consuming as fast as I can.  But, what about the unacked messages? Well, this is where "reliability" comes in.  By default, all of my consumers do timed reads. If they don't receive a message in 60 seconds, then they terminate. (I don't use RabbitMQ heartbeats. I have an "application" level heartbeat that makes sure the whole system flow is working from base station to cloud. This heartbeat fires every 30 seconds).   Failure is an Erlang technique. The consumers are written in Lua, but I did learn one thing from Erlang: Failure is okay, just plan your recovery.

So, once the process terminates, Ubuntu Upstart restarts it.  The result: The system recovers on its own from this bug.  The system continues to run.  The unacked messages are requeued and delivered.

Scaling is great, but don't forget reliability!

Using Forth to question the Status Quo

Whenever I face a  tough problem I try and break it down to the essentials.

Often using traditional methods only leads you to traditional solutions.  Sometimes traditional solutions are just fine, but what if you need something special?

This isn't about programming in Forth. It's about taking the Forth Approach. This means looking at the problem in a different way.  You can use your own favorite language, but consider the path taken (time and time again) by Chuck Moore (Forth's inventor). His chip designs are novel. His approach to problem solving is stunningly minimalist.  Go ahead and google him, I'll wait...

Sometimes is worth it to think; "What is the simplest possible way to do this?".
In my mind, simple doesn't (necessarily)  mean easy.

Consider designing a wireless temperature sensor.  You want to mount them in every room in your house. Now before you whip out your Raspberry Pi, consider three factors: Cost, Power and Size.  This sensor should cost under $20 in parts, be discrete enough to attach to a wall, and should run for at least 1 year reporting temperature once per minute.

Now, thoughts of Wi-Fi enabled Raspberry Pi (too power hungry and expensive) wane. How about something with Bluetooth LE? ($15 at best; no money left for the board, battery and other parts, plus you have to deal a fairly complex "standard").

I've discussed my approach a year ago here (Why Forth still matters in this ARM/Linux...). It basically describes a $7 RF transceiver and a $3 MCU (that requires only a couple of resistors and caps to function).  The MCU has a built in temperature peripheral.   I hand wrote an implementation of RC4 for a modicum of security. I've coded this all in Forth, but I could have used C. The implementation language doesn't matter -- the approach is inherently Forth-ish.

A year later and I still can't find anything cheaper.  The status quo says I should go to Bluetooth LE (or at least Zigbee). But, at what benefit?

Update:
Okay, this is an even cheaper RF transceiver (just $2.99, but in the crowded 2.4GHz band): http://www.ebay.com/itm/HopeRF-RFM73-2-4GHz-Transceiver-/251209604525?pt=LH_DefaultDomain_0&hash=item3a7d425dad

Complexity and the Future: Revisiting technological foundations of Smart Phones

Every once in a while it is good to sit back, take a deep breath and look at the state of things.

As technology hurls forward we accept building complexity upon complexity.

The Internet is very complex. Fine. I would call it "deeply" complex. In that manner, it is similar to an organism. However, it is based upon a very simple infrastructure called IP (Internet Protocol). Upon that we have a host of other protocols with the most pervasive being TCP.   From there, the complexity escalates rapidly.  But that's okay.  Underneath is TCP/IP and I can always grab hold of it -- it is the earth, solid and firm beneath my feet.

Now, my phone is very complex. A Smart Phone is  made up of a bunch of software. Let's consider Android. Underneath is a Linux kernel (but you can't normally touch that -- imagine floating about the earth just a few inches but never touching ground). On top of that there are processes, a VM, and a bunch of apps.  Oh, and off to the side is the actual phone stuff (sacred and untouchable).

Every once in a while the phone gets slow or needs a reset.  It is indeed a complex beast.

I'm okay with the Internet being unfathomable by a single mind, but my Smart Phone is headed firmly in that direction. So many things working together, so complex. But, unlike the Internet, my phone's software is not self healing. There is no notion of routing around bad processes or chips. When bad things happen, the phone is nearly useless.

What if I want to just make a phone call? Or perhaps send a text message.  Maybe all I want is to message someone over the internet or read my email?

What if we stripped a smart phone of everything but the communication essentials.

Nokia is trying to (re)find a niche. They are offering a new phone for the third world: http://www.nokia.com/mea-en/products/phone/105
This will sell for about $20 in the European market.  The standby time is 35 days.

If there were a bunch of these phones deployed with free text messaging, what could you do with it?
What if there was a slightly better alternative to SMS (larger payload). Or perhaps a multi-segment protocol on top of SMS that the phone could parse.

Why does the entry level into the 21st century Internet require a Smart Phone ($$$)?  Why can't I have a slightly dumber phone that plays well on the Internet?