| Can anyone explain this? Are you asking if companies make bad reference code a deliberate part of their product? I don't think any company will admit to that if it was their plan. I've seen just as much bad code as you - probably more. My observations come down to this: 1) It's reference code and labelled as such, so there's no warranty and thus no investment in making the code look good, follow any standard, or even be readable. If it works, that's enough. 150 out of 150 unit tests pass? End of story. Complaining to your FSE will get you either a shrug or a quote from their contact engineering arm. Better FSEs at better companies will try to get to the original author and ask them what the hell is up. 2) The code is written by the hardware engineers writing the Verilog and designing other parts of the chip. Sometimes they're using it to validate the part and sometimes they're recruited to write the reference code and sometimes it's both but, in all cases, they're typically not software engineers. 3) The code is shopped out to contract software engineers in far away time zones because of cost. Any companion software has a non-zero cost which means it has to be paid for in the price of the chip sooner or later. There's a strong drive to keep that cost down, obviously. I get your frustration and it would be nice if you could port reference drivers into your project in two clicks and then get back to finishing your sprint. I feel fortunate if there's anything I can read alongside the datasheet. I could mention companies that I think do better than others, but that will probably attract a flurry of counterexamples. From my POV it's just part of the job. |