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.Of the design patterns listed below are there any seen frequently in embedded systems programming? Abstraction-Occurrence patternGeneral Hierarchy patternPlayer-Role patternSingleton patternObserver patternDelegation patternAdapter patternFacade patternImmutable patternRead-Only Interface patternProxy patternAs 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.
Design patterns frequently seen in embedded systems programming
design patterns;embedded systems
Embedded Systems Growing, Expect Broad Pattern SupportAs 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 FactorsNot 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 PatternsSome 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.http://area51.stackexchange.com/proposals/15961/embedded-system-design-and-developmentThere is a procedure for reopening or reproposing a site.  If anyone is up for it, let's give it a try.