{"id":2113,"date":"2011-05-09T17:58:54","date_gmt":"2011-05-09T15:58:54","guid":{"rendered":"http:\/\/www.final-memory.org\/?page_id=2113"},"modified":"2011-05-09T17:58:54","modified_gmt":"2011-05-09T15:58:54","slug":"dos-and-do-nots-for-developing-embedded-systems-software","status":"publish","type":"page","link":"https:\/\/www.final-memory.org\/?page_id=2113","title":{"rendered":"DOs and DO NOTs for developing Embedded Systems software"},"content":{"rendered":"<p>I have compiled a simple list of DOs and DO NOTs. \u00a0They should help developing solid software for small scale Embedded Systems. I also plan to write a more elaborate article or even book about this subject. It actually contains a couple of issues and ideas that I collected over the last 3 years since leaving university.<\/p>\n<h2>DO<\/h2>\n<ul>\n<li>Design your software to use independent software modules<\/li>\n<li>Design software interfaces to be portable and movable (e.q. allow a different module to implement it without having to change too much code)<\/li>\n<li>Design the software to be hardware independent<\/li>\n<li>Hide hardware definitions behind a module that can be exchanged as a whole (a module LCD and a module OLED which both implement a \u201cDisplay\u201d subsystem)<\/li>\n<li>Document all interfaces between module<\/li>\n<li>Typedef all structs and enums in use<\/li>\n<li>Use meaningful status and return codes<\/li>\n<li>Use state machines whenever useful<\/li>\n<li>Use enum types for everything that is not a continuous measurement including status codes<\/li>\n<li>Use structured data and organize all data that belongs together into structs<\/li>\n<li>Limit code per function\/method to fit onscreen<\/li>\n<li>Design all software modules to use a common API and call structure (e.q. Module_Init(), Module_Cyclic() and Module_GetXYZ())<\/li>\n<li>Document the assumed timing for a task or process<\/li>\n<li>Use C99 types for data<\/li>\n<li>Hide compiler specifics behind macros<\/li>\n<li>Use the keyword static<\/li>\n<li>Use the assert macro while developing for a SIL or unit test<\/li>\n<li>Prototype the software independent of the actual target hardware and test it on the PC before trying it on actual hardware<\/li>\n<li>Document every behavioural aspect of the software<\/li>\n<li>Follow a generic code design pattern that defines nomenclature of values and functions, source code style and usage of keywords e.q. the Embedded C Coding Standard<\/li>\n<li> Use static code checking tools like PC-Lint often<\/li>\n<li> Separate code and data \u2013 defined default data should reside in a separate data module, e.q. device definitions<\/li>\n<\/ul>\n<h2>DO NOT<\/h2>\n<ul>\n<li>Mix multiple functionalities into one software module, write one module per defined functionality<\/li>\n<li>Use ANSI C default types unless necessary (e.q. calls of the stdlib)<\/li>\n<li>Expect the software to behave correctly, assume fault states when ever possible<\/li>\n<li>Use global variables, provide access functions instead<\/li>\n<li>Write for a specific microcontroller or target board &#8211; expect that the hardware might change<\/li>\n<li>Use fix values for controlling timing, allow the user to configure any timing requirements<\/li>\n<li>Use magic numbers, provide symbolic configuration constants instead<\/li>\n<li>Assume that the source code is enough for documentation<\/li>\n<li>Rely on any state and introduce failsafe states wherever possible<\/li>\n<li>Ignore compiler warnings<\/li>\n<li>Use master include files, only make interfaces available to a module that are necessary<\/li>\n<li>Omit testing<\/li>\n<\/ul>\n<div id=\"facebook_like\"><iframe src=\"http:\/\/www.facebook.com\/plugins\/like.php?href=https%3A%2F%2Fwww.final-memory.org%2F%3Fpage_id%3D2113&amp;layout=standard&amp;show_faces=true&amp;width=500&amp;action=like&amp;font=segoe+ui&amp;colorscheme=light&amp;height=80\" scrolling=\"no\" frameborder=\"0\" style=\"border:none; overflow:hidden; width:500px; height:80px;\" allowTransparency=\"true\"><\/iframe><\/div>","protected":false},"excerpt":{"rendered":"<p>I have compiled a simple list of DOs and DO NOTs. \u00a0They should help developing solid software for small scale Embedded Systems. I also plan to write a more elaborate article or even book about this subject. It actually contains a couple of issues and ideas that I collected over the last 3 years since &hellip; <a href=\"https:\/\/www.final-memory.org\/?page_id=2113\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;DOs and DO NOTs for developing Embedded Systems software&#8221;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":79,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-2113","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/pages\/2113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.final-memory.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2113"}],"version-history":[{"count":3,"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/pages\/2113\/revisions"}],"predecessor-version":[{"id":2116,"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/pages\/2113\/revisions\/2116"}],"up":[{"embeddable":true,"href":"https:\/\/www.final-memory.org\/index.php?rest_route=\/wp\/v2\/pages\/79"}],"wp:attachment":[{"href":"https:\/\/www.final-memory.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}