Business advice that is tantamount to "Oh, you should just make a better product" is basically bad business advice. Of course they should, everyone should. But the problem is that if they tried, it (1) costs money and (2) leverages no existing advantages.
These low-margin companies live and die on compatibility and integration. The reason you pick a STM32-whatever as your choice for your new product is generally at least partially because your existing staff know the tooling and your existing production people know the board integration requirements.
Swap that for some new RISC-V gadget and, well, you might win! Or you might find your customers walking across the street to buy someone else's gadget, because yours has no advantages.
Ergo, if you're STMicro, RISC-V is a threat in a way that "Oh, you should just use it yourself" doesn't address.
Microcontrollers are, all things considered, not that much about the ISA itself, especially when we've gotten to 32-bit controllers big enough to program in C or higher-level languages.
People aren't reading the raw assembly and juggling registers themselves anymore. But they do care about the onboard peripherals, documentation, and tooling. The STM32 ecosystem is huge because they've nailed those things.
I could see a STM32Vxxx range, same basic design but drop a RISC-V core in, and new-dev projects will adopt it if it's got the same functionality bit is a nickel cheaper.
I can 100% guarantee to you that's not the case. Existing shipping products in this world are based on proprietary toolchains, HALs like CMSIS that are ARM-only, Eclipse-based IDEs that teams refuse to move away from, build tools wrapped around custom linker scripts for one architecture that no one understands anymore, ...
This isn't a FAANG office where everyone's an expert and people change tools weekly. Commercial firmware work for "boring" devices is extremely conservative, and there's a ton of money left to be made shipping junk that's merely "compatible".
That audience is sort of immaterial to the argument.
If you have a firm that's committed to a frozen image of the platform on a specific date, they'll stick with existing products or modest riffs on it. The same premise is why we'll still see Z80 and 8051 derivatives until long past the heat death of the universe.
This is more about why a firm like STMicro doesn't need to freak out too much about RISC-V. There's no reason they 1) can't continue to sell ARM alongside RISC-V for the more change-averse audience and 2) leverage their established reputation in onboard-peripherals, toolchain, and documentation as their competitive edge.
Done right, this can be a real "commoditize your compliment" play: they can focus less effort on the boring "core CPU" functionality of their MCUs and divert it for the parts of the product they can offer a stronger case for.
> That audience is sort of immaterial to the argument.
You lost me. "That audience" is probably 80% of ST's market. If you're not talking about business as it exists then I don't know what your argument is about. It's certainly not responsive to the point I was making, which is that ST (and similar companies) is exposed to RISC-V as a business risk in a way that Intel is not.
> They will for sure should they not switch to the standard ISA.
OK, no, that's just not true. Google "adoption curve". Saying that technology X is likely to win out eventually is not the same thing as saying there's no revenue to be had selling "legacy" technology Y. Even today people still fix bugs in the occasional COBOL gadget.
And if you're one of the companies (STMicro is one) selling at least partially "legacy" technology (they'd say "mature"), then anything that accelerates motion along that curve is a threat.
How is RISC-V threatening them exactly? They can (and should) switch to RISC-V.
Note NXP is already doing so[0], and that Atmel is part of Microchip[1].
0. https://www.nxp.com/company/about-nxp/leading-semiconductor-...
1. https://www.microchip.com/en-us/products/fpgas-and-plds/fpga...