The first one is clearly solvable.
How would you solve the second? Split the EXTICR array into 4 different fields and ditch the array? There's a few similar issues like this. Arrays are 0-indexed, no way of changing that. Registers are always 1-based per all the RM docs. Or split into low/high like the AF registers.
> Registers are always 1-based
(The latter is ridiculous in itself, as FMC/FSMC_BCRx registers are indeed later numbered from 1. FMC/FSMC is a ridiculuous issue in itself, as is UART/USART and many similar. And the CMSIS-mandated headers' state is sad in general, too).
I know, milk has been spilt long ago so we just have to learn to live with this; frustration remains nevertheless. And we see this happening again and again all over the place.
I know I am opinionated but it was not me who taught that indexing in programming should ALWAYS start with zero - and for good reasons.
Note, that pins *are* zero-indexed - even in the very SYSCFG_EXTICR1 register you'll see EXTI0 field - how could that not ring any bells to whomever "designed" this?
This is all about culture, doing things systematically, meticulously, properly.
As Clive said, I can always ask; so here I am, asking.
Btw. I told to myself, but Jan, you must've come across the SYSCFG/EXTI thing in the past, how did you cope with the frustration back then?
So I looked it up:
SYSCFG->EXTICR[SOMEINPUT_PIN / 4] = (SYSCFG->EXTICR[SOMEINPUT_PIN / 4] AND (~(0xF SHL (4 * (SOMEINPUT_PIN % 4))))) OR (GLUE(SYSCFG_EXTICR1_EXTI0_P, SOMEINPUT_PORT_LETTER) SHL (4 * (SOMEINPUT_PIN % 4)));
I guess if pins are 0-index based, and those are clearly exposed to the user in a very prominent way, it's not very consistent for other stuff to be 1-based.
I'm always a fan of making things 0-based but make an effort to make things exposed to a (non-programming) user 1-based.
I would argue those DMA registers are named based off the channel numbering, and the USB is based off the stream.
Fat chance of any of this changing now, of course.
> I would argue those DMA registers are named based off the channel numbering,
No. That's *streams* in the dual-port DMA ('F2/'F4/'F7) 0-based numbere; channels (which here mean "multiplexer input") are indeed 0-based numbered, too.
These Streams correspond to Channels in the single-port DMA (as in 'F1/'F0/'F4/'Lx) and those are 1-based numbered.
This causes real trouble in 'G0/'H7 (for BDMA) where DMAMUX feeds their 0-based Channels into the 1-based DMA Channels.
> USB is based off the stream.
You mean, endpoint? That would be a fair point for the Device registers (and as such is indeed reflected also in the Device-only USB such as in 'F103/'F0/'F3/'L0/low 'L4), but not for Host in the OTG module (where the numbering corresponds to... eee... that's a long story). The main reason for 0-based numbering here is, that the OTG does not come from ST but from Synopsys.