Running 2 uCs instead of 1

[LMorr.3]

Hello,

I'm building a device which will have a user control panel with knobs ( adc ), buttons, encoder knobs, and LEDs etc which will use up many pins.  The device will perform time sensitive output tasks such as DAC and PWM based on user input.

I'm thinking of using two uCs instead of one;  The first to handle all the UI input and the second to handle the output tasks.  My plan is to have the user interface uC send short commands to the second uC over SPI.  Some advantages include being able to test my device by just sending serial messages instead of having physical knobs, buttons, etc.  I could 'connect' different types of UI boards, as long as they can send SPI messages to the second uC.  I would also have more peripherals/pins to work with.  I could also use USART as well as SPI so that I could connect a USB->Serial to my board to send commands to test.

I was planning on sending a static sized 'packet' ( and not variable packet size ) so that the receiving uC knows how many bytes to 'receive' over SPI.

If I add a 3rd uC, the UI uC could use a second SPI port to send commands to it as well.  

Is this a reasonable approach?  ( just need some direction on a good way to handle this )

Thank you!

[TDK]

Having multiple MCUs with multiple firmware is significantly more work than maintaining a single code base. You need to keep their code in sync and ensure both are updated. Yes, it can be done, but it adds a layer of complexity that far outweighs any benefit you get from splitting the logic.

Handling user input and sending UART/SPI commands is lightweight stuff, you can do it all on a single MCU. If things are time sensitive, you're going to be able to respond quicker with a single chip than collecting data, sending it to another MCU, interpreting it, then acting on it.

[RhSilicon]

The work that will be required to handle each MCU will be multiplied by the number of MCUs. Physical space occupation, more concern with connectors, data cables, PCB layout design, communication protocol between the MCUs etc. When a software update is performed on one MCU, it may be necessary to update the other MCUs, for example communication protocol update.

The fragility of the system can also be distributed, such as humidity in the air corroding the tracks and terminals of components, electromagnetic interference, etc. Think of an automotive system, that's basically it, each part of the vehicle has a module.

A lot of people use dedicated MCUs for the HMI, such as the Nextion display and the like, as long as the volume of data that the HMI will send or receive from the other modules is not high speed or high rate, it may be interesting to use several MCUs, but perhaps the cost is higher than concentrating processing on a smaller amount of MCU.

[LMorr.3]

You and TDK bring up great points.

So I'm assuming using SPI to communicate between 2 MCUs as I plan should be fast enough for HMI based data.  The fastest rate will be the user turning a knob quickly ( 12 bit ADC ).

The biggest benefits I can think of so far are the ability to divide the areas of 'concern' so coding and testing the HMI can be simplified and done separately.   If the uC can handle commands via SPI, it can be re-used or shared with others for different projects.  For example the same part could be used for different HMIs.  ( a small compact panel, and a larger full-featured panel )

I also will be running out of timers and pins with one uC, so I need to plan on how I'll handle that in the future.

If I only have 1 uC handling the HMI, than each additional uC does not need to implement/duplicate the HMI code. ( DRY )  The HMI uC could send commands to the other 2 uCs using 1 SPI for each.  Each uC would be a state machine and commands would change state.

It would be like encapsulating logic into an ASIC.

[LMorr.3]

Has anyone else used this design pattern before in a project?