2021-07-21 08:29 AM
This is not a question, of course, just a rant.
and
JW
2021-07-21 09:09 AM
You can always ask...
2021-07-21 10:15 AM
:D
2021-07-21 02:55 PM
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.
2021-07-22 02:04 AM
> 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.
JW
2021-07-22 02:10 AM
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)));
🙂
JW
2021-07-22 06:12 AM
I also agree, not only of consistency, I found few bugs in the ref. manuals. They need to be updated asap.
2021-07-22 06:30 AM
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.
2021-07-22 07:03 AM
More.
Even more.
(with the added bonus of the field describing number of channels in sequence being mixed in).
JW
2021-07-22 07:21 AM
> 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.
JW