SAMC ARM has the same drawback as legacy AVR

[Simon]

i am reading through the counter documentation on the SAMC ARM and I am amazed to find that PWM mode in 16 and 32 bit mode has the sae limitation as the the old 8 bit AVR's, worse infact.

In 8 bit mode the conter has a "top" value register. but in 16 bit mode there is no such register and the user is forced to use all 16 or 32 bits unless one of the compare match (PWM) channels is sacrificed so that it's compare register can be used as top. On the AVR it was the same but at least 8, 9, and 10 bit top values were also selectable.

it's not an impossible situation but i thought ARM's were supposed to be all singing and dancing. I see bits literally thrown away as unused in 32 bit registers and yet they could not spare themselves another 8 bits to extend the period register to 16 bits (2 counters are ganged together for 32 bit operation so would have a 16 bit register each).

at 48MHz 16 bits is 700Hz so it's a decent number but really surprised here.

[PCB.Wiz]

it's not an impossible situation but i thought ARM's were supposed to be all singing and dancing. I see bits literally thrown away as unused in 32 bit registers and yet they could not spare themselves another 8 bits to extend the period register to 16 bits (2 counters are ganged together for 32 bit operation so would have a 16 bit register each).

Yes, a quite common syndrome.
NXP tend to be better here, but some vendors get tangled up in either reusing old timers, or thinking a simple paste helps portability...
- but one of my pet peeves is the 32b MCUs  lacking 32b usability in the peripherals.  Too many have just 16b timers, or worse, as you say here...

NXP I think do 32b timers and 32b prescalers  and Nuvoton do 24b timers and 8b prescalers which I think is a more practical middle ground for a vendor worried about gate counts.

[langwadt]

i am reading through the counter documentation on the SAMC ARM and I am amazed to find that PWM mode in 16 and 32 bit mode has the sae limitation as the the old 8 bit AVR's, worse infact.

In 8 bit mode the conter has a "top" value register. but in 16 bit mode there is no such register and the user is forced to use all 16 or 32 bits unless one of the compare match (PWM) channels is sacrificed so that it's compare register can be used as top. On the AVR it was the same but at least 8, 9, and 10 bit top values were also selectable.

it's not an impossible situation but i thought ARM's were supposed to be all singing and dancing. I see bits literally thrown away as unused in 32 bit registers and yet they could not spare themselves another 8 bits to extend the period register to 16 bits (2 counters are ganged together for 32 bit operation so would have a 16 bit register each).

at 48MHz 16 bits is 700Hz so it's a decent number but really surprised here.

ARM is just the CPU, peripherals are vendor specific some ARMs have all singing and dancing timers

unused bits in a register doesn't mean those bits are wasted, it is more likely that the bits don't exist 

adding bits to a register and a compare cost actual hw

[Simon]

But this is not even a copy of those AVR timers, it's a totally different , they could just not be bothered to have a 16 bit PER register which is nuts and retrograde when another setup register is 32 bits and only uses 1 byte!

I can understand the 16 bit counter rather than 32 bit. The CPU is designed by ARM but the peripherals are done by the vendor. I don't have a problem with 16 bits and ganging two together if I am desperate for a 32 bit counter which I am not as even at 48MHz it will take over a minute to roll over so use of 32 bit instances are going to be rare.

[ataradov]

You are being compensated by having A LOT more timers.

Also, SAM L10/L11 address this issue and there is PER register in all modes. The same timer peripheral will be propagated to new devices in due time.

Yes sure, it would be nice to have the hardware that does exactly what you need it to do at that exact moment, but it does not work that way on any architecture or vendor.

[Simon]

adding bits to a register and a compare cost actual hw

but a measly 8 bits? I mean cmon, a major product limitation over 8 bits? take it out of the program memory if they are so precious.

[Simon]

You are being compensated by having A LOT more timers.

Also, SAM L10/L11 address this issue and there is PER register in all modes.

Yes sure, it would be nice to have the hardware that does exactly what you need it to do at that exact moment, but it does not work that way on any architecture or vendor.

