anti patterns - Embedded systems worst practices?

Question

What would you consider "worst practices" to follow when developing an embedded system?

Some of my ideas of what not to do are:

Avoid abstracting the hardware layer, instead spreading hardware accesses throughout the code. Not having any type of emulation environment, having only the actual hardware to exe/cute on. Avoiding unit tests, perhaps due to the above two points Not developing the system in a layered structure, so that higher up layers could depend on lower layers functionality debugged and working Selecting hardware without considering the software & tools that will use it Using hardware designed for easy debugging, e.g. no test points, no debug LEDs, no JTAG etc.

I'm sure there are plenty of good ideas out there on what not to do, let's hear them!

question from:https://stackoverflow.com/questions/251413/embedded-systems-worst-practices

Answer 1

• Uninitialized exception vectors (you know, for the ones that "will never be reached")
• Say it with me: Global variables. Especially ones shared between ISRs and tasks (or foreground loops) without protection.
• Failure to use "volatile" where necessary.
• Having routines that DisableInterrupts() and then EnableInterrupts() paired up. Got that? Not RestoreInterrupts(), but ENABLE. Yeah, nesting.
• No GPIOs to toggle when testing.
• No testpoints on board.
• No LEDs or serial port for viewing run-time system status.
• No measurement of how busy/idle the CPU is.
• Use of inline assembly for all but the most dire of cases. Write a quick callout.
• Using for (i = 0; i < 1000; i++) { } to "delay a bit". Yeah, that's not gonna bite you in a hundred different ways....
• Not using const everywhere possible to preserve RAM and reduce boot time (no copying / init of variables)

I've got a ton more but that should get us started....