Register-level examples for "more complex" interfaces, e.g. USB

[waclawek.jan]

Part of dialog between @TDK​ and me from https://community.st.com/s/question/0D53W00001EhiPhSAJ/wtf-go-back-to-old-community :

• [me] [linking to https://community.st.com/s/idea/0873W000000KyjfQAC/detail which asks for register-level examples for every module in STM32]
• [TDK] I agree that there should be register level examples for most things, certainly for timers, uart, SPI, etc. Probably not for USB.
• [me] This is a common misconception. In my "dozens of appnotes per module" model, I can envisage a couple of appnotes for USB in both its incarnations seen in STM32s, just to achieve enumeration, that's all register-level. And more dozens for the "auxilliary" features of USB such as sleeps, OTG-related, supply related...
• If you have a freely available register level USB implementation, I would love to see it. I’d very much like to get away from the HAL/ST USB library mess but can’t devote the time to understanding/implementing it at the register level from scratch.

No I don't have a freely available register level USB implementation. There are several reasons, the most obvious one is that most software I write is paid for. Also, it's not written in very readable form, (not only) because I don't have time to tidy it up for publication. Also, it did not see any external scrutiny nor too many implementations ("a library needs to be used in at least a dozen of implementations, until it starts to be any good"). Also, it's not written in clear C, I use my own "macro language" which makes things a bit different.

But what's the most important issue here is, that actual work with hardware forms only a negligible fraction of the whole implementation. Far below 1%. So, publishing USB implementation amounts to mostly publishing a *software stack*. And, as it goes in mcus, those are entangled in other hardware, and there are strong opinions on different approaches to them. At the end of the day, my solution, developed with a particular set of applications in mind, from the perspective of a random user with random expectations is not any better from ST's.

And that's common with other interfaces which are perceived to be complex, such as USB host, or ETH. The vast majority of complexity is in the complex protocol stack, of which the vast majority has to be solved in software. This adds to bad design of the protocols and the need to accomodate quirks and peculiarities of variety of counterparts, with which these interfaces interact, out in the wild. A personal experience, these quirks and peculiarities accounted for approximately half of the work spent so far.

The fact is, that the core hardware for USB device, USB host or ETH, is - from the programmer's perspective - at a similar complexity than any other nontrivial peripheral. Say I2C, maybe even simpler. So, examples showing the basic signaling (DP pullup, bus reset, etc), reception and transmission of an example packet, are relatively trivial.

Plus out-of-band signaling, e.g. the OTG/supply-related issues. These are straighforward hardware-registers.

OTOH, these modules have quirks in themselves, just have a look at the mix of bits including "toggle" in USB_EPnR of the device-only USB. Not to mention the poorly documented (and also badly designed) Synopsys OTG module. So those DO need competent explanation, yet almost never need a full stack for that.

And that's what I would like to see. In form of beefed-up Snippets, which ST said they can't implement on other than 'L0/'F0 exactly because of the "complex peripherals" (I am lazy to find the post here). And accompanied by the dozens of appnotes.

JW

PS. I recommend you to have a look at the original SPL-based USB implementation for the Synopsys OTG ("STM32F105/7xx, STM32F2xx and STM32F4xx USB On-The-Go Host and Device Library"). Maybe you'll start to see the Cube/HAL/LL mess as a brilliant and clean solution...