>>900505 (OP)
You want some advice on low-level embedded "safe" software?
0) Mil-Grade is bullshit, you may like to read some specs for atomic stations; always go for hard-coded real time or simple interrupts.
1) stop with this commie bullshit; you may appeal to some eastern-slav old fucks, but they still don't know everything and fail miserably most of the time.
2) Misra-C requires you to buy it (but you may pirate it); ANSI-C is usually enough.
3) Get some "splint"-like commercial bullshit that doesn't detect shit, it may, or may not help you.
4) Write your own libraries for everything! Even sprintf, sscanf if you consider yourself a "safety"-oriented boy.
5) Do not use famous and popular libraries, specifically glibc; they are shit
I repeat:
DO NOT USE DEFAULT LIBRARIES
The reason behind this is simple they may brick your microcontroller so bad, you won't be able to reboot them using software means or even watchdog timer.
6) There is no "reusable" code really; every time you write something, you MUST rewrite it better next time; the only exclusion is some initialization routine, it may be reused many times in some of your different projects.
7) Make use of software daemon removal, or soft reset or hardware watchdog reboot.
8) Test it, until you break it; usually it breaks when you overflow its buffers or (much more common case) if you are using default libraries.
9) QNX might sound good and sound, but you must remember: the simpler your code is the easier it could be debugged. Also those canadian faggots won't help you at all.
10) Do not for for autistic "ALL INTERRUPTS" they will too break your system; choose optimal level of interrupt priority levels, put some circle buffers where needed and place checks in interrupts to check whether the previous operation is completed or not.
11) If you are not sure your system can handle all the input you MUST create a separate block specifically to feed some leftover data into.
12) Don't listen to autists sperging out: "use this flavour-of-the-month bullshit", or "some obscure one-programmer-per-continent VASTLY SUPERRIOR programming language", or "assembler 4 life". You are programming in C because it's "lingua franca" of modern embedded, and there are not that many embedded specialists, let alone embedded fortran/basic/assembler/forth/OOP autists.
13) Comment your code. Write some header documentation. Describe your functions like: what it does, its inputs, outputs.
14) Learn good coding practices, like naming your vars by their size: ui32FaggotSize, pui8InputBuffer[INPUT_BUFFER_SIZE].
15) Preprocessor directives. They may help you a lot, even when you use them in your own libraries (and i mean write your own libraries to be able to output hexadecimal, binary, char, float).
16) When you are ready to become "MIL-Grade pro" anime pro pun is intended send your code to your country govt code reviewing agency/or "patent"-like bureau; even if your code looks stolen you may remind them that you wrote it specifically for this hardware setup which is nowhere else to be found.
Not in the mood for shitpost, but you may throw some questions at me.