I’d like to start a little brainstorming session on what MCU you would use if you were to design a brand-new OpenCyphal product. I do realise that this somewhat depends on the exact nature of the product-to-be-designed (i.e. if you need hardware support for a specific non-generally-available interface or a hardware accelerator).
However, I think it’s safe to assume that most products can be built with a generic MCU interacting with some sensor/actuator via one of the “classic” interfaces such as SPI, I2C, SDIO, Ethernet, USB (god forbid). I believe this to be the reason why we see such a prevalence of STM32F4 based designs (The reason for the prevalence of STM32-ARM-in-general being caused by them being one of the first semiconductor vendors with a decently usable HAL).
However, I feel that as needs for computing power are rising the STM32F4 is maybe getting a bit old. Consequently I’ve been looking into STM32F7 and STM32H7. The F7 series is featuring a Cortex-M7 over a Cortex-M4 (as the F4 series does). ARM provides a decent comparison table between the two architectures here. Looking through the chart I’d say the main advantage is higher “throughput” due to the availability of caches and general architectural improvements, possibility for further speed-up due to existence of tightly coupled instruction and data memory (TCM) and support for double-precision (DP) FPU on some F7 CPUs.
The H7 series seems to be a bit too big for a typical OpenCyphal enabled application (as I imagine it), unless you specifically need hardware support for TFT-LCDs, MIPI-DSI, JPEG-Codec, etc. Also some of the H7 series are a asymmetric combination of a Cortex-M4 and a Cortex-M7, such as the H747 used in Arduino’s Portenta H7 product. Personally I feel running two cores on a single package is a unnecessary complication as concurrency is already hard on desktop systems, much harder on embedded systems where there’s no support for std::thread, std::mutex, std::future, etc. (I think you get the idea).
You may have noticed I’m focusing on the STM32 product line, but this is in no way set in stone, it merely reflects my own exposure to MCU types so far. The only “interface requirement” I have is that I have at least two CAN FD capable modules on-chip.
Dear reader: Which MCU family would you recommend and why?
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:
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.
The NXP S32K1 had some difficulties with the CAN-FD IP. The S32K3 series has corrected this and includes TSN support in it’s Ethernet IP. While MCUs like the S32K314 and the H725 seem like supercomputers compared to ye-olde ATMega328 they are completely reasonable where a product is not as sensitive to a few dollars here and there in the BOM and they are capable of fully exploiting the promise of Cyphal.
802.1Qbu is interesting because it’s the latest and last piece in the whole “deterministic Ethernet” story approved as part of 802.1. Because it’s so new it’s not easy to find support for it yet.
Thank you both Scott and Pavel for providing your take on the topic. Reading through your replies I get the feeling that both of you are seeing “deterministic” Ethernet as the future field-bus-of-choice (or at least as a viable alternative PHY to CAN) for interconnecting OpenCyphal nodes. Given the higher throughput of Ethernet over CAN it seems you expect applications with a need to share larger amounts of data between nodes. Would you care to comment on this observation?
Actually my contra-argument was that the additional software-complexity due to of having two cores in one package is usually not worth the headache (unless your application has very specific needs which would benefit from such an architecture).
Not sure why you are pulling out the ATMega328P out of the bag . There are plenty of cheaper Cortex-Mx CPUs available . Given the cost of software/firmware development for modern-day complex embedded systems imho means BOM reduction via MCU selection is only a topic for very large consumer facing applications (i.e. automotive).
. There are plenty of cheaper Cortex-Mx CPUs available 
. Given the cost of software/firmware development for modern-day complex embedded systems imho means BOM reduction via MCU selection is only a topic for very large consumer facing applications (i.e. automotive).