Could it be 5V
Make something new on a decades old dead technology? Would be very odd.
Well, yeah. But this whole "8 bit killer" marketplace doesn't seem so full of success, and I think part of that is the lack of 5V I/O support (note that most ARMs already have a lower "core" voltage than IO voltage.)
(The other reason is the general lack of of a good library/sdk set for low-memory controllers.)
The C0 series seems to be quite similar to G0, M0+, but only up to 48Mhz and **FPU**
FPU on a entry-level targetted mcu? That's another level!
FPU on a entry-level targetted mcu? That's another level!
I'm curious to see that. Where did they get the info about the C0 series having a FPU?
If it's indeed M0+-based as seems to be the case, that would be the first line of MCUs with a M0+ core and a FPU. That I know of, at least.
FPU on a entry-level targetted mcu? That's another level!
I'm curious to see that. Where did they get the info about the C0 series having a FPU?
If it's indeed M0+-based as seems to be the case, that would be the first line of MCUs with a M0+ core and a FPU. That I know of, at least.
I didn't think an FPU was an option on M0 or M0+ at all.
Microchip PIC32CM
C in this case standard for "Cortex", same way as "M" in PIC32Mxxx was for "MIPS", it is just a core type, and not related to the supply voltage directly, so I would not read too much into this.
You can add an FPU as a peripheral, but that makes no sense to me. If you need floating point performance, you probably want fast integer performance too.
There is probably no way to guess how "C0" is different unless some datasheet leaks.
This article from October 2021 also mention it -
https://community.st.com/s/article/what-are-the-preferred-ides-for-stm32-microcontrollers, and specifically
Unlimited application size for Cortex-M0/M0+, fit for the STM32C0, STM32F0, STM32G0 and STM32L0 Series
So, Cortex-M0+ is a safe bet.
Not sure where the FPU thing came up, this series has absolutely no FPU.
With these kind of chips for me the biggest challenge is how to share SWD/GPIOs/other interfaces in a safe manner such that 2 or 3 pins are not wasted on SWD
A bit premature to tell.
One thing I can reveal though " Your new 8-bit MCU, is not an 8-Bit MCU"
Stay Tuned.
Pat
If you look of the STM32xnnn P/N scheme. the letter "x" indicates the various series. On cortex M0/M0+ General purpose devices , there is the "F", is was the first of its kind. the "L" for Utra low power", the "G" as the second generation of the "F" and soon the "C"
If we want to assign a meaning to "C" .. Cost , Cheap, Cool ?? you can pick what you want
Pat
Could it be 5V
Make something new on a decades old dead technology? Would be very odd.
Well, yeah. But this whole "8 bit killer" marketplace doesn't seem so full of success, and I think part of that is the lack of 5V I/O support (note that most ARMs already have a lower "core" voltage than IO voltage.)
(The other reason is the general lack of of a good library/sdk set for low-memory controllers.)
8-bit killer ..... 8-bit replacement is in fact on going. It was a matter of Price point and old habits. The internal Bus size is not relevent to the user I guess.
Now let's imagine a product as advanced and deployed as the STM32 is. With very good price point with a very basic architecture similar to 8-bit.. It may eventually be a breakthrough. ...mmm let see.
Not sure where the FPU thing came up, this series has absolutely no FPU.
With these kind of chips for me the biggest challenge is how to share SWD/GPIOs/other interfaces in a safe manner such that 2 or 3 pins are not wasted on SWD
***FPU**
That's a typo for sure.
Mayyybeeee MPU instead. like Memory Protection Unit ?? why not, it could be a cool stuff right
Modify message
32-bit MCUs are already massively cheaper than 8-bit MCUs. The only way you can move 8-bit people to 32 bits is if you dumb down all the peripherals to the 8-bit level. But that does not seem like a good idea.
There is no point in speaking in riddles, if you can't openly say what it is, we'll just wait until we can. This is not a TV show, we don't need vague hype.
Mayyybeeee MPU instead. like Memory Protection Unit ?? why not, it could be a cool stuff right
The M0+ has an optional MPU, so this could be the case indeed.
MPU alone is not enough to justify a separate series. It is a very marginal and mostly useless thing. If it comes for free - nice, but I can't remember a single instance where not having an MPU was a deal breaker.
Just found some technical documents about the STM32C0 discovery board on a Chinese website:
www.stmcu.com.cn
"The DIP28 pinout is designed to be as compatible as possible with the ATMEGA328 8‐bit microcontroller." This is like board vendors putting shield connectors on all kits. I have never seen anyone actually use them for anything. The attractive part of the Arduino is not connectors or the MCU, it is the firmware ecosystem. And I'm thinking ST is not going to do much work there, and tell the story how Cube is better.
It looks like a 5V I/O device. Pretty pointless if you ask me. If it is extremely cheap, there would be uses, but if it costs as much as comparable devices, seems strange to me to bring such a device to market.
"The DIP28 pinout is designed to be as compatible as possible with the ATMEGA328 8‐bit microcontroller." This is like board vendors putting shield connectors on all kits. I have never seen anyone actually use them for anything. The attractive part of the Arduino is not connectors of the MCU, it is the firmware ecosystem. And I'm thinking ST is not going to do much work there, and tell the story how Cube is better.
It looks like a 5V I/O device. Pretty pointless if you ask me. If it is extremely cheap, there would be uses, but if it costs as much as comparable devices, seems strange to me to bring such a device to market.
I like 5V IO. More often than not it spares me the pain of having to use mosfet drivers or level translator, since most of the electronics i interface with is still 5V and will be for years to come.
Also one of the reasons i still use 8bit PIC: 5V ADC, 5V PWM, simple to program yet powerful, cheap, can reuse 99.9% of the code if i migrate design to other families.
I wonder if they will do 5V IO+USB? Is it there on the documents?
Just reading the tea leaves of the user manuals for the boards - it looks like it still needs 3.3 V, so it is possible that it is either 5V tolerant only, or only some pins are 5V and 3.3 V is still necessary. It might have internal regulator for the USB, of course.
A lot of the things on the board still seem to be referenced to the 3.3 V supply. For example joystick is read via a resistive divider and an ADC channel, and the 1.0 ratio is shown to be 3.3 V. May be just the way board is designed, of course.
My issue with dedicated 5V devices if that you are limiting yourself to a very narrow selection. So, in a long run it is better to transition to 3.3 V logic. There is a place for 5 V, of course, but for general applications, I'd stay away from it.
"The DIP28 pinout is designed to be as compatible as possible with the ATMEGA328 8‐bit microcontroller." This is like board vendors putting shield connectors on all kits. I have never seen anyone actually use them for anything. The attractive part of the Arduino is not connectors or the MCU, it is the firmware ecosystem. And I'm thinking ST is not going to do much work there, and tell the story how Cube is better.
It looks like a 5V I/O device. Pretty pointless if you ask me. If it is extremely cheap, there would be uses, but if it costs as much as comparable devices, seems strange to me to bring such a device to market.
They probably thought Atmega's would go completely out of stock during the shortage, so they spun this up as an idea to capture the marketshare.
Shields I've never personally used, but, there is a lot of value in having a standardized pinout. Also having lots of pin headers is never bad on a dev board.
https://www.google.com/search?q=nucleo+shield32-bit MCUs are already massively cheaper than 8-bit MCUs. The only way you can move 8-bit people to 32 bits is if you dumb down all the peripherals to the 8-bit level. But that does not seem like a good idea.
Some are some aren't, the cheapest MCUs are 8-bit Padauks right.
Some are some aren't, the cheapest MCUs are 8-bit Padauks right.
For the same general performance and peripheral set, 32-bits are almost universally cheaper.
Sure, there are some very low-end 8-bitters, but 32-bit does not even cover that part of the market, sine the whole MCU there is cheaper than ARM license fee.
Well, it's a question of market. But also die size. 8-bit MCUs take up much less die area for the logic part, but is that necessarily always a benefit? For the older/larger node sizes, sure. But if you wanna use any more recent and finer node size, then an 8-bitter becomes rapidly pad-limited, meaning that unless it has very, very few IOs, or you have like a multi-core chip with a number of cores (but I haven't seen vendors taking this path really), then a given die would essentially be empty, most of the area being defined by the pads. Which is pretty wasteful. So 8-bitters have become kinda niche - partly because they have lower performance, but even if the performance is adequate for some applications, then you have this factor that you become essentially stuck with older process nodes, or the chip becomes absolutely not competitive cost-wise.
Just reading the tea leaves of the user manuals for the boards - it looks like it still needs 3.3 V, so it is possible that it is either 5V tolerant only, or only some pins are 5V and 3.3 V is still necessary. It might have internal regulator for the USB, of course.
A lot of the things on the board still seem to be referenced to the 3.3 V supply. For example joystick is read via a resistive divider and an ADC channel, and the 1.0 ratio is shown to be 3.3 V. May be just the way board is designed, of course.
My issue with dedicated 5V devices if that you are limiting yourself to a very narrow selection. So, in a long run it is better to transition to 3.3 V logic. There is a place for 5 V, of course, but for general applications, I'd stay away from it.
Everything in a car's trunk is still either 12V power or 5V signal
I do use 3V3 when i can but just doing small board with dual power supply because interfaces are at 5V and logic is at 3V is a major pain. You would think there would be many LDOs with dual ouput, 5V and 3V3, pretty easy to do and yet almost zero parts and i have to use two LDOs... I welcome advanced parts with 5V IO
"The DIP28 pinout is designed to be as compatible as possible with the ATMEGA328 8‐bit microcontroller." This is like board vendors putting shield connectors on all kits. I have never seen anyone actually use them for anything. The attractive part of the Arduino is not connectors or the MCU, it is the firmware ecosystem. And I'm thinking ST is not going to do much work there, and tell the story how Cube is better.
It looks like a 5V I/O device. Pretty pointless if you ask me. If it is extremely cheap, there would be uses, but if it costs as much as comparable devices, seems strange to me to bring such a device to market.
They probably thought Atmega's would go completely out of stock during the shortage, so they spun this up as an idea to capture the marketshare.
Shields I've never personally used, but, there is a lot of value in having a standardized pinout. Also having lots of pin headers is never bad on a dev board.
https://www.google.com/search?q=nucleo+shield
32-bit MCUs are already massively cheaper than 8-bit MCUs. The only way you can move 8-bit people to 32 bits is if you dumb down all the peripherals to the 8-bit level. But that does not seem like a good idea.
Some are some aren't, the cheapest MCUs are 8-bit Padauks right.
I do like the fact that i can move up/down the line in microchip parts with no redesigns, the same pinout (or with minor differences like a VDD pin becoming a GPIO with zero alternate functions) is used across most 8bit/16it and some 32bit parts. I welcome standardised pinouts (i was thinking of replacing a MHCP part with an atmel part that had almost the same pinout but swapped USB pins. SWAPPED. ugh