8 bits, that is all that was needed and I'd be happy loosing a whole counter instance for it if it doubles the outputs. i mean this is not about saving 8 bits, it feels like some lame ass marketing move to push us onto bigger and more complex chips that really do not do what i want. SAMC's are just perfect for the auto sector, 5V operation, dual CAN bus, what more could one ask for in a project that is not a smart phone - 8 measly more bits......

[ataradov]

Things don't just happen. The peripherals that SAM C uses were designed before Cortex-M0+ core was used. That's why they all have strange 8-bit registers and stuff like that.

Over time peripherals are improved and put into new MCUs. There will always be legacy stuff, and you just have to live with that. Designing and putting into production new peripherals is actually a lengthy process.

[PCB.Wiz]

8 bits, that is all that was needed and I'd be happy loosing a whole counter instance for it if it doubles the outputs. i mean this is not about saving 8 bits, it feels like some lame ass marketing move to push us onto bigger and more complex chips that really do not do what i want. SAMC's are just perfect for the auto sector, 5V operation, dual CAN bus, what more could one ask for in a project that is not a smart phone - 8 measly more bits......

Yes, it does smack of laziness, and the fact Atmel/Microchip are fixing this in newer parts, shows you are not alone in giving then stick about this.
Chaining timers kludges I expect on a 8 bit MCU, but not on a 32b one....

[Simon]

Well these are not AVR counters so where did they come from? and they are less than the AVR counters. I am just stunned that they did this, I mean why put a PER register in at all, and having decided to put one why not make it the same size as the native and default counter size?

16bits is not a huge issue as i said. it yeilds frequencies of 700Hz and down but I still fail to get over the sheer stupidity of it. Where they trying to stop say motor drivers being developed? 8 bits is probably a bit lame for motor drivers but 16 bits is too slow, but 9 or 10 bit would work.

[ataradov]

On Cortex-M0+ parts silicon area is actually a concern. So I would not expect to see 6 full 32-bit timers anyway. It really does drive the price of the part up.

I know we all have a dream chip, but that just does not happen.

[langwadt]

But this is not even a copy of those AVR timers, it's a totally different , they could just not be bothered to have a 16 bit PER register which is nuts and retrograde when another setup register is 32 bits and only uses 1 byte!

just because a register looks like it is 32 bit doesn't mean that there actually is 32 bits

you could give every bit its own address

[Simon]

Yes, it does smack of laziness, and the fact Atmel/Microchip are fixing this in newer parts, shows you are not alone in giving then stick about this.
Chaining timers kludges I expect on a 8 bit MCU, but not on a 32b one....

I really don't mind chaining timers, at 16 bits you are rarely going to want more and another time can be sacrificed to make a 32 bit one if you really need one. But a decent 16 bit timer is a must and even the 8 bitter get that right.

[ataradov]

Well these are not AVR counters so where did they come from?

They were designed for an unreleased architecture. Again, designing this stuff takes years. And market shifts during those years. In this case Cortex-M0+ core came along, and plans changed.

[Simon]

But this is not even a copy of those AVR timers, it's a totally different , they could just not be bothered to have a 16 bit PER register which is nuts and retrograde when another setup register is 32 bits and only uses 1 byte!

just because a register looks like it is 32 bit doesn't mean that there actually is 32 bits

you could give every bit its own address

There are plenty of 8 bit and 16 bit registers with holes in them too. No none of thu bits have addresses as they are humble setup registers. Unless you can miss bits out in the smalest block you can address they gained nothing.

[langwadt]

But this is not even a copy of those AVR timers, it's a totally different , they could just not be bothered to have a 16 bit PER register which is nuts and retrograde when another setup register is 32 bits and only uses 1 byte!

just because a register looks like it is 32 bit doesn't mean that there actually is 32 bits

you could give every bit its own address

There are plenty of 8 bit and 16 bit registers with holes in them too. No none of thu bits have addresses as they are humble setup registers. Unless you can miss bits out in the smalest block you can address they gained nothing.

