-
I agree but that is not a reason to just dismiss NRE costs and only look at the costs of a single part.But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.
All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero. -
I agree but that is not a reason to just dismiss NRE costs and only look at the costs of a single part.
That's true too. It is meaningless to evaluate suitability of different MCUs without knowing the purpose, budget and many other factors. None of these can be dismissed. That is exactly the reason why we cannot perform a comprehensive analysis on the forum. However, it doesn't mean that isolated factors, such as unit price, cannot be discussed and/or compared. -
When I search for STM32 programing it all seems very confusing due to all the aproaches you have (Standard Peripheral Library, CubeMX, etc).
It's confusing, but luckily, there's an answer: you can just do all of it normally, like you did with AVR or PIC processor: by reading the reference manual and configuring the registers as you wish. The peripherals are a bit more complex (due to being more capable), but it doesn't make it too hard to learn. STM32 libraries make everything difficult since they don't abstract the implementation details out as they should, but only add an extra layer of burden and uncertainty.
Doing it without the library structs and functions produces much more readable code, quicker development, higher level of understanding and more robust implementations, compared to library code copypasting from Stackoverflow; this has nothing to do with the concept of using libraries in general, but everything to do with the STM32 libraries, which, unfortunately, are totally unusable and completely doomed. This is a trap for young players, who will find a lot of confusing examples on the web, while it's difficult to find simple examples that don't use the libraries.
If you require a good peripheral abstraction layer and usable libraries that allow you to work on the higher level, and you don't want to write this layer from scratch, then STM32 is definitely out of question. AFAIK, most others have it at least somewhat better, although it's seldom brilliant. For me, having good libraries and abstaction layers was not too important, since they tend to suck anyway, and I like to work on low level, so I work with STM32 chips quite a lot, and have a love-hate relationship with them. They do have documentation issues and undocumented silicon bugs (even though the errata sheets are quite long), and they ignore reports of non-documented silicon bugs, instead of being responsible and updating the errata sheet. But I guess most other complex 32-bit MCUs have similar issues as well.
Generally, the modern 32-bit MCUs have peripherals that are a lot more capable than something on an 8-bit AVR, so that even when you have more processing power available, you end up using less of it; more of your code ends up initializing the peripherals that can do surprising amount of the work so that you don't need to do timing-critical things in software as much. -
Look here:When I search for STM32 programing it all seems very confusing due to all the aproaches you have (Standard Peripheral Library, CubeMX, etc).
It's confusing, but luckily, there's an answer: you can just do all of it normally, like you did with AVR or PIC processor: by reading the reference manual and configuring the registers as you wish. The peripherals are a bit more complex (due to being more capable), but it doesn't make it too hard to learn. STM32 libraries make everything difficult since they don't abstract the implementation details out as they should, but only add an extra layer of burden and uncertainty.
Doing it without the library structs and functions produces much more readable code, quicker development, higher level of understanding and more robust implementations, compared to library code copypasting from Stackoverflow; this has nothing to do with the concept of using libraries in general, but everything to do with the STM32 libraries, which, unfortunately, are totally unusable and completely doomed. This is a trap for young players, who will find a lot of confusing examples on the web, while it's difficult to find simple examples that don't use the libraries.
If you require a good peripheral abstraction layer and usable libraries that allow you to work on the higher level, and you don't want to write this layer from scratch, then STM32 is definitely out of question. AFAIK, most others have it at least somewhat better, although it's seldom brilliant. For me, having good libraries and abstaction layers was not too important, since they tend to suck anyway, and I like to work on low level, so I work with STM32 chips quite a lot, and have a love-hate relationship with them. They do have documentation issues and undocumented silicon bugs (even though the errata sheets are quite long), and they ignore reports of non-documented silicon bugs, instead of being responsible and updating the errata sheet. But I guess most other complex 32-bit MCUs have similar issues as well.
Generally, the modern 32-bit MCUs have peripherals that are a lot more capable than something on an 8-bit AVR, so that even when you have more processing power available, you end up using less of it; more of your code ends up initializing the peripherals that can do surprising amount of the work so that you don't need to do timing-critical things in software as much.
https://github.com/xcvista/STM32F407-Startup/blob/master/platform/src/stm32f4xx_it.c
https://github.com/xcvista/STM32F407-Startup/blob/master/platform/src/system_stm32f4xx.c
I decided to give the STM32F407 startup code a rewrite, and ended up getting this easily understandable code. -
STM32 libraries make everything difficult since they don't abstract the implementation details out as they should, but only add an extra layer of burden and uncertainty.
You could easily as well argue the other way around.
Doing it without the library structs and functions produces much more readable code, quicker development, higher level of understanding and more robust implementations, compared to library code copypasting from Stackoverflow; this has nothing to do with the concept of using libraries in general, but everything to do with the STM32 libraries, which, unfortunately, are totally unusable and completely doomed. This is a trap for young players, who will find a lot of confusing examples on the web, while it's difficult to find simple examples that don't use the libraries.
CubeMX icw SW4STM32 works, it is definitely not great, as you say a lot of layers but it works and there is a forum with thousand people giving you support and as last resort a company that has people added to the forum to add support.
Compare that to your own bare metal implementation or that from anyone else, there is no support, it might work but easily as well fail at some time if the youngplayer wants to do something else, eg add a peripheral.
The 3rd baremetal engineer has its own way of thinking and working so created that code with his mind which is perfectly ok for him/her but another person needs to grasp that way of thinking, invest in understanding the code. Often there is no or minmimal documentation, minimal comments in the code, no support , that considered it is equally bad in my eyes.
Now I have started with CubeMX and SW4STM32 with a modern nucleo board with a decent processor (STM32L4xx or STM32F4xx are good for starters, don't use the F1 since it is old and has lots of quircks) and had it up and running in one day with a blinky. Another 1 hour for a UART that did not do what I wanted
So there I encountered my first issue, it only had interrupt functionality to receive a fixed number of bytes. Calling the function with 1 byte half the data was lost. So looking at those huge functions with extra code around it to make it pretty robust I hacked and slashed it back so the IRQ function would not call 3 layer deep other stuff but in case there was no error it stored the byte in my own queue module and be done with it. So total 1 day and I had a uart working, not bad.
A youngster might need a week or more with help from the forum to get things going but way better than starting from scratch.
Then another argument: code size, I know MX consumes code as we drink water but my project above took 12kB , I still have 988kB left, so what is the problem? For mass production yeah don't go that way, for hobbieist, amateurs One of a kind projects, come one , unless you are a student or unemployed your time costs more than the ROM on the chip.
IMO the CubeMX can be used as a start to get things going: I/O properly defined, clocks and peripherals defined and working. Then the hard stuff starts to tweak and adjust it to your own personal needs.
For youngplayers, stick to the HAL because then you have support.
-
What about Renesas?
Surely they don't support beginner-friendly boards and their prices is to the roof... but their quality is nice. I do hope I get to use them one day when I have the chance.
They have "gadgets" boards like Sakura and Peach boards with what they call MPU (mircoprocessor unit), because MCU is too mainstream.
I'd like to take your opinions on why such a very powerful MCU (or MPU) is not so popular on this forum or in general, despite being one of the best sellers and kinda the kind of automotive market as far as I know.
___
One little thing off the side: which one of these 32-bit MCUs offer protection from stealing firmware? I bet commercial product designers take this so serious, aren't they?
If you are going to design a commercial product, will you use code protection features?
I am saying this because I could get the AVR code of a washing machine board then burn it on another new chip then solder it instead of a faulty one... this makes repairing a whole board price without even doing a thing xD. Not everyone knows how to do it, despite being simple. I am going to try the same with Freescale and Renesas products. Renesas ones use protection but somehow people are confident that a USB-to-serial flash programming will get the code out of it... it is just a trial to see if the chip is protected or not.
-
One little thing off the side: which one of these 32-bit MCUs offer protection from stealing firmware? I bet commercial product designers take this so serious, aren't they?
I think most vendors offer a lockdown mode that either requires a mass erase or is impossible to remove. For what I know STM32 have a code protection level 2 that completely disables any programming and debugging interfaces, disables the internal bootloader entirely, and not even allow the application to switch it back.
If you are going to design a commercial product, will you use code protection features?
I am saying this because I could get the AVR code of a washing machine board then burn it on another new chip then solder it instead of a faulty one... this makes repairing a whole board price without even doing a thing xD. Not everyone knows how to do it, despite being simple. I am going to try the same with Freescale and Renesas products. Renesas ones use protection but somehow people are confident that a USB-to-serial flash programming will get the code out of it... it is just a trial to see if the chip is protected or not. -
What about Renesas?
I agree that they aren't widely used in hobbyist circles. Probably just one of those momentum things. The (non-pink) evaluation boards are a little costly, in line with that 90s era pricing model; you might pay in the $50-200 range? The pink "Gadget Renesas" boards seem to be targeted to the hobbyist market in Japan only. However, after you spend a little more for the dev board I don't think they're unapproachable by hobbyists who are already familiar with microcontrollers. The YRDKRL78G14 evb is pretty neat.
Surely they don't support beginner-friendly boards and their prices is to the roof... but their quality is nice. I do hope I get to use them one day when I have the chance.
They have a good series of entire books, published for free, that are very readable. They seem to have a sane architecture conducive to C compilers. Good documentation, a standard Eclipse based free IDE (e2 studio), and a free GCC toolchain available. The only unusual thing I have noticed is that some entire lines of a given microcontroller will not be available through distributors. It seems they are focused towards high volume automotive parts where you are expected to contact them directly and get a quote on large quantities.
The cost of the chips is about on par with their competitors:
I am increasingly using RL78 and like it enough that I will pay for their optimizing compiler. I want to try out their RL78/G1D with integrated Bluetooth Low Energy, when that becomes more available. Their E1 programmer is the only programming tool I've seen that has a self-check function; I wish everyone else did that, especially with what you pay for some of these things.
That all said, there is no secret magic feature of these microcontrollers just because they are Renesas and move in high volume. You can do most of the same things with an MSP430, STM32, etc. -
Renesas: difficult to get and expensive for low quantities.
Goto Farnell type Renesas goto microcontrollers, 44 found only 13 available rest no longer available, look at price for 32 bit only 50MHz.
Then type STM goto microcontrollers >1000 ARM, >110 other
Repeat with Microchip/Atmel, NXP , TI you get the picture. -
Renesas: difficult to get and expensive for low quantities.
Well, I can't speak for the situation outside the US, but:
Goto Farnell type Renesas goto microcontrollers, 44 found only 13 available rest no longer available, look at price for 32 bit only 50MHz.- Digikey: 841 parts active and available
- Mouser: 172 parts in stock
- Arrow: 470 parts in stock
- 50MHz RX200: $6.38 to $3.31 depending on quantity
- 40MHz RX200: $3.72 to $1.70 depending on quantity
-
I completely disagree. For hobby projects or any other one-off, the NRE is the dominant cost. The cost of the parts is a pitance compared to the time to develop. You don't ammortize the NRE over thousands or millions of units, it is all for one unit. The cost of a single PSoC5 is equal to less than half an hour of time. So even if it is way overkill and 80% of its resources go unused, if it makes the solution easy and quick then it's a good choice. If I was building a million of them, then I'd spend a lot of time to choose something that fits the application well without added cost for unused features. My hobby time is neither free nor plentiful.But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.
All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero. -
For that IDE that is mandated to use, either people will get straight up shut down by it if they have only Linux or macOS, or will fumble a lot due to the (fairly) steep learning curve of PSoC. It is often faster just cook up a small circuit on a breadboard and test if it works than go through the nitty gritty bits of PSoC Creator. I even have STM32F373CCT6 on DIP adapters just so I can prototype with even advanced processors like that quickly. Also where is your CMSIS hraders? A lot of code may not expect vendor library in place but do expect to find CMSIS.
I completely disagree. For hobby projects or any other one-off, the NRE is the dominant cost. The cost of the parts is a pitance compared to the time to develop. You don't ammortize the NRE over thousands or millions of units, it is all for one unit. The cost of a single PSoC5 is equal to less than half an hour of time. So even if it is way overkill and 80% of its resources go unused, if it makes the solution easy and quick then it's a good choice. If I was building a million of them, then I'd spend a lot of time to choose something that fits the application well without added cost for unused features. My hobby time is neither free nor plentiful.But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.
All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero. -
Just a few of the good things in a PSOC.
To me, the biggest drawback of the PSoC is that no currently available part has hardware floating point. The PSoC 5 is based on Cortex-M3 (which doesn't have an FPU) rather than a Cortex-M4 (which does). -
I have long raised this question of the missing FPU for an analog-centric chip. And they decided to dismiss it entirely.Just a few of the good things in a PSOC.
To me, the biggest drawback of the PSoC is that no currently available part has hardware floating point. The PSoC 5 is based on Cortex-M3 (which doesn't have an FPU) rather than a Cortex-M4 (which does). -
Well Farnell usually is a good indicator of popularity and future availability. Until about 15 years ago Hitachi (now Renesas) microcontrollers where quite popular but nowadays they seem to have vanished. Maybe this has to do with lack of good low cost (free) tools. Back in the old days the distributors would hand out 'demo' versions of the compilers to keep sales going.Renesas: difficult to get and expensive for low quantities.
Well, I can't speak for the situation outside the US, but:
Goto Farnell type Renesas goto microcontrollers, 44 found only 13 available rest no longer available, look at price for 32 bit only 50MHz.- Digikey: 841 parts active and available
- Mouser: 172 parts in stock
- Arrow: 470 parts in stock
- 50MHz RX200: $6.38 to $3.31 depending on quantity
- 40MHz RX200: $3.72 to $1.70 depending on quantity
-
Maybe this has to do with lack of good low cost (free) tools. Back in the old days the distributors would hand out 'demo' versions of the compilers to keep sales going.
But they do have free dev tools, though? They have the same Eclipse / GCC combination that most other companies provide:- e2 Studio (Eclipse)
- GCC for RL78, RX, etc.
With the above, there is better access to a free toolchain than for PIC.
I just want to buy CC-RL (their proprietary compiler) because I don't really like GCC, and I think the Renesas one makes better code. Personal preference.Well Farnell usually is a good indicator of popularity and future availability. Until about 15 years ago Hitachi (now Renesas) microcontrollers where quite popular but nowadays they seem to have vanished.
I don't know, is distributor availability really a good measure of popularity? The company itself seems to be doing just fine:
Note that most of the growth of their competitors was purely due to acquisitions.
Given those numbers, if a distributor's stock was an indicator of overall popularity, why wouldn't Farnell stock Renesas? Surely as a business they would want to sell based on what is happening today, not how popular it will be five years from now. I mean, Farnell sells Raspberry Pis; does that mean they are a more popular product than Renesas chips? Maybe in certain circles.
I just do this on my own as a low volume purchaser, so I have no "industry perspective" on what is going on. Keep that in mind as I'm really unqualified to know what is going on here. However, if it is like most other B2B companies, my guess would be that Renesas is just picky about their sales channels. Since they cater to the automotive market, I'd guess they know the names of all of their potential customers and have or are trying to establish direct sales relationships with them. They are probably not the types of customers that order through distributors (a.k.a. middlemen). Like I was saying earlier, Renesas have entire lines of various microcontroller families (hundreds of parts) that I can't find at any distributors anywhere, but which are clearly being produced and supported. They probably expect you to call, strike a deal with with a sales droid, and put in your first order for a few pallet loads.
Likewise my only experience with Farnell is that they don't seem to be competitive on price or selection here in the US, but that they seem to be big in Europe. Even today, I think geography has a huge role in what we are exposed to. For example in the other thread over there was a lot of discussion about WCH and Allwinner chips. I know these move in high volume (Allwinner especially), but again they are not available at any distributors I buy from. Does that mean they are unpopular? Or does it just mean that you'd have to be in China to be exposed to that ecosystem? -
They are supposed to be used in ultra cheap devices as MPU. If you factor in R&D cost (due to poor documentation and barely hacked up Linux kernel) and logistics cost (to send someone to China just to purchase and do local QA) as well as patent cost (to be legally imported to western world), they are not that cheaper compared with NXP/FS MPUs.
I assumed as much; documentation is one of my critical needs and I will pay a lot more for a well documented product. But if you are making tablets or coffee machines I expect the equation works the other way around. -
At least for Allwinner MPU the only folks that is actually interested in the documentation is the folks in linux-sunxi community trying to write and mainline the drivers. For us using the chip all we need is a simplified documentation produced by the community (in English anyway) that allows us to boot the chip up.For example in the other thread over there was a lot of discussion about WCH and Allwinner chips. I know these move in high volume (Allwinner especially), but again they are not available at any distributors I buy from. Does that mean they are unpopular? Or does it just mean that you'd have to be in China to be exposed to that ecosystem?
They are supposed to be used in ultra cheap devices as MPU. If you factor in R&D cost (due to poor documentation and barely hacked up Linux kernel) and logistics cost (to send someone to China just to purchase and do local QA) as well as patent cost (to be legally imported to western world), they are not that cheaper compared with NXP/FS MPUs.
One Chinese chip made the exception, ESP32, but so far that's the only one I know, with good BSP (though not Linux), English document and no legal issues (no known patent infringements, no known copyright issues, and they officially offers FCC certified modules).
As of patents what technology you suspect is not useable without license? You can skip the video engine (contains MPEG license issue) but it does not have a community driver anyway. I know SD can be a common target here but keep in mind SD interface using SPI, 1-bit and 4-bit are not license encumbered as those are also covered in the MMC standard.
For WCH most of their products runs their own propertiary mask programmed core (hence can be treated as a black box.) The few chips that contained licensed IP they did it right way. -
That is the problem but so does nVidia or Imagination (PowerVR) do this too. Allwinner do drop code but blobs are common.At least for Allwinner MPU the only folks that is actually interested in the documentation is the folks in linux-sunxi community trying to write and mainline the drivers.
That's the problem. An IC company doesn't provide true GPLed kernel at all is quite questionable. A third party repo is appreciated, but don't you think it's supposed to be the job of the official who monetizes on their chips? -
At least it seem to me that Allwinner don’t mind a potential GPL violation suit or on the receiving end of the said leader’s F bomb or the proverbial bird.That is the problem but so does nVidia or Imagination (PowerVR) do this too. Allwinner do drop code but blobs are common.
And if I run a chip company, I don't want a global software leader to say F me.
I'm fine with binary blobs for FW, but for code running on the same CPU in the same memory space of kernel, I prefer not to have blobs. -
Some mcu companies only target business to business sales in huge quantities.
Broadcom comes to mind with their socs that have m4 cortex in them, try find a datasheet, it is unobtanium unless you are working inside such a business deal company.
For an individual the smart move is to go with the mainstream companies that offer documentation, support and where forum members can help with experience.
. -
For an individual the smart move is to go with the mainstream companies that offer documentation, support and where forum members can help with experience.
I agree, those are very important things. I like and use Renesas personally (along with many other platforms / manufacturers) and find the documentation enough for my purposes, but I won't say that everyone needs to drop what they are using and go pick up some Renesas chips. At the end of the day there are plenty of chips that do the same things. I think we're lucky to have so many choices today.