Skip to content

Comment on Ask HN: Current state of programming embedded devices?parent

Comments

Generally for embedded work, you want to avoid any and all complexity as much as humanly possible. In most critical embedded programming its all statically allocated and has shallow call stacks (eg: a call depth of more than 8 is forbidden).

For devices that connect to the internet, I prefer a two processor approach where a very simple processor does the critical work (eg: being a thermostat), and a more general purpose processor (raspberry pi, etc) handles the human interaction (GUI or webpage) and uses your more standard programming approaches. This way if the main CPU suffers a fault, it doesn't make the device worse than useless as the simple processor is doing things like making sure the commanded temperature is not too hot/cold, the temperature actually is changing when the heat is on, etc.

With dynamic languages or even using dynamic memory you can run into unpredictable pauses that can literally cause things to catch on fire (see 3d printer extruder fires).

A good example of the lengths you go through for embedded programming is the JPL coding standard: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

edit: fixed grammar

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.