I don't have any question related to coding. My concerns are about embedded systems programming independent of any particular programming language.

Because I am new in the realm of embedded programming, I would quite appreciate responses from those who consider themselves experienced embedded systems programmers.

I basically have 2 questions.

  1. Of the design patterns listed below are there any seen frequently in embedded systems programming?

    • Abstraction-Occurrence pattern
    • General Hierarchy pattern
    • Player-Role pattern
    • Singleton pattern
    • Observer pattern
    • Delegation pattern
    • Adapter pattern
    • Facade pattern
    • Immutable pattern
    • Read-Only Interface pattern
    • Proxy pattern
  2. As an experienced embedded developer, what design patterns have you, as an individual, come across? There is no need to describe the details. Only the pattern names would suffice. Please share your own experience.

I believe the answers to the above questions would work as a good starting point for any novice programmers in the embedded world.

closed as too broad by user22815, durron597, GlenH7, user40980, gnat Aug 22 '15 at 5:34

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    After years of RT/E experience I can proudly conclude that I don't know half of these patterns even by name. Yet, I'm likely to have used most of them. Don't appreciate people who are focused on patterns rather than doing their work. – littleadv Oct 7 '12 at 6:25
  • 1
    Thanks littleadv. Knowing patterns by names, or even knowing patterns at all, is not a requirement. But it is a fact that patterns are direct results of best practices done by experienced designers. So, knowing patterns could help novices get some insights on best practices. I didn't say that each of the patterns listed by me is used in the embedded world. I just asked if any. The purpose of my questions was to gain design "wisdom" from "wise" embedded programmers who are willing to share knowledge. – softwarelover Oct 7 '12 at 7:13
  • I believe that you should use patterns that address and solve the problem in front of you, not that littleadv told you he used once. I cannot see how knowing that others used patterns helps you in making a decision what to do. – littleadv Oct 7 '12 at 7:40

Embedded Systems Growing, Expect Broad Pattern Support

As embedded systems start to have more memory and processor available, and shift from bare metal, to real-time-kernels, to embedded versions of Linux and Windows or even to Android, I suspect they will pick up all these patterns and more.

Pattern Limiting Factors

Not sure how to make a table, but your list could be evaluated for suitability to be implemented on bare metal, with an RTK, or with an OS. There may be variations dependent on computer languages, with assembler or embedded C++ potentially being restrictive, C lacking object orientation to facilitate some of the patterns, and C++ (or its features) being either unavailable or prohibited by coding standards like MISRA.

Coding Standard and Real-Time Interaction with Patterns

Some embedded systems projects forbid use of dynamic memory. This puts a real damper on some of the patterns. Others may either hurt or help with the amount of memory required. Use of managed code techniques can introduce unwanted latency during garbage collection.

Patterns as a Starting Point?

I believe the answers to the above questions would work as a good starting point for any novice programmers in the embedded world.

I think this statement is a bit of a jump. Patterns are something of a meta-concept and are no substitute for down and dirty details like memory maps, programming peripheral devices like timers, uarts, SPI, I2C, ATOD/DTOA, PWM, etc. or creating interrupt services routines. If you are using an OS, you will need some kind of board support package. If you are using COTS, you need to evaluate which products.

If you are doing custom hardware, there is interaction with electrical engineers and some training to cope with reading schematics and reading (or maybe writing) data sheets and theory of operations documents. Using test equipment like Oscilloscopes, logic analyzers, JTAG or In-Circuit Emulators and IDE based cross development tools from Windows, Linux or even Mac.

Embedded Systems On Stack Exchange?

There was an Embedded Systems site for Stack Exchange that was in the Commitment stage in Area 51. It was closed due to a two year time limit. There are several embedded related proposals including a beta for Raspberry Pi, a BeagleBoard with two followers, and an Arduino proposal that is also closed.


There is a procedure for reopening or reproposing a site. If anyone is up for it, let's give it a try.

Not the answer you're looking for? Browse other questions tagged or ask your own question.