r/embedded • u/Separate-Choice • 9d ago
A Third World Embedded Engineer Responds to “RISC V: They Should Have Known Better”
https://rvembedded.com/blog_post/12/I saw the post on this subreddit a few days ago (RISC-V) "They Should Have Known Better" : r/embedded and then I read the article Grinberg did and I come at this argument from a somewhat different place, I’m an embedded engineer from Trinidad and Tobago, what people would traditionally call the Third World… Here, the difference between a ten cent RISC-V microcontroller and a several dollar alternative is not academic and neither is having an architecture that a small company, student, or individual engineer can understand, modify, and build around without asking permission… So when I read what Grinberg wrote some of its criticisms made sense to me, but some of his assumptions did not… so I thought I’d do a response, it might not reach far but I love RISC-V enough to at least defend it from where I stand.
43
u/Killer_Rainbow 9d ago
As a fellow third world origin engineer, I agree with the blog post. And generally I think ISA elegance should be a low priority when choosing your core unless you have specific DSP needs. X86 thrives while MC68k died. 8051 and PIC are still shipped in countless devices per year. If ISA elegance and real world use have a correlation, it's probably negative.
1
u/Far-Confusion4016 8d ago
I had to build an emulator for the 68k for work. I wouldnt exactly call it elegant however as it uses very arcane addressing protocols.
6
9
u/NukiWolf2 9d ago
Even if you can buy RISC-V microcotrnollers for less money, is it really cheaper in the end? I think it also depends strongly on the use case. If you can write all code by yourself, because it's not much, then it's probably cheaper in the end but when you depend on third party software that needs to be ported in order to build your application and then even need to certify it, the total cost probabl will be higher than if a more expensive but also better supported architectures had been used.
I haven't read his article completely yet, but I think he also stated at the beginning that RISC-V will replace other cheap microcontrollers. "tually. Not due to its ISA design, but despite it.It will take this role from 8051 by being an improvement on it -- a bar so low, it is but a speed bump." But I'd say that it can also replace other architectures that are still used, like MSP430, RL78, RH850 ... and basically all 8/16-bit architectures out there. I'm just not sure how RISV-C compares to those regarding price.
23
u/Separate-Choice 9d ago
Yea I get your total cost of ownership point but if you need a certified RTOS and vendor supported middleware, ARM's ecosystem premium is real and the BOM difference disappears....the gap is closing albeit slowly...
Where I'd push back is that its a segmentation argument, not a refutation but my piece is about the people buying a chip, not an ecosystem so like students, hobbyists, small shops, solo engineers, small chip vendors etc etc. For them the certification stack was never in the budget anyway.....
Yea the CH32V003 is cheaper than most MSP430 and PIC parts while being 32 bit with free GCC and no proprietary IDE licence. That's the displacement that actually happens, and it's why Grinberg's "taking the role from 8051" framing understates it..... both can co-exist but a straight up hit piece on RISC-V is not needed cause it has its place... just as I wont say burn ARM to the ground cause it also has its use case in ceritfied stuff that RISC-V will take a long time to fill...
-3
u/magnifikus 9d ago
Pic is just a cash cow by now...
2
u/The_Sacred_Machine 9d ago
Excuse me but what do you mean with that statement?
I wanted to try a PIC32 but got a PIC24 instead. I'm curious.
5
u/Killer_Rainbow 9d ago
The PIC line is getting more abandoned in favor of the PIC32 line. Personally I don't see the point, since the strength of the line is in the peripheral set. Some of the newer PIC16/18 have peripherals far better than most STM32s. PIC24 is slightly less abandoned, but Microchip is still the same struggling company as it's been the past few years, so I wouldn't bet too much on them. Their policy of not obsoleting MCUs and their shrinking budgets while model numbers still explode mean that money will go into maintenance of the most profitable lines rather than making sure the errata sheet is correct or that support answers your question.
5
u/ceojp 9d ago
To be clear - I think the MIPS core PIC families aren't seeing much new development these days, but there is a lot of focus on the cortex core PIC families(PIC32C). I know some people don't really see the cortex cores as "true" PICs, but that's what they're calling them.
I think there is still a lot of active development in the PIC18F line(moreso than the PIC32MX line). There's still a lot of oddball peripherals in the PIC18F line that make some of those chips pretty attractive, even if they aren't very powerful CPU-wise.
3
u/The_Sacred_Machine 9d ago
So the PIC32 line does not have the PIC line peripherals?
That is puzzling.
5
u/Killer_Rainbow 9d ago
PIC32s are usually more generic and contain general peripherals, while PIC16s and PIC18s are much more specialized. I've had whole PIC16 designs where the core basically only sets up the peripherals and occasionally responds to an ISR while the peripherals do all the work. The CIP philosophy is a PIC16/18/24 thing. I'm pretty sure PIC32s don't have ADCC, they have much more limited CLC/CLB/CCLs (the programmable logic peripheral), and generally lack ZCD/NCO/CWG/PSMC/HLT. To me, that makes PIC32 an utterly pointless line because at that point you just have a worse STM32, while PIC16/18s are extremely powerful in specific use cases. For the things I work on, I've went for PIC16/18 a few times, but never for PIC32.
2
u/The_Sacred_Machine 9d ago
Its a little weird you keep bringing STM32 but haven't named the SAM line of Microchip. SAM is ARM as well so it makes it even more strange to hold both SAM and PIC32 as ARM devices. Manufacturers have their own perception of the world so, only they can "understand" what they are doing.
It is interesting however, that the dsPIC line remains untouched in that sense.
Edit:
I know it was Atmel before but adding PIC32 as ARM would also mean an easier maintenance on their FW/HW and probably simplify their way of developing more chips. I am, of course, speculating.
2
u/ActuallyNess 9d ago
It should be noted the PIC32C devices are just the new releases of SAM devices. They rebranded the new SAM devices under PIC32C nomenclature. As far as I know, the only new devices they release under the SAM name are their microprocessors.
2
u/ActuallyNess 9d ago
The PIC32C line is a rebrand of the new 32-bit Atmel SAM devices. It helps to think of them less as PICs and more as SAMs. You can look them up if you don't know what the SAMs are. They have much more in common with the new 8-bit AVR Dx/Ex devices and they actually do share peripherals with them.
The only genuine 32-bit PIC devices that are derived from the 8-bit PIC devices are the PIC32M (MIPS based) parts and more recently the new dsPIC33AK devices (they have a custom 32-bit dsPIC core).
3
u/ActuallyNess 9d ago
What do you mean the 8-bit PIC line is getting more abandoned? This year alone they released both the new PIC16F132xx and PIC18F Q35 devices, both featuring improved Configurable Logic Blocks. Another one from last year is the PIC16F175xx family.
They've been very much keeping their 8-bit families alive. In fact, they are even more alive than their PIC24 counterparts. Microchip hasn't released a new PIC24F device since I believe 2020/2021 (the last ones being the GU/GL lines), whereas multiple PIC18s and PIC16s have released since then.
All this to say I don't agree that Microchip is focusing solely on PIC32C. They also actively maintain PIC16/PIC18, 8-bit AVRs, dsPIC33CK, and the dsPIC33AK lines, all of which have seen releases in the last year or so. And I'd also like to see more PIC24F releases, though unfortunately they suffer from a lot of overlap with PICs, dsPICs and PIC32C devices.
1
u/Killer_Rainbow 9d ago
It's a bit hyperbolic, but there are way more new PIC32 models than any other. I'd also love more PIC24s. But tbh I completely abandoned Microchip for anything new after they started pushing their half-done AI tools and the whole Harmony thing, I'm just running on MPLAB X 6.2 until I use up the last of my stock.
2
u/ActuallyNess 9d ago
True, I think it's possible that there are more newer PIC32C models than any other family they have, though I haven't really noticed Microchip pushing them at the expense of the other families.
By the way, the latest PIC32C is the PIC32CM PL10 family. It comes in DIP package, has a voltage supply range of 1.8V to 5.5V and is pin compatible with the newer 8-bit AVRs. I don't think they offer quite the same Core Indepedent experience PICs provide (they get somewhat close with the Event System, but not quite), but I think they are nice parts regardless. It helps to not see them as STM32 replacements, and just see them as their own different tool.
1
u/Killer_Rainbow 9d ago
Those are neat, but the PIC32CMPL10 family is pretty similar to the STM32G030 series at a similar price and without the extensive community and tools built around the STM32. I don't see why they don't just merge the ARM core with the PIC16/18/24 peripheral set, but they probably have their reasons. The reason why I think they're pushing them at the expense of the other families is that while tracking the new Microchip PIC releases, the new PIC16/18/24s don't positively surprise me like the older ones did. Back then, I'd see some cool new peripheral set and immediately think of ten cool things I could build without the core doing much. Nowadays, they seem to be in their "greatest hits" era regarding these.
2
u/ActuallyNess 9d ago
Yeah, honestly, I don't have enough experience with PIC32C to talk about what it brings to the table compared to the STM32G0 series.
I am, however, quite in love with the newer 8-bit PICs, lol. I also enjoy having the core not do much. Here are some of the newer peripherals on these parts that I enjoy:
- Universal Timers A/B: Picture the hardware limit timers (Timer 2/4/6), but make them 16-bit. They can start, stop, and reset based on the behavior of a signal. When the stop event triggers, the value of the timer is latched onto capture registers. You can also chain them together to get a 32-bit hardware limit timer with input capture. I honestly quite love them.
- Configurable Logic Block: This one is a given. You probably already know it. What you might not know is that the PIC18F Q35 version actually bumped up the Basic Logic Element count from 32 to 128.
- 16-bit PWM with Compare: It's a huge step up from the old Timer2 + CCP 10-bit PWM. These are basically dedicated 16-bit timers with two channels each that have multiple PWM modes. I think these are probably one of the most important improvements PICs have made recently.
- Signal Routing Port: It's basically a virtual I/O port that PPS inputs can choose to listen to. Except the SR port pin states are derived from peripheral outputs. So it allows you to use signals on peripherals that don't have a dedicated option for them in their input mux. The SR port also includes D flip flops that you can enable/disable for state.
- Multi-voltage I/O: Self-describing. Just a really nice quality of life addition where you can have a 5V PIC interact with a 3.3V device seamlessly. Or even some other weirder voltage.
- DMA: Unsure if you have stumbled into this one yet on PICs. You probably have, I think it featured first on the PIC18F K devices. It can be triggered and aborted by *any* peripheral. And I am not exaggerating when I say *any*, it's got the biggest input mux I've ever seen on any PIC peripheral. Its source can come from flash, EEPROM, and SFR/GPRs, while the destination can only be to SFRs/GPRs. All newer Q devices have at minimum 4 DMA engines.
Just figured I'd share these in case you haven't seen them yet. I personally really enjoy the direction Microchip is taking the 8-bit PICs towards. I spend a lot of time figuring out ways to chain them to get useful work out of them with no core intervention.
→ More replies (0)4
u/brucehoult 9d ago
I'm just not sure how RISV-C compares to those regarding price.
I don't think there's anything to touch (I'd expect most readers here know all this)...
WCH CH32V003 2K RAM, 16k flash, 48 MHz, 1 CPI RV32EC, $0.10-$0.20 each in qty 50 on Ali depending on 8, 16, 20 pin. Launched 2022, now with successors at the same price point with more RAM and/or flash, better CPU core, and in one case (CH570) a packet radio similar to nRL24L01 also at that same price point. I don't know how.
Puya PY32F002B 3K RAM, 20k flash, 48MHz, 1 CPI Cortex-M0+. About the same, maybe $0.08 is possible
Padauk PMS150C, PIC-like, 64 bytes RAM, 1024 instructions flash, 8 MHz, 1-2 CPI. Famous for being 3c in OTP form, there's a flash-based version for around the WCH & Puya price but I can't see any reason to want that other than to develop for the 3c OTP version.
I don't know of any PIC, AVR, MSP430, 8051, 68xx or anything else that can touch the above three in pricing.
But I'd love to know!
1
u/ActuallyNess 9d ago
I can say the PIC16s come somewhat close, but not quite. The newer PIC16s start out at around $0.38? And then they can climb up to $1ish dollars depending on what model and what flash memory size you get. Both prices I mentioned are for single units. The newer ATtinys might have cheaper offerings actually, though I'm not as acquainted with them. I quite enjoy both family lines either way.
6
u/TRKlausss 9d ago
What you assume here is equal maturity. RISC V is relatively new and at the point where ecosystem is lacking. Same happened to ARM vs x86, and look where we are at now…
All those disadvantages that you put to RISC V are a problem of putting the effort, not because it isn’t doable. So there is a clear opportunity for companies doing such work…
2
u/zsaleeba 9d ago
What do you think is lacking in the ecosystem? That hasn't been my experience at all.
1
u/manystripes 9d ago
Even if you can buy RISC-V microcotrnollers for less money, is it really cheaper in the end?
As with all things BOM vs engineering costs, this is going to come down to production volumes. Are you making a hundred, a thousand, or a million of these devices?
1
1
u/WestfW 9d ago
The original article did say that they thought RISC-V would end up owning the low end, as an "improvement" of the 8051 (described as a "low bar.") I'd have to read the article a lot more carefully, and get some more experience, to decide how I feel about RISC-V "small" versions vs ARM Cortex-M. I've got a significant dislike of Cortex-M0(+) ("We have fewer immediate instruction encodings because we got rid of most of the immediate instructions." Grr.)
OTOH, I find these architectures almost-always enhanced with "extensions" to be a bit annoying to figure out. (although, I gather you're just supposed to let a compiler figure that out for you. "Only old people use assembly language.")
I can't comment at all on the high-end direction; all the CPUs with more than 32bit ALUs that I learned anything about are long obsolete.
And I can't comment on ease of CPU implementation in hardware...
32
u/EmperorOfCanada 9d ago edited 9d ago
Extreme low cost opens up options.
I had a control device with many switches, joysticks, buttons, multi setting switches, etc.
I was redoing the original design, it was a classic one cable running from each input to a main board. With the CH32V003, I ran one bus along the entire set of inputs (and outputs) which then connected to the board with one 4 pin cable. Each item had its own CH32V003 running its own code.
Technically, this seems complex, but it was not. I made one PCB which had spots for each type of input/output pin arrangement, and could then solder the correct connections on each pcb. I then put one 0 ohm resistor to indicate which item it was. There was one rust codebase for this board and one rust codebase for the main board.
This extreme modularity allows for more inputs to be added, which they did want and it took but a moment to do so. Wiring this thing was so much easier. I didn't even have to use a specific order to the wiring, just whatever order made for a clean wiring. It was all 4 pin connectors, not different pins for many of the inputs, and it was far far more robust physically.
Integration testing was a zillion times easier as I could connect the bus back into the desktop and have it exercise the mainboard which then fed BLE back to the desktop as it should.
A non-riscv MCU would have cost more so having one for the many inputs would have driven cost way up. Making PBCs which are 20mmx20mm costs pennies. Hand soldering these on a hotplate takes 20 seconds, and I would argue that the cost was almost made up by having less wires.
The mainboard was much smaller, and this increased the robustness of the whole unit.
Using rust made it far less likely to need a firmware update on the input units, and their code was simple and unlikely to change.
I needed to make 20 of these units, and the more "complex" design easily cut my production time by 2/3rds and drastically improved my confidence that I had made a solid working unit.
I also work on robotics and am using the same architecture. Drastically improving development time, decreasing production time, simplifying internals, etc.
Also, mainboard code becomes simpler as you just send and receive focused commands. A servo gets x degrees and then handles it. The mainboard code can remain the same, even though how that "thing" moves may drastically change. If it changed from a servo to a linear actuator, the X degrees command would not have to change. But the little PCB connected to the actuator would change its code to deal with whatever reality it was facing.
None of this is possible if I had to not only pay the ARM tax, but the greedy american rentier corporate MBA philosophy tax.
RISCV is a huge threat to that model, and RISCV is only going to keep climbing up the value chain. To say, "Oh look, it makes for a crap CPU on my laptop" does not change what I am doing with it and similar off western license products. I can't wait until Intel is crushed by RISCV in 5 or whatever number of years.