There is much accumulated wisdom in the embedded systems programming field as to how to correctly write a real time application. Examples of this wisdom could be found in the methodology of breaking up the application to a startup phase and a run phase, avoiding exiting the application, avoiding dynamic memory allocation and deallocation at runtime and more. There is also much accumulated wisdom in the programming field in general where a very important principle is ones control of ones software, as opposed to the other way around, and the notion of finding bugs and problems early whether that be in code writing, QA, deployment or beginning of execution.<\/p>\n\n\n\n
The combination of the two aforementioned elements forms the principle of critical condition testing at application startup. According to this principle you should put all environmental concerns as tests to be executed at the startup phase of your embedded application. Environmental conditions to be checked may include, among others, the following:<\/p>\n\n\n\n
All of these checks should be run in the first second or so of the software\u2019s execution and, contrary to normal wisdom, should cause the software to halt and not proceed with normal execution. The reasons for this scary tactic is that:<\/p>\n\n\n\n
These checks should also be written in a way which enables them to be easily removed when the system has stabilized, when it\u2019s environment has stabilized (like when the system moves to production) or in order to reduce boot time.<\/p>\n\n\n\n
This principle is especially important to real time and embedded systems programmers because of a few factors:<\/p>\n\n\n\n
There is much accumulated wisdom in the embedded systems programming field as to how to correctly write a real time application. Examples of this wisdom could be found in the methodology of breaking up the application to a startup phase and a run phase, avoiding exiting the application, avoiding dynamic memory allocation and deallocation at … <\/p>\n