But at least RS-232 was adopted by a minor standard institute. Other serial buses like SPI and I2C aren’t as fortunate, and they tend to be implemented (and named) in new creative ways for every chip manufacturer using them. These are truly “customized standards”, you have to RTFM in extreme detail before even considering using the specific SPI/I2C chip, to see which creative non-standard ideas they decided to implement this time. Compare these with CAN which is a formal ISO/IEC standard, I have never had any protocol/timing-related problems when setting up two CAN controllers to speak with each other, while such problems are mandatory when using SPI and I2C.

If filling a hardware roll, I love performing this job as it gives me a chance to re-review the schematics, design strategy, logic levels / timing, and CPLD equations, etc. This could be invaluable to the quality and integrity of the design and may filter out any remaining bugs or oversights. I wish this task were taken more seriously and in my opinion, it all comes down to money.

Mutexes are needed when different threads need to access the same hw registers. However, mutexes still have their flaws. Each and every thread in all of their respective hw register accesses must use the same mutexing technique. If even one thread doesn’t, the system is exposed.

This is where the design of the hw can help, by assigning, where possible, bits into registers only needed by one thread. For registers that do need to be accessed by multiple threads (such as GPIO ports), atomic register access mechanisms (see here for examples) can be employed to eliminate any need for mutexes.

This and your previous post both allude to the issue of bit allocation to registers. It’s a tough problem, particularly on small processors with limited address space. Different companies have adopted different strategies on this, so I’d be interested to get your opinions on this topic in future posts.