One large microcontroller or several small ones?

[jgalak]

This is kind of a philosophical question, so I don't expect any sort of definitive answer. Rather, I'd like to know what factors people with more experience than I (which is almost everyone) think about in making this sort of decision.

When working on reasonably complex projects, when is it best to use a single, larger, microcontroller and when is it best to use several smaller ones? 

For example, lets say you have a system with multiple external peripherals that each need to be controlled by a uC.  Is one better off with a single larger uC that has sufficient IO and sufficient speed to manage them all at once, or would one be better off with several small uCs, one for each peripheral, and a central, slightly larger uC, to direct them all?

[KrudyZ]

If the interactions between the sub-systems are well delineated then using multiple uC (perferably of the same type) will usually make for a more robust system and will be faster to develop.
What matters is that the interaction can be reduced to lower bandwidth protocols that reduce the real time requirements of the master controller.

[filssavi]

I'd say it depends on how the larger system is phisically and logically configured, for example

If the system is highly coupled (for example an oscilloscope)  you would have to be really really highly masochistic to use such a system since controlling and synchronizing all the different processors is a task and a half

On the other end if the problem has naturally defined boundaries (for example controlling a large led wall made up of multiple sections) using a distributed network (be it master-slave or p2p) of smaller compute units

also if there is a large physical distance between two boards (for example multiple boards along a large industrial oven) using some sort digital bus to connect them all of them with just 2 or 3 cables is a good idea and this requires multiple processors

[NorthGuy]

I always lean towards one big one. Usually, it would have peripheral modules which would do the job of many small MCUs, but since they're peripherals, they are much easier to control.

However, if many small ones cost less than one big one, I would go the other way.

[nctnico]

If the interactions between the sub-systems are well delineated then using multiple uC (perferably of the same type) will usually make for a more robust system and will be faster to develop.
What matters is that the interaction can be reduced to lower bandwidth protocols that reduce the real time requirements of the master controller.

NO!
It is exactly the opposite of what you describe. Using multiple controllers is much harder because suddenly you are dealing with several asynchronous processes. Also the communication between the controllers WILL FAIL so you need to add error recovery as well. I have been down this road a couple of times and it is MUCH harder to get right then it seems at first sight. The simplest and most robust way is to have everything in one program.

It reminds a bit of the cycle many programmers go through. First they start with single threaded programs, then they discover threads and start to make a real big mess of things with hard to discover bug like mutex deadlocks and finally they go back to do as much in a single threads as possible and only use multiple threads if they really have to.

[ogden]

It is exactly the opposite of what you describe. Using multiple controllers is much harder because suddenly you are dealing with several asynchronous processes.

Exactly. You are dealing not only with that. There are problems of firmware initial programming during manufacturing, firmware update, version compatibility tracking for all those controllers, as well.

If design allows single microcontroller, resources of single microcontroller are enough then it's no brainer to use just single microcontroller.

[donotdespisethesnake]

+1

If you have a complex project, adding more CPUs makes it more complex, never simpler. The only time to consider multiple CPUs is when you have maxed out the CPU package, you have physical separation or need electrical isolation.

The complexity required for reliable comms is often underestimated and can be a nightmare to debug if done poorly. There can be a significant overhead of comms processing, unless you have a very strong logical separation between functions.

I think in nearly the projects I have worked on where multiple CPUs were used, the lesson was always "next time we design this with a single CPU..."

[Kalvin]

Synchronous, time-triggered design will solve most problems of the asynchronous design.

[mikeselectricstuff]

One big one is always the first approach. With multiple MCUs, debugging is usually a lot harder, and you have the hassle of dealing with multiple firmware images and making sure everything has the correct versions.

There are some niche situations where it can make sense to use multiple processors, e.g. smart sensors/peripherals, and for where you have a small MCU doing power management to turn on a big lumbering Linux processor. 

[Tomorokoshi]

I've seen both and done both.

Mr. Ganssle has talked about this on occasion:
http://www.ganssle.com/

All the benefits and hazards pointed out above apply. There are a few things that can help guide the choice:

1. Is there a process that is highly timing dependent, processes a lot of interrupts, run in "real-time", etc.? This may benefit from being it's own separate processor.

2. Is there a process that channels a lot of data, such as video or audio that is likely to cause system-wide issues if it's caught up in some waiting process? This may benefit from being it's own separate processor.

3. Are there boards connected by long cabling that have to do complex tasks but are relatively low bandwidth? A remote processor can turn a lot of parallel lines / inputs / outputs into a serial channel.

4. Are there boards connected to very different environments? For instance, one connects to a computer using USB while the other controls motors on 240 VAC. The necessity of optical isolation makes it attractive to use a separate processor.

Just like using multiple tasks on one processor, it's a matter of using the right set of tools for the job.

