-
Take a look at the auto industry! There are dozens of distributed uCs in the modern automobile. I have been told it approaches 100:
https://www.embedded.com/electronics-blogs/significant-bits/4024611/Motoring-with-microprocessors
It certainly wouldn't be feasible to do all this computing in a single CPU not to mention the extra cabling costs. The auto industry doesn't use uCs because they like them, there is simply no other way to meet modern expectations.
So, the answer is "it depends". How complex is the overall system and what is the tradeoff in developing a network versus centralization. BTW, the CAN bus already exists and many uCs can use it.
-
Take a look at the auto industry! There are dozens of distributed uCs in the modern automobile. I have been told it approaches 100:
Actually a car is a poor example because the interface between the components is fixed by a (limited) CAN bus which forces people to think about how the split a system in pieces. And even then the systems in a car still need to be able to deal with transmission errors and loss of communication.
So, the answer is "it depends". How complex is the overall system and what is the tradeoff in developing a network versus centralization. BTW, the CAN bus already exists and many uCs can use it.
Nobody is saying you can't split a system across multiple microcontrollers but the fact is that if you do that you open a very large can of worms. -
Take a look at the auto industry! There are dozens of distributed uCs in the modern automobile. I have been told it approaches 100:
It's just me who feels like it's groundhog day again and again?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.
-
I don't know how I missed that earlier post.
In my view, there are car functions like fuel injector timing that have hard real-time requirements. It doesn't
make much sense to bother such a processor with controlling the seat heating or the rear window wipers.
OTOH, it is possible to pilot an autonomous vehicle across the desert for the DARPA Challenge using just an LPC2148 and some excellent coding.
http://www.bdmicro.com/darpa-gc/
The LPC2148 is a simple 60 MHz ARM with 512k of flash and 40k of RAM.
But they didn't have rear window wipers...
I would almost always go for the distributed approach as it allows for separate design/test schedules. All that is necessary is a network framework and an agreed command/response structure. It's going to depend on scale.
http://www.bdmicro.com/code/robin/
-
I think the cars have distributed systems mostly because each MCU is designed and programmed by a separate team. Trying to do it through a central MCU would be a complete disaster mostly from the organizational point of view.
-
consider also the fact that there are many CAN and LIN busses and some of them are completely isolated from others. In the previous example the engine ECU and the window wipers ECU are two separate one because they are on different networks. one don't have a clue of what the other is doing, they could be on different veichles for what they know
-
If it fits one uC, use one uC.
It's cheaper mostly, faster to build and develop, less maintenance and setup.
Do not compare with auto industry, it's a distributed finished product made of modules with strict specifications and a myriad of contractors (each design has two source at least). -
Depends - I always try to default to "one controller" in most projects.
However, you don't need to be afraid of using multiple, if it makes the project possible, or simplifies it. Sometimes distribution simplifies things. And sometimes you just have to.
Available resources do matter. For example, right now, I've been working for a year on a project with one master and multiple slave microcontrollers. It was extremely quick to setup, with little issues. This is because I chose to simply use SPI, always have fixed communication size (basically, "commands" and "responses" memory buffers are just updated between master and slave), and use continuously running DMA. Using 16-bit SPI word length, 16-bit DMA length, and data packets where each 16-bit word can be thought as a "separate thing" (i.e., it doesn't matter if word3 has updated, but word4 hasn't yet, they don't need to be from exactly at the same time), this, basically, transparently makes both processors see each other's memory so I can access those things as easily as I'd do in a single CPU. DMA runs by itself and keeps everything in sync. So I can just instruct:
motor_controllers_tx[0].speed = 1234; motor_controllers_tx[0].cur_limit = 10000 /*ma*/;
and read back: position = motor_controllers_rx[0].position or motor_controllers_rx[0].current;
Still, reflashing through the said SPI link did cause some extra work, especially since I still have some bug in my slave processor SPI bootloader code, necessitating manual flashing (using a cable) every now and then when "update all firmwares automatically from the application" gets stuck
.
But this kind of simple design is not always possible. If you need to think about framing the data, atomic operations, timestamping, latency, jitter, etc., it can get harder. And for the next rev, I'm upgrading to a MCU directly capable of taking over the slave MCU tasks. More visibility, possibility for bigger software changes without needing to respecify interfaces all the time, and needing fewer physical components tend to make development easier and quicker.
-
I have seen designs where there was one main MCU (or DSP) and one processor (of some kind) for the UI (display and buttons).
This makes sense to me, since you can talk between each other on a high level protocol and it take some heavy burden of generating graphics on screen out of the equation. Also the requirement for both cases are (usually) totally different - you can select devices that are specialized for the job.
Other than that, I tent to lean to keep it simple unless the problem really requires it - sometimes the problems you have to solve are NOT simple. (don't oversimplify)
[2c] -
This is because I chose to simply use SPI, always have fixed communication size (basically, "commands" and "responses" memory buffers are just updated between master and slave), and use continuously running DMA. Using 16-bit SPI word length, 16-bit DMA length, and data packets where each 16-bit word can be thought as a "separate thing" (i.e., it doesn't matter if word3 has updated, but word4 hasn't yet, they don't need to be from exactly at the same time), this, basically, transparently makes both processors see each other's memory so I can access those things as easily as I'd do in a single CPU. DMA runs by itself and keeps everything in sync. So I can just instruct:
If you don't have error checking in that system it is going to bite you in the ass. Data integrity checking is very important when communicating.
motor_controllers_tx[0].speed = 1234; motor_controllers_tx[0].cur_limit = 10000 /*ma*/;
and read back: position = motor_controllers_rx[0].position or motor_controllers_rx[0].current; -
I think it much depends how well you can map tasks onto which processors, and what influence it will have on the communications between tasks, as you could analyze intensively/excessively with a design space exploration.
IPC inside a MCU is much simpler to set up, synchronous, high and predictable data flows, easier to change than a communication protocol, and above all 1 MCU hardware solution is often more cost effective. This makes it the go-to solution for most projects.
But mapping real-time tasks onto a 1 processor can be challenging. Modeling all tasks as separate processors in e.g. a SDF dataflow model is rather trivial, but not so much anymore when having multiple tasks, that depend on the scheduler of a RTOS, resources sharing, priority inversion, etc. At this point it may be more reliable, predictable and cost effective to map tasks onto separate MCU's and limit the communication between systems. I think automotive is a classic example of applying this solution, but perhaps also space industry and maybe even medical applications.
In engineering you don't get anything for free though. If you're debugging such multi processor systems, it could be quite hard to get the state of all processors at any moment in time, e.g. if you hit a breakpoint in 1 MCU.
If you want that, then simulation and modeling again can help out, .. but then I certainly hope you're not doing this project on your own.
I don't really think the intention of a CAN bus (or any in fact..) is to have some kind of "LEGO for electronics" if all devices stuck to the same protocol. Although some buses come quite close, you often see that each manufacturer will have their own proprietary settings and protocols in order to setup devices, making it not so 'LEGO' after all.
But this was already discussed; it depends on the project.
In practice; 1 MCU will be most cost effective, going to multi MCU's only when you have good reason to do so, like physical wiring (thinking of some Mikeselectricstuff LED installations that used 1 PIC processor per RGB LED...), (hard) real-time tasks mapping, or perhaps modularity (although I think this is often an utopia, unless you have many hours to burn) -
Depends on the communication medium,the ability to do anything sensible about the error and any consequences. If you are getting errors on a hardwired system, you need to fix the hardware.This is because I chose to simply use SPI, always have fixed communication size (basically, "commands" and "responses" memory buffers are just updated between master and slave), and use continuously running DMA. Using 16-bit SPI word length, 16-bit DMA length, and data packets where each 16-bit word can be thought as a "separate thing" (i.e., it doesn't matter if word3 has updated, but word4 hasn't yet, they don't need to be from exactly at the same time), this, basically, transparently makes both processors see each other's memory so I can access those things as easily as I'd do in a single CPU. DMA runs by itself and keeps everything in sync. So I can just instruct:
If you don't have error checking in that system it is going to bite you in the ass. Data integrity checking is very important when communicating.
motor_controllers_tx[0].speed = 1234; motor_controllers_tx[0].cur_limit = 10000 /*ma*/;
and read back: position = motor_controllers_rx[0].position or motor_controllers_rx[0].current;
Error checking = more code = more work and a larger potential bug surface. In the case of MCUs in the same box talking to each other, if you're getting comms errors you have bigger problems.
In some cases error checking (withoit logging or good diagnostics) can disguise underlying hardware issues, making debugging harder.
For example with a DMX lighting installation, an open or shorted line of the differential pair can cause flickering issues that can often be diagnosed & tracked down by looking at the pattern of the errors. if it had, say, a checksum that made it just not work, it would be a lot harder to diagnose issues.
As with many design decisions, there is no right or wrong way, just more or less appropriate for a given situation.
-
If you don't have error checking in that system it is going to bite you in the ass. Data integrity checking is very important when communicating.
Again, it depends. STM32 SPI has an integrated CRC8/CRC16 generation and checking which works through DMA as well, and will give interrupt on detected corruption. So in this case, this is made quite easy. So yes, I'd recommend having error checking in communication whenever possible, too.
This being said, I'm not a big fan of such blanket statements.
Everything is communication. And 99.999% of your communication does not have any kind of integrity checks.
Do you have integrity check in your CPUs memory bus? Or ALU?
Do you have integrity check for memory? And yes, this is actually very relevant. Memory corruption is widely studied and a well known phenomenon. Still, we often just choose to accept the results, and not invest in error correcting RAM.
I have thousands of traces on my PCB. Some analog, some digital GPIO, some SPI, some I2C... All carry "communication", and all are important. Do I add some kind of "integrity checking" to each of them? Is this realistic?
By adding gazillions of checks everywhere, you can drop the unprotected area of 99.999% to maybe 99.99%. When done right, you concentrate on the biggest contributors of errors.
Or, you can pretend your own CPU-to-CPU SPI link is the only magical place where electrical errors could happen.
I don't have any integrity check when reading many types of sensors, some SPI, some I2C, some parallel bus, simply because none of the sensors implement any kind of error checking functionality - even though it's "communication", and even though the integrity is "important", and even though they are fairly well designed products from the big, trusted manufacturers. Why don't they implement error checking possibility?
I guess the usage pattern seems to be that data corruption in the physical link level is so rare that many other sources of errors dominate anyway, by orders of magnitude.
Should my own SPI link, then, have a checksum? Yes, it's probably a good additional safety measure. This being said, a realistic case of one bit corrupting once per 10 years of operation is automatically fixed by the next transaction. This, of course, only works because the design is tolerant for having wrong values that exist for short time, so this doesn't work without thinking.
Adding a checksum to the SPI link would only protect from electrical corruption on said line - even then it would require extra code to handle retransmissions, etc. How well do you test this code? Given that corruption in SPI link is extremely rare and unlikely, you'll never see that part of code executing in real life. And if you depend on having the right data at the right time, always, adding the checksum and error correction logic is starting to get nontrivial.
Which gets us to sanity checking inputs, and designing things to be robust even with wrong data, whenever possible. It's most important to focus here - much more likely than having a SPI corrupted bit, is that I have just made a stupid mistake somewhere, supplying wrong parameters, overindexing something, etc. Error checking one of the most reliable pieces of hardware I have on board is not going to help on that.
Then, at the end, we need to admit that no system is perfect, and try to focus on actual "worst offenders" first. Understanding that a short SPI link between a few MCUs on a PCB, correctly electrically designed, is practically error-free (comparable to all those signals inside MCU's, also considered error-free by everyone without a second thought!), enables us to concentrate on the actual challenges, which do not get any easier when we have a multi-MCU design.
The issue with perfectionism is that it typically overlooks many super important areas while focusing on almost unnecessary.
TLDR: It depends. -
It is not a blanket statement but a good rule to follow. External signals travelling over some distance are way more prone to getting corrupted than signals inside a chip.If you don't have error checking in that system it is going to bite you in the ass. Data integrity checking is very important when communicating.
Again, it depends. STM32 SPI has an integrated CRC8/CRC16 generation and checking which works through DMA as well, and will give interrupt on detected corruption. So in this case, this is made quite easy. So yes, I'd recommend having error checking in communication whenever possible, too.
This being said, I'm not a big fan of such blanket statements.QuoteDo you have integrity check for memory? And yes, this is actually very relevant. Memory corruption is widely studied and a well known phenomenon. Still, we often just choose to accept the results, and not invest in error correcting RAM.
In my software I add checks for valid value ranges in many places. First and foremost to avoid a bug from spreading throughout the system causing odd behaviour which is hard to diagnose. But it also helps to deal with data corruption from other sources. But this is getting off-topic. -
Interesting question and discussion.
In the end, it all depends on the size, complexity and requirements of your project.
Several microcontrollers means different pieces of software to maintain, the added complexity of inter-uC communication, and more parts on your board, thus potentially more sources of failure.
But this is all a compromise. In case of a complex system, it may actually be simpler to maintain different software modules on separate targets even with the added complexity of communication, rather than one big piece of software on one target. It will naturally enforce a more modular design with clearly defined interfaces, that may be harder to get right if you write for just one processor.
On the other hand, the communication between the MCUs will add sources of potential failure, hardware and/or software. Also, it may be easier for third-parties to tamper with your system. That may be a problem for critical devices.
Then again, for safety-critical systems, isolation between different parts of the system may be an essential requirement, and usually the simplest/most relevant way of ensuring this isolation is to run those parts on separate processors. Very robust and validated OSs are also an option, but usually harder to prove anyway, and very expensive. You can take a look at relevant standards (safety-critical systems, medical, automotive... such as IEC61508, IEC62304, DO178C, etc.) to understand the point.
Also, this separation can improve the overall "quality of service" of your system if done right. Instead of a single point of failure, you can mitigate the effect of failures by distributing different tasks on different parts of your design. For this to be relevant, you should usually avoid the simple master-slaves architecture, because if the master fails, everything else will also fail. Unless a failure of the master doesn't compromise the functioning of the slaves (which may then each implement a safe mode, not-master-dependant, to ensure continuous operation, at least for critical tasks).
Of course, for simpler systems, this will just be overkill.
Anyway, those are some points to think about when making architectural choices.
-
Or possibly an advantage in the third parties may be able to interface to or enhance it.
On the other hand, the communication between the MCUs will add sources of potential failure, hardware and/or software. Also, it may be easier for third-parties to tamper with your system. That may be a problem for critical devices.
Or that you (or a subcontractor) can redesign part of a system years down the line without touching the rest of it.
-
Big-ish distances are a good reason to use multiple interconnected uCs. For example in cars. But tight real-time expected response times are a good reason to use a single uC. E.g. the PCM/ECU in a car is usually a single module.
-
Also a single core uC can only do one thing at a time, so if the job can't be dealt with easily by time slicing and/or interrupts you'll be better served by a few truly parallel tasks running on multiple uCs.
You can consider the slave uCs as custom peripherals of the master uC. It's like the difference between bit-banging a GPIO to do serial comms (which is cpu intensive) and having a uart (and very little cpu load). -
Nobody seems to have mentioned cost here and in most commercial designs that is high on the list of priorities! IMOP and experience generally you get more bang for your buck in single processor solutions, it is generally possible to use a higher performance device as an aid to future-proofing and absorbing performance degredation during the debug cycle. Of course this is not to say a single processor is always the best solution but there should be some very good reasons for using multiples, it can be for example that whilst a single processor cannot manage the task, it could with some acceleration provided by for example an FPGA. Networked systems often suffer limitations due to the communications chosen many years before, this can also happen between software modules or god-forbid shared file formats
-
Nobody seems to have mentioned cost here and in most commercial designs that is high on the list of priorities!
Costs are not only HW costs, esp. NRE costs seem to get easily out of control.
In SW dev they have learned to do everything in small steps iterate and finish subtasks instead of one big bang. So indeed it all depends on the system IMO and also expandibility, it will not be the first time our team ran out of flash after the x th new featurelist that the PM wants implemented.
Then many IoT devices use multiple controllers or do you want to implement wifi on your stm? IP can be done, but also is a PITA with all monthly security updates. -
At my last job, we had a board that had 1 master and 4 slaves. Out of everything, it was one of the most robust parts of the system. To answer your question, it depends. How disciplined is the team? how well is stuff rev controlled? What is on each slave an don the master? what is the MCU? What market are you in? To put it in preservative, yeah, you could easily do lots of stuff on one chip with an FPGA, but do you have the people on your team to do it? You could easily do one ARM chip instead of two 8 bit PICs, but do you have someone to do it? Lastly, you could put it all in one chip, but do you really want to deal with the constraints that come with it? It is not a black and white answer.
-
At my last job, we had a board that had 1 master and 4 slaves. Out of everything, it was one of the most robust parts of the system. To answer your question, it depends. How disciplined is the team? how well is stuff rev controlled? What is on each slave an don the master? what is the MCU? What market are you in? To put it in preservative, yeah, you could easily do lots of stuff on one chip with an FPGA, but do you have the people on your team to do it? You could easily do one ARM chip instead of two 8 bit PICs, but do you have someone to do it? Lastly, you could put it all in one chip, but do you really want to deal with the constraints that come with it? It is not a black and white answer.
In my experience: at some point you just have to get better engineers if projects get too complicated. I've seen the mess some people make when they try to make something work with multiple small controllers because they don't know how to use one controller. My record is replacing 13 PICs on one board with a single ARM microcontroller which worked better and replaced some other stuff as well. -
Big-ish distances are a good reason to use multiple interconnected uCs. For example in cars. But tight real-time expected response times are a good reason to use a single uC. E.g. the PCM in a car is usually a single module.
sometimes a single module, sometimes it make sense to modularize things. i.e. so that different engines come with their own controller, different gear trains with their own controller etc. so you can easily mix and match -
1. Performance
Hard real-time requirements and especially low jitter may require separate controllers.
2. Convenience
Using a small controller as a local smart input and output expander may be much better than routing a pile of signals a long distance.
3. Reliability
Large single controller real-time and safety conscious designs have have an appalling record for reliability. Even if the programmers and programming tools are up to it, and neither is a given or even likely, a single programming error or soft error can clobber the whole system. Too often designs follow NASA's method of redefining what should be considered failures requiring a redesign as acceptable errors. For instance if memory fragmentation in the heap is ultimately resulting in memory allocation failures leading to triggering the watchdog timer resetting the system which then recovers, it does not matter if recovery was successful. That is a failure.
-
Large single controller real-time and safety conscious designs have have an appalling record for reliability. Even if the programmers and programming tools are up to it, and neither is a given or even likely, a single programming error or soft error can clobber the whole system.
Nowadays that is not a very good reason. If process seperation is a concern then you can use a microcontroller which supports memory protection (MPU). Modern (automotive) SoCs even support virtualisation right down to the video system. If the entertainment software goes haywire then the dashboard display isn't affected at all. IOW Nowadays you don't need physical seperation to achieve process seperation.