...
Option 2 is to use two controller boards and have them communicate over something like UART. This is also simple electrically, as it really just requires connecting the mezzanines of the two boards. It also uses proven components, such as our native CAN and UART peripherals. The downside is that we'll need to manage two versions of the firmware for each board. We can use IO lines to allow the firmware to determine which side it's on at runtime, but we would need to be careful about how we designed the translation layer.
Follow-up: We will need a UART↔CAN translation board for driver display, so that could share the same firmware with one of the boards.
Variant: We could put another STM32F072 on the carrier board which solely acts as a UART ↔ CAN translation layer.
Option 3: STM32F4
Option 3 is to use an STM32F4 or similar chip with 2 CAN controllers. This is the most complex electrically, requiring the bringup of a new chip. We can use the regulator from a controller board, but the chip itself is unknown. Using a more powerful chip will allow us to keep all the firmware on one chip and have 2 native CAN controllers, along with a faster clock speed and FPU support. If we were to look into control algorithms, we'd probably want more power. It will require supporting the F4 series in our build system, but that should be relatively simple.
Follow-up: The STM32F103 is promising. It's a Cortex-M4F with 2 CAN buses for $10.