Figure that bootloading and updating complexity might go on the order of n². However, that is somewhat mitigated by moving tasks to remote processors. So instead of 20 tasks on the main one, perhaps it's down to 10 with other tasks distributed across the others.

Depending on the organization you may be able to more readily split it up between engineers.

Depending on the product line it may also make sense. For instance, perhaps the base model needs only a minimum amount of I/O, while a more expanded model really only needs the same overall processing power but has extra modules to support the new options. This allows a solution with a common main processor board with peripherals that get added.

[Kalvin]

There are also some exotic processor architectures that contain multiple parallel execution units and which are specifically designed for multitasking. For example XMOS and Epiphany come to my mind. You can also create multiple instances of simple CPUs or state-machines into a single FPGA.

[MT]

A simple example:
For a design we did some time ago we replaced (i bossed my stubbornnessed contracting boss) loads of 4051 muxes for the cheapest with most ADC channeled STM32 , not only did we replace the cumbersome (code as well as PCB routing) 4051 multi channel level detecting problem into per single ADC channel/pin level detecting problem instead, so per 10 ADC ch's there is a dirt cheap MCU (a total of 12 MCU's) who does ADC atodetect, averaging, scaling instead of 2 4051 per field times 12 who does nothing. The master MCU talks to each slave MCU by 9 bit auto-address , master MCU just pings in a steady phase for new values or channel activity reports. A weekend Code+PCB replaced ca:1,5months of code+pcb of our contracting boss unfinished struggle. Edit: I forgot to say the MCU also replaces a 4094/HC595 per field so multiple MCU's is well justified fro this particular problem. 

The point are it depends on your/their design goals and how much time/money they/you want to spend as usually and what your management/contractor/etc dictates. This particular problem was solved with many MCU's way cheaper then one big MCU and complex solution.

[KrudyZ]

I've seen both and done both.

Mr. Ganssle has talked about this on occasion:
http://www.ganssle.com/

All the benefits and hazards pointed out above apply. There are a few things that can help guide the choice:

1. Is there a process that is highly timing dependent, processes a lot of interrupts, run in "real-time", etc.? This may benefit from being it's own separate processor.

2. Is there a process that channels a lot of data, such as video or audio that is likely to cause system-wide issues if it's caught up in some waiting process? This may benefit from being it's own separate processor.

3. Are there boards connected by long cabling that have to do complex tasks but are relatively low bandwidth? A remote processor can turn a lot of parallel lines / inputs / outputs into a serial channel.

4. Are there boards connected to very different environments? For instance, one connects to a computer using USB while the other controls motors on 240 VAC. The necessity of optical isolation makes it attractive to use a separate processor.

Just like using multiple tasks on one processor, it's a matter of using the right set of tools for the job.

Figure that bootloading and updating complexity might go on the order of n². However, that is somewhat mitigated by moving tasks to remote processors. So instead of 20 tasks on the main one, perhaps it's down to 10 with other tasks distributed across the others.

Depending on the organization you may be able to more readily split it up between engineers.

Depending on the product line it may also make sense. For instance, perhaps the base model needs only a minimum amount of I/O, while a more expanded model really only needs the same overall processing power but has extra modules to support the new options. This allows a solution with a common main processor board with peripherals that get added.

Jack Ganssle also on multiple occasions mentions how much faster it is to develop smaller systems and that putting everything into one processor is a recipe to have your project come in late with more bugs.
Separating out tasks allows for easy re-use of modules.
Modern cars have hundreds of microprocessors, not because they run out of processing power, but because it is much better to build them that way.
They use CAN and LIN to talk between the modules, which can be independently verified and re-used on the next model.
Hardware is cheap, developers are not.

[mikeselectricstuff]

If you do use multiple MCUs, you'd better have good tools to show the comms in real time, like serial decode on a scope.

[nctnico]

Jack Ganssle also on multiple occasions mentions how much faster it is to develop smaller systems and that putting everything into one processor is a recipe to have your project come in late with more bugs.
Separating out tasks allows for easy re-use of modules.

You can do the same in one controller. Just run (mostly) independant parallel tasks with clear APIs between them. I've worked on huge microcontroller projects together with others which where using a simple round-robin scheduler. Everyone had a particular area of expertise and we just put the right modules together to make a product work.

[ogden]

Jack Ganssle also on multiple occasions mentions how much faster it is to develop smaller systems and that putting everything into one processor is a recipe to have your project come in late with more bugs.
Separating out tasks allows for easy re-use of modules.

"Software module" shall be assumed as smaller system as well, not necessarily independent microcontroller.

Modern cars have hundreds of microprocessors, not because they run out of processing power, but because it is much better to build them that way.

