I wager that when it comes to Cyphal-enabled embedded systems, functional safety is occasionally a relevant concern, and it shold be considered when deciding on which MCU to use. Requirements of ISO 26262 or AEC-Q100 limit the set of MCUs significantly but those that are left are often well-suited for applications where Cyphal is likely to be found. Notably, you will not find STM32 in that set, and for a good reason. Consider these (I am not paid by anyone to promote anything, this is based on my own experience but YMMV):
-
I am going to beat @iain.galloway to it and suggest one to consider NXP S32K – modern general-purpose ARM Cortex-M7/M4 MCUs with advanced safety, AEC-Q100 qualified. They come with ECC on all memories and 5V operation support (with limitations though) which is desirable in high-EMI environments. The newer chips also support lockstep cores but I have no experience with these yet. Some time ago I was looking for an AEC-Q100 MCU that I could run Zephyr on and at that time, S32K1 was not a viable option for that, so beware; right now things might be different but then I would cautiously check the list of peripherals supported by the RTOS. My personal opinion is that these are great chips but last time I checked the software side was a bit weak. It wouldn’t matter if you are planning to go baremetal though.
-
Another interesting family is the automotive Microchip ATSAM D / ATSAM E / ATSAM V. On the consumer — functional safety spectrum they are closer to the former and you will notice the lack of support for high-voltage operation and ECC on all memories, but the upside is the much better software support in third-party stacks and the ability to use Zephyr with decent peripheral support out of the box.
Regardless of the platform chosen, I would by default caution everyone against reliance on the MCU peripheral drivers shipped by the chip vendor because that software usually belongs in a trash can. Stick to the facilities provided by the RTOS instead, use decent third-party stacks, or write your own abstractions.
All of that said, in 2022 it might be more prudent to drive the design based on the software stack you are interested in rather than on the chip because of the shifting complexities. Just go look at the list of platforms supported by your RTOS/framework of choice and then select strictly based on that (with additional constraints applied as necessary, such as AEC-Q100 / ISO 26262). For instance:
- Zephyr: Supported Boards — Zephyr Project Documentation
- NuttX: https://nuttx.apache.org/docs/latest/introduction/supported_platforms.html
- Rust HALs: GitHub - rust-embedded/awesome-embedded-rust: Curated list of resources for Embedded and Low-level development in the Rust programming language
This argument only makes sense if you are planning to produce your hardware in copious amounts while its software remains relatively unchanged or unsophisticated. For many Cyphal-enabled projects, this is not the case and you will have a hard time offsetting the benefits of a marginally cheaper MCU against the rising costs of software development and maintenance. Unless you require selling your devices in multiple thousands of pieces on a highly competitive market where every cent matters, you are likely to be better off choosing a sufficiently rich platform and software ecosystem that would allow you to get to the market faster and spend less time worrying about squeezing your software into limited chip resources and more time thinking about the business logic and the problem domain.