Hello,
I am working on a commercial vending machine controller and would like to get feedback from engineers and experienced STM32 designers regarding a system architecture change.Problem Statement
The current single-MCU design is constrained by:
Timer availability, particularly for stepper and DC motor control
GPIO interrupt count, driven by sensors and safety inputs
GPIO pin availability, limiting further expansion
Increasing real-time jitter when multiple loads operate simultaneously
These constraints are no longer addressable through software optimization alone and are limiting both scalability and reliability. This has led us to consider a multi-MCU architecture.
Proposed Architecture Master MCU
Device: STM32H563ZIT6
Responsibilities:
All sensor acquisition (ADC and digital)
Control logic and system state machine
Recipe execution and sequencing
Safety checks and fault handling
Communication with UI/HMI
The master MCU does not generate direct motor timing signals.
Slave MCUs (2x)
Dedicated load-handling controllers
One MCU for stepper motor control
One MCU for DC motor / PWM-based load control
Slave MCUs perform only deterministic actuation
No sensor acquisition and no business logic are implemented on slaves
Inter-MCU Communication
Primary option: CAN (FDCAN), chosen for arbitration, fault handling, and robustness
Secondary option: RS485, considered for lower-priority or legacy expansion
A block-level architecture diagram has been attached for reference.
Current Peripheral Usage on STM32H563 (New Approach)
Even with this split, the master MCU remains heavily utilized, which is why all motor timing responsibilities are fully offloaded to slave MCUs.
Points for Discussion
Is this master + load-slave MCU architecture a suitable long-term solution for vending machine or appliance-class products?
From an STM32 architectural perspective, are there recommended design patterns for systems with heavy timer and interrupt usage?
CAN vs RS485 for multi-MCU control:
CAN appears preferable for arbitration and fault handling
Are there any STM32H5-specific considerations or limitations?
What are the common pitfalls in such systems (boot sequencing, synchronization, fault recovery, debugging) that should be addressed early?
From a product lifetime perspective (8–10 years), does this architecture appear robust and maintainable?
Request for Feedback
We would appreciate feedback from:
application engineers
Developers with experience in multi-MCU STM32 designs
Engineers who have implemented CAN-based industrial or appliance systems
Thank you in advance for your time and insights.
Best regards, Praveen Kumar Boatload Minds Pvt Ltd.