1: Which ARM? (Designing for a Cortex M0+ is entirely different from an M3 is from ...)<p>2: What are your design contraints? (Do you have hard-real time requirements? If so, you&#x27;re probably going to want to use the primitives that come with the RTOS (QNX&#x2F;Green Hills Integrity&#x2F;all-the-major-players have their own method of &quot;IPC&#x2F;threading&#x2F;whatever you want to call it&quot; and it&#x27;s usually an Erlang-esque message passing component.)<p>3: I&#x27;m presuming you&#x27;re going for automotives, in which case lol, TBB rules but you&#x27;ll never get ISO 26262 certification using it. If it&#x27;s for an entertainment thinger just use QNX like everyone else.<p>4: &quot;Unit tests take a long time and&#x2F;or crash..&quot; I&#x27;m sure the TK1 has ETM (which is <i>better than bondout chips, seriously</i>).<p>Just look at this[1] (then get your manager to bring me in as a consultant - it pains me to hear you have &quot;long-standing issues with an ARM port&quot; and the way your team-lead thinks he can solve it is with unit tests). &quot;Long time to load which sometimes fails entirely&quot; is a race condition. Insure++ is the &quot;Coverity&quot; for embedded (just as expensive, just as wonderful).<p>[1] <a href="http:&#x2F;&#x2F;i.imgur.com&#x2F;wcqlon7.png" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;wcqlon7.png</a> -- how your team lead should be actually debugging embedded components. If you give me more details re: your system&#x2F;functional&#x2F;integration requirements, I can likely tell you in which direction to move though.