So, what to expect from the 'C0?

[waclawek.jan]

As said, the 'C0 is mostly a cut-down 'G0. Let's now put aside the "is it a true STM8 replacement" and the price-related discussion, let's just have a look at what we can and what we can't find in these chips. I had a look at the DS and RM and here are some random findings:

• there are 2 models, 'C011 and 'C031; they differ only in RAM size and number of pins (both are in the popular 20pin TSSOP, 'C011 ends there, 'C031 goes up to 48 pins)
• less RAM and FLASH than 'G0 but that is expected, RAM has parity as in 'G0, switched off by default through RAM_PARITY_CHECK option bit
• min. 2.0V VDD (i.e. no 1.8V interoperability) - this is something we see in the "Value lines" (i.e. STM32yxx0)
• the usual -6, -7, -3 temperature ranges
• 48MHz max sysclk (vs.64MHz G0, en-par with 'F0, better than 32MHz 'L0)
• 1kB OTP (as in 'G0), nice!
• FLASH does NOT have ECC (it's explicitly written - 'G0 does have ECC), 2kByte pages, endurance is the same 10k
• 24MHz FLASH, has prefetch and 2 lines of instruction cache (same as 'G0)
• no PLL!
• HSI 48MHz with separate scalers for sysclk and peripherals clock (kernel clock)
• LSI, LSE as usual (pins for LSE see below)
• HSE min 4MHz but up to 48MHz(!) with crystal (same as 'G0, but still quite surprising), of course has bypass mode too
• except for the most-pin models (for which see HSE_NOT_REMAPPED option bit), there's only one pair of oscillator pins marked OSCX_IN/OSCX_OUT (yes, shareable with GPIO) so you chose whether you want LSE or HSE, can't have both - IMO this is a very good solution, we've seen much worse on the low-pin-count low-end STM32s
• pins in the SO-8 (and the ridiculously small WLCSP 'C011) are stil bonded together as in other families' SO-8, but there are mux registers in SYSCFG which prevent switching them to output or AF simultaneously. There's a related SECURE_MUXING_EN option bit. This definitively deserves a footnote to the pin table in the DS (@Imen DAHMEN​ can you please have a look at this?) I foresee an influx of complaints for these pins not working as expected in the non-SO-8 packages...
• single-port DMA with DMAMUX as in 'G0, but only 3 DMA channels, but given peripheral count this is OK
• GPIO-to-EXTI selection registers are part of EXTI and not SYSCFG as in most STM32, but this was so in 'G0 too - thumbs up
• no DAC/VREFBUF/COMP (which is a pity, there were STM8 with dual DAC and COMP); ADC is okay I guess
• only single-point internal temperature sensor calibration value, as in Value lines
• no RNG, CRC is the variable-poly one which is okay, both watchdogs are probably okay
• no 32-bit TIM, TIM1 is the super-duper variety which is nice, TIM3 is normal, TIM14 is a single-channel, TIM15/16 are the almost-advanced single-complementary-channel ones - all in all it's a nice selection of timers, except the no 32-bit TIM...
• [EDIT] I've forgotten... RTC. With bells&whistles (wakeups, input/output etc). But WHY? There's no VBAT, no reasonably-low-power-mode with RTC...[/EDIT]
• [EDIT2] there are 4 backup registers - there's no VBAT so they are just to survive Standby mode - but they are not in TAMPER as should be with RTCv3, nor part of RTC as they used to be with RTCv2, but, quite surprisingly, are part of PWR (as PWR_BKPxR) [/EDIT2]
• one I2C (with FM+ support, DS does not indicate FM+ capable pins in the pintable, but RM has FM+ enable bits in SYSCFG, so I don't know what to make out of this)
• two USARTs of which one is super-duper IrDA/LIN/ISO7815/RS485/autobaud/FIFO/kitchensink, the other basic - that's fair IMO
• only one SPI with the lame simplex I2S - but hey, this is a basic micro, why would you want I2S on it at all?

Comments, please.

JW

[Patrice HAMARD]

Hello Jan,

I take good note of your comments. Particularly the Analog portion regarding DAC and Comparators. The analog IPs are generally costly in size and we have chosen to remove them knowing the bridge we are offering with the STM32G0 in which you can find a full set of those.

8-bit with Analog content are expensive, generally more expensive than STM32G0. We made the C0&G0 upward compatible in order for developers to add these features at will.

Thank you by the way for your detailed analysis. I will keep the "*USART/ Kitchensink mode" in our roadmap 😉

[waclawek.jan]

Hi @Patrice HAMARD​ ,

Thanks for the comments.

> The analog IPs are generally costly in size

Just to have some actual data points:

The STM8L152 buys against the STM8L052 not just 2xDAC and COMP, but also TOUCH. IMO there are applications where the cca 45cents price difference is worth it. I'm not sure the 'C0 vs. 'G0 price will get down to 45 cents, especially since the "smallest" 'G0 with DAC has extra features which may be useless for those lowest-end applications.

Speaking of STM8L152 vs. STM8L052 maybe analog is not THAT useful in the low-end applications, but touch IMO may be.

> I will keep the "*USART/ Kitchensink mode" in our roadmap 😉

:D

... but please don't. The feature creep we see in STM32 peripherals generally has IMO returns diminished already to almost zero, and there are more potential gains from rethinking the peripherals and their interconnections. For example, the often requested UART timeout, rather than adding it as a feature to UART, is better solved by interconnecting UART RXNE as an optional input to the general-purpose timers. There are many similar examples, e.g. connecting SPI clocks to TIM outputs. It just requires to listen to feedback from actual users, e.g. here on the forum, would it be properly functional.

JW

PS. I've forgotten - added above to the list - the RTC, which IMO is entirely redundant in a baseline mcu, if there's no VBAT, easily replaceable by a general-purpose TIM - so that's maybe something to contemplate for the next iteration of the lowest-end?

[Imen.D]

Hi Jan,

Thanks for your post and for taking time to report this with many details.

I raised your feedback internally with the appropriate team for review.

Imen

[waclawek.jan]

The team is surely thrilled to review my review 🙂

Thanks, Imen!

Jan

@Imen DAHMEN​