Why don't you just pick factory automation as an example? Factory also have hundreds, most likely thousands of microprocessors.

We shall be careful here with definitions of "device".

Hardware is cheap, developers are not.

Exactly. You shall not forget that "coding" is only part of whole development. There's electronic engineering, software system analysis and not only. Multi-cpu system shall have components developed which single-cpu system does not even need. It's additional expense! Indeed it is much easier and cheaper to develop single cpu system with 10 developers than 10 cpu system using same 10 developers. As I said - software module shall be considered "smaller system" as well.

Proper segmentation of project into "development/work modules" does not necessarily mean multiplying CPU count 

[MT]

For security and safety reasons many system solutions requires multi MCU's.

[ogden]

For security and safety reasons many system solutions requires multi MCU's.

Indeed we can find zillion various systems which really needs more than single MCU. Distributed systems which occupy more than single PCB also most likely requires multi MCU's. So reason to have multiple MCU's are system requirements, not some generalized/stupid rules of splitting system into multiplies, like "each developer or function of device needs own MCU"

[tszaboo]

It depends. There is no one size fits all answer for this. Typically, if you can solve it with one big MCU, then that is the good choice to do, but if it makes bottlenecks, or if the physical layout makes it different, then you need to divide it down. I worked on a system, where one unit was 1 FPGA, 1 big MCU and 5 small (equally programmed)  MCUs, and for that system, this was the logical choice.
The asynchronous reason is a bad one, because once your tasks are complicated enough, you need an RTOS and there you need to handle the exact same problems, as with two MCUs. Communication between tasks and MCUs is very very similar. The more difficult part is usually bootloader and similar niche problems. Remember, on an embedded system, 80% of the code will be for the exceptions (and such niche cases), not for the main task.

[MT]

For security and safety reasons many system solutions requires multi MCU's.

Indeed we can find zillion various systems which really needs more than single MCU. Distributed systems which occupy more than single PCB also most likely requires multi MCU's. So reason to have multiple MCU's are system requirements, not some general/stupid rules of splitting system into multiplies, like "each developer or function of device needs own MCU"

I concur to my self and your statement,who would be stupid enough to design the Internet depending on one fat CPU?

[ogden]

It depends. There is no one size fits all answer for this. Typically, if you can solve it with one big MCU, then that is the good choice to do, but if it makes bottlenecks, or if the physical layout makes it different, then you need to divide it down.

Very well said. Cannot agree more   

In my opinion initial question is well answered now, we can wrap it up.

[SL4P]

The most relevant application of co-processors that i’ve seen (apart from dedicated math accelerators etc), are to implement ‘proven’ subsystems e.g. front panel controller, motor drivers, communications as separate devices - if the project justifies it.

[thm_w]

A simple example:
For a design we did some time ago we replaced (i bossed my stubbornnessed contracting boss) loads of 4051 muxes for the cheapest with most ADC channeled STM32 , not only did we replace the cumbersome (code as well as PCB routing) 4051 multi channel level detecting problem into per single ADC channel/pin level detecting problem instead, so per 10 ADC ch's there is a dirt cheap MCU (a total of 12 MCU's) who does ADC atodetect, averaging, scaling instead of 2 4051 per field times 12 who does nothing. The master MCU talks to each slave MCU by 9 bit auto-address , master MCU just pings in a steady phase for new values or channel activity reports. A weekend Code+PCB replaced ca:1,5months of code+pcb of our contracting boss unfinished struggle.

The point are it depends on your/their design goals and how much time/money they/you want to spend as usually and what your management/contractor/etc dictates. This particular problem was solved with many MCU's way cheaper then one big MCU and complex solution.

I would have thought a 10ch+ i2c ADC would make more sense but looking at the prices they are more than a STM32.
The cheapest stm32 STM32F030F4P6 with 11 channels $1.85 CAD.
The cheapest ADC is at least $2-3.

[nctnico]

I would have thought a 10ch+ i2c ADC would make more sense but looking at the prices they are more than a STM32.
The cheapest stm32 STM32F030F4P6 with 11 channels $1.85 CAD.
The cheapest ADC is at least $2-3.

Without comparing specs this comparison is meaningless if it is just based on price. There are many 'cheap' ADCs with several LSBs of error and I have no idea how good/bad the STM32's ADC is. A good ADC with less bits may be cheaper and get similar resolution with some oversampling.

[thm_w]

Without comparing specs this comparison is meaningless if it is just based on price. There are many 'cheap' ADCs with several LSBs of error and I have no idea how good/bad the STM32's ADC is. A good ADC with less bits may be cheaper and get similar resolution with some oversampling.

Yes I am aware the stm32 is less capable. For 8-bit ADCs, I could not find a cheap 10 channel one for less than $3 (on digikey at least).