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:
-
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
-
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.
Best Answer
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:
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.
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.
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.
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.