Posted on August 09, 2017 at 16:04One of the problems is that the 'white goods' guys have represented a large volume, and driven design decisions in the past. They however represent a very small number of customers, and we seem to be stuck with them driving the bus, rather than the needs/expectations of those using a 32-bit micro for other applications. I'm afraid the design is far to far down the pike to remedy any of the obvious failings.
The TIM module is a monster, it's generality kills it on all fronts. I understand why 16-bit was chosen, but if your broke the TIM in to more functional blocks you could address some of those. The pin mux has a lot of vacant routeing. You're not trying to compete with archaic 8 and 16-bit micros, a 32-bit micro should have 32-bit timers, period. A couple of 64-bit counters wouldn't go amiss these days.
Having half-a-dozen 32-bit encoders, with 2 limit registers could be it's own peripheral. The frequency could be below 200 MHz, and avoid a lot of the critical path arguments. These could also be used to measure external frequency, with the ability to capture counts from different internal timebases.
The motor control needs it's own TIM, the multi-phase stuff, while not my thing, seems to require a lot of baby sitting of the TIM.
The STM32 used to represent a couple of different designs, in the last year this seems to have exploded into a large array of parts. Much of the disparity is handled by Cube/HAL, but unifying everything is a monumental task and results in a thick abstraction layer. Supporting and doing proper regression testing is going to be very difficult.
