Will-st-develop-riscv-alternatives-to-the-arm based-stm32 MKII

[Riscy00_UPP]

In reference to these questions 5 years ago (unable to post link, not allowed for new member., I'm looking through the RISCV which is competing against CORTEX or ARM. Out of interest, what is ST.com doing with RISC-V and future roadmap or they intended to keep it out since Cortex/ARM is doing fine?

[Pavel A.]

Yes, Cortex/ARM is doing fine. Then why to go for risc-v? What can it do that ARM cannot?

It's understandable why, for example, Intel, uses risc-v: they already buy some IPs from ARM and this is ridiculous. But ST?

[Riscy00_UPP]

I sense RISC-V seem relevant for custom application under embedded application and server and more where they put in their own IP (not open source) next to free ISA under RISC-V (open source). I found some youtube that showed Cortex performs better under the same clock freq than RISC-V. My concern with so many vendors, there is going to be a portability issue between them and they seem to lack a CMSIS library (please correct me if I'm wrong, I saw NMSIS, which is a clone of CMSIS by China). Would RISC-V be at the right place for the embedded market in a similar context (along with advanced peripherals) within NXP, STM32, TM4C, etc? I accept RISC-V and FPGA from Microchip, etc look attractive due to the high Ethernet data rate, but no stock. It gives more freedom for a vendor to create application specific and manufacture MCU for internal use. However, because of free ISA with simple low-cost IP-based peripherals, it is possible to market embedded MCU in competition against CORTEX-based devices, especially high-volume products. I would expect more from RISC-V in the coming years.

[Tesla DeLorean]

I think RISC-V is going to make significant in-roads into the market.

Having decades of experience build/working on SoC using ARM, MIPS, SPARC, V850, I'm deep into the don't care territory, build with portability in mind, and just need decent set of tools to succeed.

Will ST add RISC-V? I'm not sure, they'd need to write smaller checks, but it does complicate their support significantly. Dropping a GNU/GCC compiler into their platform being the least of the issues.

I think the stable of STM32 parts is already becoming a bit unsustainable and unmanageable as it is. There needs to be a culling. Kind of tied their hands with the 10-year commitment, and need to basically freeze support of some and put them out to pasture. They can keep making/shipping as long as the fab, assembly, test can deal with them, but stop the incessant software churn and regression testing that causes.

Not sure ST needs the RISC-V, does open the door for smaller vendors, and those with FPGA basis. This might be where most of the value comes from, being able to make better designs if all the inflexible / compromised peripherals can be junked.