Industrial Product: Forth + Bare Metal + Cortex M vs C++ Linux + Cortex A

File this is in the category of "spending way too much time thinking rather than doing"...

This is a long post about building an "Industrial Strength" product.

I sit poised between rebooting my "Home Alone" Elderly monitor using a micro-controller  or a microcomputer based solution.

It isn't a very sophisticated setup: A few PIR motion sensors, a water detector, a magnetic switch for door open/close detection and a means of notifying me when something interesting happens (e.g. mother-in-law wanders out of the house when we are not at home, is up in the middle of the night, left the water running, etc).  The notification method is still "up in the air": Do I uses a GSM modem to send SMS to my smartphone or do I maintain an Internet connection and send it email?

I have previously implemented a prototype in LuaJIT and ran it on a small form factor PC (using off the shelf X10 RF sensors).  It sent the data to a cloud server and notified me of events via email. You can read about it in my other blog: http://eldermonitor.blogspot.com/.  This prototype is too heavy (small form factor PC + cloud services).

So, now, for the "make it lighter" reboot, I've been looking at the very interesting A10-OLinuXino-LIME (something of a more industrial quality Raspberry-Pi).  Industrial is the enticing bit. I want this thing to work. I don't want to design my own board (yet). I would like the prototype to work and work "for a long time".  This isn't to say that the Pi wouldn't, but I've had very good experiences with Olimex boards when doing embedded stuff at my day job.

But, here is the thing: Software.

Debian is stable (and used quite a bit in the embedded and server based arena), but is this LinuXino Debian build solid?  I don't know.  I do know that this stuff is still mainly "enthusiast" supported.  For this project, I am not an "enthusiast". It must work.

(An aside: If it "must work", how can I rely on X10 RF stuff?  I've run the sensors for over a year now in my house and they are still going strong.  I haven't had to change batteries either. They aren't sophisticated, but they seem to work for the long haul -- at least for now.)

So, here I am, writing modern C++11 code on my 64 bit i5 dual core laptop and planning to recompile (port?) it to the 32-bit ARM (Cortex A8) ... and thinking... will this thing work reliably?

With the C++ I am thinking about abstractions and algorithms.  Am I making something inherently simple more complex?

Do I really want a full blown Linux here? Will it run for a year without fail (or crash)?

So, I sit here at my workbench and I am comparing the A10-OLinuXino-LIME board (argh, what a horrible name) and the Freescale FRDM-K20D50M (Cortex M4) board and wonder if I am not going light enough.  Getting the USB based X10 CM19a receiver to work on the Cortex M4 is not trivial.  (I may punt and go for hardwired sensors for the time being). And, C++ on the Cortex M4 means either fighting g++  (ugh, the linker config) or paying >$1000 for a serious compiler.

I've got and old (still functional) MPE Forth Stamp Compiler working with the FRDM board. It isn't free but it is solid.  Solid is what matters here.

I have visions of a simple device that once configured (and installed) hums along doing its job for months (...years!) without concern for whether it gets stuck in a reboot (e.g. Linux runs out of space due to a logging issue, SD card corruption, etc) or whether my C++ has some subtle memory issue (e.g. modern C++11 looks down upon "new" and "delete" but can still run out of space by auto allocating objects on the stack).

Forth is, well, Forth. On bare metal, I can completely *grok* my development environment.  Porting MPE Forth to the FRDM board was a pain, but now I *understand* the FRDM board.

What am I trading here?  A modern C++/Linux design vs something that I know will work (and how it works).

I'm an old Unix hand (been doing it since the mid-1980s), but I don't know if I am comfortable with a home monitor running a community supported port of Debian. Too many unknowns?