One large microcontroller, or lots of small microcontrollers?

I'm used to doing basic and straightforward things with microcontrollers, relatively speaking. Things such as driving LEDs, running motors, basic routines, GUIs on character LCDs, and so on, but always just one key task with at most a few little side tasks. This has relegated me to low end products since that's really all that's needed in those cases.

I'd like to start designing more complex things but the upper side of the microcontroller continuum is not something I've been well exposed to. Thus, I've been having a very challenging time trying to pick a microcontroller where I will do lots of tasks simultaneously — I can't tell just by a MIPS number and a satisfactory pinout if it has enough horsepower to do what I want it to do.

For example, I would like to control 2 BLDC motors with PI routines, alongside some serial and USB comms, a GUI, and a slew of other tasks. I'm tempted to just have a microcontroller for each motor and then one for the miscellaneous tasks so I can guarantee that the overhead from the miscellaneous stuff won't gum up critical motor functioning. But I don't know if that's actually a good idea or a naive way to go about things.

I guess my question is really two-fold:

1. Is the all-in-one approach a good idea when having to do a lot of multitasking, or is it better to segment and isolate, and

2. How can I intuitively find out if the microcontroller I'm looking at has enough compute power to do what I need based on my list of tasks?

I'm looking at moderate dsPIC33s all the way up to ARM SoCs that run RTOS. A systematic way to hone down what I need would help me out a lot.

• xmos.com – Ignacio Vazquez-Abrams Apr 24 '14 at 21:50
• nxp.com/documents/data_sheet/LPC4370.pdf – markt Apr 24 '14 at 23:07
• Too many answers already, but sometimes getting many programmable micros on the same board all speaking the same language is way more work than just using a single micro, perhaps with some intelligent peripherals. – Erik Friesen Apr 25 '14 at 17:01

The answers to your questions are different depending on what your end goal is. If you need a handful or less of these devices, you should make development easier, and not worry about parts cost. If you're going to make a thousand or more of these, it's worth analyzing your requirements and reducing cost of the device hardware.

Small quantities

If you are doing a one-off or small run of these devices, then your development efforts are going to swamp your per-item costs, and you should focus on what will be easiest/fastest for your to develop, rather than the cost/size of the microelectronic.

In general encapsulation can decrease complexity, increasing your productivity. If you have some hard real-time requirements, such as your BLDC control, PID loops, etc then you may find it faster to use separate controllers specifically for those tasks that communicate with controllers where you keep the user interface and other non-real-time tasks.

So in this case, the answer to your questions are:

Is the all-in-one approach a good idea when having to do a lot of multitasking, or is it better to segment and isolate, and

The scale tips slightly towards segmentation and isolation. The major reason is that debugging a real-time system can be very time consuming, and keeping such tasks on their own processor limits the variables you have to measure or control when trying to find why something isn't working right.

How can I intuitively find out if the microcontroller I'm looking at has enough compute power to do what I need based on my list of tasks?

In this case the cost difference between a 32 bit processor with a lot of resources and an 8 bit processor with limited resources is small relative to the amount of time you're going to spend working on development. There's little reason to try and figure out how much power you need - just get the biggest processor you feel you can develop for and use that. If at some later point you need to cost optimize the design, it's relatively easy to measure actual processor resource usage, then choose a lessor processor that can handle the actual load. Until then, use the biggest one and don't worry about finding the "best fit".

Mass production

If you plan to make many of these devices, then careful analysis will yield significant cost savings. Generally speaking a larger microcontroller will cost less than two microcontrollers capable of replacing the single microcontroller, though there are certainly exceptions depending on the specific tasks required. At these quantities, the cost of the hardware will likely be much larger than the cost of development, so you should expect to spend more time analyzing your requirements and performing development than you would if you were only making a few.

Is the all-in-one approach a good idea when having to do a lot of multitasking, or is it better to segment and isolate?

The all-in-one approach will generally be less expensive over the life of the entire project than multiple processors. It will require more development and debugging time to make sure the various tasks don't conflict, but rigorous software design will limit that nearly as much as having separate hardware would.

How can I intuitively find out if the microcontroller I'm looking at has enough compute power to do what I need based on my list of tasks?

You will need to understand the tasks you want to perform and how many resources they take. Suppose the following were true:

Your BLDC PI routines will consume X cycles of processor time 100 times a second, and each need about 50 bytes of RAM for operation, 16 bytes of EEPROM for tuning, and 1k flash for the code. They'll each need 3 sixteen bit PWM peripherals in the microcontroller. You may need to specify jitter, which will have specific interrupt latency requirements.

Your USB and serial routines will consume Y cycles of processor time on an as-needed basis, 2k RAM, 64 bytes EEPROM, and 8k flash. It'll require USB and serial peripherals.

Your GUI will consume Z cycles of processor power 30 times a second, and will need 2k of RAM, 128 bytes of EEPROM, and 10k flash. It'll use 19 I/O for communications with the LCD, buttons, knobs, etc.

