Regarding peripheral variants...

[Alan Chambers]

Posted on June 08, 2018 at 10:48

I have a question about a feature of STM32s which slightly puzzles me. Each peripheral class (e.g. SPI) may have several instances on a given processor (e.g. SPI1, SPI2, ...). Different processors in the family have different collections of instances. So far, so good. The thing that seems a little odd is that different instances can have different capabilities. There are two or more variants (for want of a name). Timers in particular exhibit this property, ranging from the fully featured TIM1/TIM8 variant down to the much more basic TIM6/TIM7 variant, with several flavours in between.

Does anyone know why this is so? I mean, I can guess that there are trade offs in silicon area, but I'd be very interested in having a deeper insight. Is there better documentation about the peripheral variants than what can be gleaned from the reference manuals? I mainly use F4s. Are the variants used in F0s and so on identical, so that TIM1 (say) has the same features on every processor?

I've found that having several variants on the same processor makes it harder to write generic drivers. If I write a class to implement a PWM output on TIMx CHy, there are only certain timers and capture/compare channels which can be used, and even then there are subtle differences about which particular features are supported in each case.

The SPL is full of conditional blocks which are either executed or skipped for certain specific timers, but there seems to be no indication to the developer that this has happened. This makes writing a generic API simpler, but glosses over the differences in capabilities. I've been trying to write a C++ library which precisely represents the capabilities of the target hardware so that, for example, accessing a register or field for TIM2 which exists only on TIM1 will result in a compiler error. It's just an experiment in diving down a rabbit hole: it feels promising in some ways, and terrible in others. That library is not important, but it got me thinking about the nature of the hardware, so I thought I'd ask those much more knowledgeable than I.

I guess, at the end of the day, the hardware is what it is, and we just have to work around it.

AlPS: I'm feeling deja vu, and apologise if I've asked this before.

[David SIORPAES]

Posted on June 08, 2018 at 11:06

For different timer variants details there are these application notes: 

http://www.st.com/content/ccc/resource/technical/document/application_note/54/0f/67/eb/47/34/45/40/DM00042534.pdf/files/DM00042534.pdf/jcr:content/translations/en.DM00042534.pdf

, 

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/91/01/84/3f/7c/67/41/3f/DM00236305/files/DM00236305.pdf/jcr:content/translations/en.DM00236305.pdf

[Tesla DeLorean]

Posted on June 08, 2018 at 12:22

On the F2/F4 (and several others) TIM2 and TIM5 are 32-bit, this is not uniformly the case. The F1 and CM0(+) don't have any 32-bit TIM

TIM1 and TIM8 are the 'Advanced' TIM, and require the outputs/inputs to be enabled.

There is usually a table in the RM or DS describing this, but it can be frustrating.

[henry.dick]

Posted on June 08, 2018 at 12:46

'

The thing that seems a little odd is that different instances can have different capabilities.

 '

because not all applications need every timer to be that complex / sophisticated.

with that said, uniformal peripherals (identical instances in your terminology) do exist on some chips: Renasis, Luminary / TI, NXP, and certain PICs (24/32). they make programming much easier at the expense of larger silicon.

[Tesla DeLorean]

Posted on June 08, 2018 at 13:04

The lack of 32-bit TIM on a 32-bit platform has long frustrated me. Also the heavy use of naive integer dividers everywhere, and absence of any fractional adder (NCO) to be able to hit specific frequencies well.

I personally would have preferred not to have general purpose TIM that throw in the whole kitchen sink, but had smaller and more orthogonal timers and counters, that did specific tasks well.

The issue with 32-bit counters, at frequency, is critical paths in the counter and comparators (carry propagation type things), and the gate count in general of the TIM units.

ARM designs tend to eschew the use of transistors/gates where possible, however this is not arbitrary and they make the ones they do use function very cleverly. Others just take the directive to decimate gate count too literally, and don't compensate for the reductions with smarter designs.

[Alan Chambers]

Posted on June 08, 2018 at 14:34

Thanks. Those look useful.

[henry.dick]

Posted on June 08, 2018 at 14:47

'

The lack of 32-bit TIM on a 32-bit platform has long frustrated me.'

I haven't found 32-bit timers to be that useful. many times, it can be done via software. In other cases, most MCUs, including STM32, provide the ability to chain 16-bit timers together to form 32-bit timers.