A guide to better embedded C++
Almost nobody in their right mind would do this. (To be fair, many people working with hardware are not in their right mind anymore. Try it, you&#x27;ll see.)<p>1: Don&#x27;t use bitfields when interacting with registers. The language does not guarantee the behavior you want. Or even the behaviour you <i>think</i> you want.<p>2: &#x27;volatile&#x27; is the contract that we (language users) have hammered out with the compiler industry over the last 20 years; it means &quot;don&#x27;t get smart with this memory location&quot;. Use it.<p>3: For any SoC of more than trivial complexity, the vendor will supply headers that describe the hardware (register names and addresses, field names, sizes, offsets, enumerations, etc.). You will hate their naming convention. You will hate the way they encode field sizes, offsets, masks, etc. Deal. Because the alternative is you, or your intern, making dozens of mistakes attempting to transcribe from the documentation. Here&#x27;s a hint - the better vendors auto-generate these headers from the VHDL. They are often right even when the documentation isn&#x27;t.<p>4: It&#x27;s trivial to template most interactions with registers. See, for example: <a href="https:&#x2F;&#x2F;github.com&#x2F;steffanw&#x2F;laks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;steffanw&#x2F;laks</a><p>5: A little investment in your abstractions, even if the lower levels look a bit more complex or verbose, helps make your application logic easier to follow.<p>The discussion here about re-ordering is largely moot; if you&#x27;re having issues with the core re-ordering your transactions, either your core is børked or you haven&#x27;t mapped your peripheral space correctly. The former is pleasantly rare, the latter common enough that your compiler vendor is going to ask you about it before they give you a bug number.