A friend at work pointed me at Mbed devices for real-time end of line work. I’ve been involved in work that used 68hc11 processors for that sort of thing (getting very long in the tooth) and I’ve looked at using AVR parts (cheap, dip packages and decently capable). PIC controllers also seem to show up frequently (but the small look I’ve taken at the PIC architectures doesn’t make me happy).

These are ARM Cortex-M0 devices with what initially looks like pretty decent support. As an outbound, real-time controller and a back-end in something like an RPi (for home stuff) these might be a better solution than the AVR chips.

I’ve had good results from building systems with the ‘quick twitch’ responses pared down to the smallest size reasonable and baked into small controllers and keeping the higher level control (that doesn’t have the real-time response requirements) back on a linux or windows based system. This keeps the complexity in a location where powerful development tools and more capable processors reside and makes development much simpler.

I’ve been looking at CAN as an intermediate communications bus for this sort of work as well. The SPI and I2C options work well for tightly coupled peripherals in the same voltage/signalling family but don’t extend well.

Ethernet is wonderful for larger scale coordination between components that are running relatively complete operating systems.

CAN splits the difference with a defined physical layer running differential signalling that provides common mode noise resistance and (probabaly…haven’t looked in detail) avoids ground reference issues. It is still low level enough to code directly to (unlike TCP where the stack gets a bit involved to do things right). It supports quite a few devices on a single connection and has a decent access arbitration mechanism.

I haven’t bought any parts to try playing with this yet, but it seems promising.