When you're first starting, it might be hard to understand what X, Y, Z actually are, and this will change a little bit depending on the architecture of the processor. However you should be able to understand, within a ballpark estimate, how much ram, eeprom, and flash your design is going to need, and what peripherals you need. You can choose a processor family that meets your memory and peripheral requirements and has a wide range of performance options within that family. At that point, for development, you can simply use the most powerful processor in the family. Once you've implemented your design, you can easily move down the family in terms of power to a lower cost option without changing your design or development environment.

After you've done enough of these designs, you'll be able to estimate X, Y, and Z better. You'll know that the BLDC PI routines, though run often, are quite small and require very few cycles. The USB and serial routines require a lot of cycle, but occur infrequently. The user interface requires a few cycles frequently to find changes, but will require a lot of cycles infrequently to update a display, for instance.

I would separate out the motor control, and have a separate microcontroller which includes PWM (perhaps a PIC18) for each of the two BLDC motors, since the PI control is an isolated task once it is started up, and once you write the code you can use it on both micros. You can connect them back to the main microcontroller via interface like I²C, and download the parameters for the PI control from there if you wish. That would allow you to modify them in your GUI.

I would then run everything else in the main microcontroller, such as a PIC24 (a PIC32 is probably overkill, based on the tasks you listed). Plus the fastest PIC24E's can run almost as fast as a PIC32.

When choosing a microcontroller, I first estimate the amount of flash and RAM that I need, and then look at the word length and processor speed. For the later, often the hardest requirement to meet is the fastest interrupt you expect to handle. If you are outputting 16 KHz sound, for example, and have a interrupt every 62.5 µs, then you better have a microcontroller with an instruction time down in the tens of nanoseconds, or you won't be able to service it and get any other work done.

There is a semi formal approach you can use to help you generate your answer. I highly recommend reading chapter 2 of White's "Designing Embedded Systems", most of which is available at Google Books.

This chapter talks about designing system architectures, and offers a semi formal approach to how you can best encapsulate tasks. While the chapter is largely about one controller systems, it easily extends to multiple controllers. It will help you envision which resources need to be shared, and help you pick your level of encapsulation for each task.

She offers a variety of views to consider, one of which I show below, but there are many useful manipulations. This, of course, doesn't make much sense on its own, but I hope it encourages you to check out the chapter.

As to "how do I know if I have enough controller", my own preference is to put as much power into my designing sandbox as I can, and then figure out how many resources I can cut down on once the design is well on its way. The difference in price between a $10 microcontroller and a$3 microcontroller for prototyping purposes might just be weeks of retooling and twiddling your thumbs waiting for new parts, while the design can always keep moving if you have enough power.

I work on a system that is broadly what you're describing - motors, IO, display, 3x UARTs + SPI + I2C running on a Coldfire 52259 (mid-range 32-bit ~80MHz micro) and it's not too difficult, although getting the software architecture right is important - we have a lot of stuff running on hardware & interrupts (anything that the hardware can handle on its own, we run in hardware & service with interrupts) leaving the main() loop to do all the housekeeping.

Personally I dislike most RTOS I've seen, at the low end they bloat a project, add another thing to learn, and you're going to get better performance from the hardware by doing things directly (using the available hardware functions + interrupts) rather than faking it with software.

At the high end, these days there seems to be so little margin between an MCU that's complex & powerful enough to really benefit from an RTOS and something (SoC) that just runs embedded Linux.

However, in that instance I would say there's some value in using small cheap micros to handle critical functions (EG motor control where timing or stopping at a limit is critical) under the command of the main "brain" CPU so you're not relying on a "non-realtime" OS to do something in a timely manner.

Everyone elses answer is better but I have a bit to add that may be useful. This may be a bit off the mark and I would love to add it as a comment but there is a 50 rep rule:(

Short answer is it depends, see above but why not think about processor benefits too.

Why not think about the benefits of smaller processors. This is, after all a question about processors. For mathematical and certain non-iterative tasks, multiple processors can produce a logarithmic boost. Amdahl's rule states that a boost can be achieved of $\frac{1}{((1-p)+\frac{p}{s})}$ but this comes . P is the percentage of the computation that can be split and s is the speedup (depends on number of operations, hardware; etc.).

Of course, cost, ease of implementation; etc. are important and even more important to consider as well.

The answer can depend on implementation details. Some tasks as easier to implement in a clean and robust way on separate microcontrollers. Power consumption may also be a consideration - generally speaking a single micro handling several tasks will require less power than several micros handling single tasks.

"Horsepower" is secondary to whether you can fulfill your realtime constraints.

If you have two PWM outputs, and both need to switch at the exact same time, then you need to have the necessary parallelism in place to be able to do that. If you have a dedicated PWM controller which takes care of the exact timing, that will work, even with a rather small microcontroller, while a GPIO based solution will be massively complex even if lots of computing power is available.

For most protocols, modern MCUs have embedded implementations of those parts of the protocol that have realtime constraints, so if you can find a MCU that has the required peripherals and has the required CPU speed to handle the data flows (i.e. the hard realtime requirement degenerates into a soft realtime requirement of the form "will be able to read from the FIFO before it is full, and faster than it fills up"), that would be the optimal choice.

If no such solution exists, your options are either moving functions out into separate controllers, using a CPU+FPGA solution (e.g. FPGA with hard ARM core), or a pure FPGA solution (optionally with a soft CPU, depending on complexity requirements).