Counter Point (Bluegiga BLE112: A Game Changer?)

After writing the last blog entry, a thought kept re-occurring: "Mission Accomplished."  You may have immediately caught on to the reference: President Bush's 2003 Mission Accomplished speech.

I certainly don't want to trivialize the aftermath of that speech (are we really done yet?), but  it does remind me of the faith we (the software community) place in abstractions and generalizations.

A scripting language onboard the BLE112 and so it will only take a few lines of code to do my sensors?  Sounds great.  But, there are no reports from the ground yet.  Is the scripting language stable? Are there bugs hidden in the implementation?  Are there subtle things that it does automatically that will bite me in the ass?

The same questions can be asked about Embedded Erlang. It sounds fantastic, and of course the first major Erlang deployment was indeed embedded (the AXD301 switch). But a lot has been added to Erlang and OTP since then. Is all of it good? Is all of it stable and proven?

This is not a criticism of BLE112 scripting or Erlang, but a reminder of why I went "low level" 6 years ago in the first place: The abstractions and libraries were killing me.

A thought: My Roku locks up every couple of months.  I have to hard reboot it.  I am guessing that it isn't a hardware problem nor a problem with the OS (linux?). Somewhere an app is failing.  My home sensor system can't do this. It must work 24/7 for as long as it is powered.

While Erlang has a great approach to fault tolerance, it is not the complete answer. You must intelligently use it's recovery features and you must avoid software faults to begin with.

"Not invented here" is preached against, but if you can't trust the provided tools, what do you do?

I'll have to see if Bluegiga's scripting is solid. But, what do I do if the sensors start silently failing weeks (or months) after deployment. How do I debug it?

In order to get my Erlang base station up and running I will need my Erlang code to interface with a serial port. There is no support in Erlang to do this.  I was going to write one (or use "netcat") to create a TCP bridge for the serial port and let Erlang talk to it. Will this eventually introduce subtle problems? How do I manage the bridge?  The Erlang approach says to expect that the bridge will fail and simply restart it (and resync the rest of the processes with it).  This is a smart approach, but with the "bridge" I have left the Erlang eco-system.

All of these issues nag me, and they should.  On the one hand, I think that the embedded world (mostly hardware types writing assembly, C and maybe C++)  is way behind the "high level programming" world in providing flexibility.  But with that flexibility, software folks have brought with them all of the little devils that come with high level programming.

Food for thought.