Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Embedded systems worst practices?

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!

  • like image 785
    Fred Basset Avatar asked Oct 30 '08 19:10

    Fred Basset


    People also ask

    What are the main challenges of the embedded systems?

    The challenges in design of embedded software have always been in the same limiting requirements for decades: Small form factor; Low energy; Long-term stable performance without maintenance.

    Is embedded systems dead?

    Embedded systems are dead in a historical sense – their software and hardware from 10 years ago are no longer with us. Somehow, they evaporated, probably passed away to a better world. In fact, they've been replaced by less intelligent software and more powerful hardware.


    1 Answers

    • 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....

    like image 83
    Dan Avatar answered Sep 28 '22 10:09

    Dan