only the bits  that are used exist, it is hardware

[T3sl4co1l]

They were designed for an unreleased architecture. Again, designing this stuff takes years. And market shifts during those years. In this case Cortex-M0+ core came along, and plans changed.

Heh, anyone familiar with AVR32?  Maybe that's where it came from, or what they were working on before they moved to ARM.

Tim

[ataradov]

Heh, anyone familiar with AVR32?  Maybe that's where it came from, or what they were working on before they moved to ARM.

I'm not 100% sure of the actual history of those peripherals. AVR32 used all 32-bit registers, so it was not it. It would have been something different, probably continuation of Xmega line. I don't know the timelines for all of that.

Or may be it was designed for Cortex all along, but since it was done by the 8-bit people, they chose to do 8- and 16-bit registers.

[ogden]

I do not get those rants "my MCU does not do this or that". It's like "my car does not reach X speed or Y mileage". Well... it does not. You can blame *yourself* that you did not chose right tool for the job. Don't blame the tool.

[PCB.Wiz]

I do not get those rants "my MCU does not do this or that". It's like "my car does not reach X speed or Y mileage". Well... it does not. You can blame *yourself* that you did not chose right tool for the job. Don't blame the tool.

Well, yes.
That's why I point out the vendors who do offer 'the right tools for the job'...
Some MCU suppliers do this better than others.

[techman-001]

I do not get those rants "my MCU does not do this or that". It's like "my car does not reach X speed or Y mileage". Well... it does not. You can blame *yourself* that you did not chose right tool for the job. Don't blame the tool.

I can see Simon's point, he bought a 32 bit chip and expected more. It's a complex chip and perhaps Simon hadn't read all the copious reference PDF before purchase ?

To continue your car analogy Simon bought  the 32 cylinder Atmel/Microchip car and just assumed it would have a AM/FM radio but they cheaped out and it's AM only.

Simon should have bought a proper STM32 cylinder car.

[ataradov]

Yeah, STM timers are not the greatest either, so I would not be too excited here. There will be different kinds of complaints, but there will be plenty.

[ogden]

To continue your car analogy Simon bought  the 32 cylinder Atmel/Microchip car and just assumed it would have a AM/FM radio but they cheaped out and it's AM only.

You nailed the problem. Thing is that 32 "cylinders" does not guarantee anything. We talk about SAMC which is Cortex-M0+ based ARM - chip class where most of the bloody price competition wars happen. This class is so price-optimized that you have to read specifications well because in car analogy there could be no passenger seats nor wheels included.

That's why stm32 community make so many designs using overkill stm32f4 chip - because it is packed with virtually everything stm32 chips can have. When you are finished with your build and understand kinds and number of peripherals you need, RAM and FLASH and CPU resources - then you look at the lower series of the stm32 chips.

When you lived all your life in the Arduino world and suddenly wake-up in front of Mouser ARM MCU page which has 11137 various offers (today), you have to think why it is so in free market where offer is consumer-driven.

Yeah, STM timers are not the greatest either, so I would not be too excited here. There will be different kinds of complaints, but there will be plenty.

LOL, yes. You may solve timer capture register count problem but run into another [edit] For me most annoying stm32 problem is - clock subsystem. Try to run ADC directly from crystal oscillator source while PLL with it's **ing jitter is running - you can't.

[Jeroen3]

I guess most vendors just pulled a timer from the Synopsys library they bought anywhere in the last century and just keep using it.

[Simon]

As i said I can work with it I'm just stagered they did it, I am reading through the documentation now to find out how it works. 8 timers all locked at set frequencies unless a channel is lost. As I also said if they were concerned about cost I am sure users would opt to loose 1 timer and guarantee full flexibility on 2 channels of what is left not just 1. So SAMC has up to 8 timers, if I need a specific frequency I only have 8 outputs. If they dropped a counter and added 8 bits more to 7 registers I would have full flexibility on 14 channels, that's a bit more than 8 eh? that's all i am saying, the decision defies logic.