Could we ask ST to be consistent?

[waclawek.jan]

This is not a question, of course, just a rant.

and

 

JW

[Tesla DeLorean]

You can always ask...

[waclawek.jan]

:D

[TDK]

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.

[waclawek.jan]

> 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

[waclawek.jan]

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

[Harish1]

I also agree, not only of consistency, I found few bugs in the ref. manuals. They need to be updated asap.

[TDK]

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.

[waclawek.jan]

More.

Even more.

(with the added bonus of the field describing number of channels in sequence being mixed in).

JW

[waclawek.jan]

> 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