AnsweredAssumed Answered

Regarding peripheral variants...

Question asked by Alan Chambers on Jun 8, 2018
Latest reply on Jun 8, 2018 by dhenry

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.

 


Al

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

Outcomes