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).

[rstofer]

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.

[nctnico]

Take a look at the auto industry!  There are dozens of distributed uCs in the modern automobile.  I have been told it approaches 100:

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.

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.

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.

[ogden]

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.

[rstofer]

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/

[NorthGuy]

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.

[JPortici]

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

[mac.6]

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).

[Siwastaja]

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.

[obiwanjacobi]

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]

[nctnico]

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;

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.

[hans]

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)

[mikeselectricstuff]

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;

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.

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.
 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. 

[Siwastaja]

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.

[nctnico]

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.

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.

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.

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.

[SiliconWizard]

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.

[mikeselectricstuff]

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 possibly an advantage in the third parties may be able to interface to or enhance it.
Or that you (or a subcontractor) can redesign part of a system years down the line without touching the rest of it.

[GeorgeOfTheJungle]

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.

[GeorgeOfTheJungle]

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).

[fourtytwo42]

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

[Kjelt]

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.

[Gibson486]

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.

[nctnico]

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.

[langwadt]

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 

[David Hess]

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.

[nctnico]

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.

[langwadt]

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.

but there is probably good reason to keep the internet connected entertainment system/instrument cluster and the engine/brakes/steering physically separated so some guy in a basement in Hackistan can't drive you off a cliff remotely

[Kjelt]

And on security: meltdown is a real problem for process seperation and virtualization.

[nctnico]

And on security: meltdown is a real problem for process seperation and virtualization.

That is not really relevant because it is known and thus it can be solved.

[Kjelt]

And on security: meltdown is a real problem for process seperation and virtualization.

That is not really relevant because it is known and thus it can be solved.

Nico the only real solution AFAIK is to replace the processor with a newly designed one, the current patches rely on skipping some opcodes but relies on the os to inforce this. But for this discussion it might be too far offtopic.
I still think there are valid system cases where multiple processors are a good decision. Take a look at a pc for example would you really want the main core processor to do everything? Even sample all the aux input devices like mouses, keyboards , etc? How about controlling the harddisks? Although the original IBM PC with 8086 might have some performance issues doing this the current ones could handle it with ease but why don't they. Why use a complex USB protocol?
Wouldn't you say that it is a necessity in this case to make a good documented interface in order for all manufacturers to design, build and test these aux devices seperately? How often did you need to upgrade the firmware of your keyboard or harddisk? Was it essential?

[obiwanjacobi]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

 

[mikeselectricstuff]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

 

Like the choice of single or multiple processors, it's entirely application dependent.
There is no "good" or "bad", only more or less appropriate for a given set of constraints

[Gibson486]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

 

Like the choice of single or multiple processors, it's entirely application dependent.
There is no "good" or "bad", only more or less appropriate for a given set of constraints

Exactly. If everything were so black and white, they would not being paying engineers. Not everything is binary and if it was, lots of us would be in unemployment. There is no book that says, do this when this occurs and if there is, it is misguided. The books that give us the answers are the text books in school that just give us equations to formulate our thinking. That is the reason why the internet has so much conflicting info.  The reasoning behind it has to do with the application and constraints. Lots of the designs that were deemed "bad", were more likely due to the iterative process.  They started off as good decisions, but they were probably rushed into the rest of the design. Not everyone will be fortunate enough to put into a situation where they can carefully make architectural decisions.

[Tomorokoshi]

Not everyone will be fortunate enough to put into a situation where they can carefully make architectural decisions.

Does anyone really ever get that opportunity?

I'm working through several projects using the DAMS process.

It's all the rage these days: Design to Arbitrary Management Schedules.

[obiwanjacobi]

Okay, I worded my question poorly. I understand that 'it depends' 

Can we say something on what things to look out for, how you solved what problems in what way...?

[SiliconWizard]

Not everyone will be fortunate enough to put into a situation where they can carefully make architectural decisions.

Does anyone really ever get that opportunity?

At least in situations involving safety-critical devices, not only is it an opportunity, it's also a requirement.
And if you ever work in a company that designs such devices and doesn't care about architectural choices, don't just walk. Run.

I'm working through several projects using the DAMS process.

It's all the rage these days: Design to Arbitrary Management Schedules.

I know what you mean. It's somewhat related to all the "lean management" concepts that are currently in favor. Unfortunately, a lot of managers (usually at the top management level, not the middle managers) have been convinced that what works in production environments can be happily applied in any area of a company, including R&D.

[Siwastaja]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

 

If on the same board, SPI is usually a good candidate: even the smallest MCUs have it, bigger have shitloads of separate SPIs, it's often DMA'able (is that a word?) (compared to, say, I2C, where actually utilizing DMA and getting any benefit of it is often left as a dream). It's fast and robust, simple to debug. SPI is simple to make self-reset after the transmission, which is delimited/framed by actual physical signal, compare this to, for example, the state horror and lockups of I2C.

If on the separate boards and you need reliability for longer links, against noise, etc., consider CAN and RS422/485. CAN is great when you have quite some many devices together and everyone shouts something; RS422 is great as a link between two devices. Latter works even with most cheap microcontrollers which have UARTs. CAN seems rather OK mostly because apparently most MCU manufacturers have outsourced and bought the same bxCAN peripheral IP, which is of usable quality and documentation compared to what it could have been if, for example, ST had designed their own 

Retry logics are often more difficult than you'd expect! If possible, design periodic resend of important data in any case; implement timeouts on important things. Additional safety with counters that prove that the data is recent. This strategy is often used with CAN bus and in automotive. "Just flood the data", "throw bad data away" and "timeout to safe state if no recent data available" work way more robustly than trying to design a two-way "did you get it?" "do we need to resend?" logic. For example, how do you deal with lost resend requests? How do you deal with buffering all the data that might need resending? Don't try to implement an abstacted high-level message transfer protocol (i.e., something like TCP), chances are you are solving the wrong problem.

[GeorgeOfTheJungle]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

Easy peasy one UART per uC, for long distances use differential/balanced signaling (rs-422/485), the software protocol is up to you, but the simpler the better.

CAN is designed for multiple modules on a bus with message priorities and is thus needlessly complicated, avoid it except when you CAN't :-) and SPI is not designed for long distances and is 4 signals + GND for gods sake are you kidding me? A UART is one signal (half duplex single ended, wired or) or two (full duplex single ended or half duplex differential) or 4 if full duplex differential, +GND, there's nothing easier to use than that.

[nctnico]

And on security: meltdown is a real problem for process seperation and virtualization.

That is not really relevant because it is known and thus it can be solved.

Nico the only real solution AFAIK is to replace the processor with a newly designed one, the current patches rely on skipping some opcodes but relies on the os to inforce this.

Well, we are discussing a new design so there is no need to replace anything.

[Kjelt]

No just have to wait till the hardware is made, Q3 i believe Intel is shipping first silicon

[mikeselectricstuff]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

Easy peasy one UART per uC, for long distances use differential/balanced signaling (rs-422/485), the software protocol is up to you, but the simpler the better.

UART is a good first choice, but not always ideal as you need to deal with packet framing - an advantage of SPI is the chip-select takes care of this. SPI is also easier to bit-bash for transmit if you don't have enough peripherals, and doesn't care about system clock accuracy or jitter.
 
 

[Siwastaja]

Yeah, UART is often simple and great and everything, but....

The fact that SPI provides reliable hardware framing signal with no restrictions to packet length makes it really easier to use than UART for many purposes. Some microcontrollers even support managing the chip select signal, for example, by DMA.

Extra complexity added by framing seems to sometimes surprise young players. How do you do that with UART? Often by actually designing a protocol and writing a parser for it, easily 100 lines of code even for a rather simple task + specification you need to keep up to date. Bugs can easily sneak in as you need parser state.

With SPI, synchronous data swaps of two memory areas (simple self-documenting structs, for example), arbitrary length, even tens of kilobytes if necessary, between two CPUs can happen almost 100% automatically and very robustly, often with a few lines of code, and you have the job done. With UART, you are building and specifying message formats and messages and designing how to frame them, i.e., at what character does the previous message end and the next start?

But of course, it depends. Sometimes the UART solution is way simpler than SPI. Sometimes you want to give a simple command. And sometimes 8 bits [for a complete message] is enough, and UART can frame that for you!

CAN can be simpler than UART, as well. Often it solves the framing problem way easier than UART. Often, the ID is data type directly (i.e., it tells you where to assign the data), and 8 bytes of payload is quite usable! Now you don't need headers, delimiters, or parser code either. Many CAN-based systems are complex as hell, but it's not because they are using CAN. CAN seems to be trendy among "let's do everything the complex way" folks, but you can still use it in a sane way if you want to. I have replaced a complex UART horror (my earlier revision) with a simple and robust CAN solution. It's always nice when you can just delete a few hundred lines of message parsers and just do the underlying thing "directly" by using signaling that's more suitable for the task.

[MT]

Any paper around describing "CAN for us who dont like convoluted complex system solutions" or "CAN the simple elegant way"?

[GeorgeOfTheJungle]

There's no need to deal with framing in software/parsing, you can use the hardware to signal the start of frame with a break (a start bit that lasts a bit longer than a character time). DMX512 does it so too.

void on_rxErrInterrupt () {
    newFrame();
}

[nctnico]

Yeah, UART is often simple and great and everything, but....

The fact that SPI provides reliable hardware framing signal with no restrictions to packet length makes it really easier to use than UART for many purposes. Some microcontrollers even support managing the chip select signal, for example, by DMA.

Extra complexity added by framing seems to sometimes surprise young players. How do you do that with UART? Often by actually designing a protocol and writing a parser for it, easily 100 lines of code even for a rather simple task + specification you need to keep up to date. Bugs can easily sneak in as you need parser state.

With SPI, synchronous data swaps of two memory areas (simple self-documenting structs, for example), arbitrary length, even tens of kilobytes if necessary, between two CPUs can happen almost 100% automatically and very robustly, often with a few lines of code, and you have the job done. With UART, you are building and specifying message formats and messages and designing how to frame them, i.e., at what character does the previous message end and the next start?

I don't quite agree with this approach. First of all an SPI transaction can be screwed up by a single short spike on the clock line. Secondly sharing structs between various parts of the software is a major pain in the ass. If it gets changed in one place, it must be changed everywhere and how do you deal with backward compatibility? In many protocols you see a message consists of seperate strucs of data each with header which has the type, length and sometimes a version. Still not ideal but at least it has some way to deal with incompatible versions. Last but not least I'm weary of sharing large / many data structures. That is usually a sign a distributed system hasn't been partioned properly and thus there are too many dependancies which need to cross the border from one device to the other.

What I did for a system which needed distributed processors is the following: I used a bit-banged multi-drop framing protocol using NRZ signalling over RS485 because I had that available but it could have been UART based just as well. The payload of the messages consists of commands in plain text (which also makes framing easy: STX and ETX are the characters to use when using a UART). Every product I make has a command line interpreter on a serial port anyway so getting the system to work is just a matter of putting the payload of the messages into the command line interpreter and sending the result (OK, a value, whatever) to the sender of the message. Debugging is very easy because you can enter the commands through the serial port too (in a debug built) and dump whatever is being send over the 'network'. Backward compatibility is also easy. If a device can't deal with a command or if there are extra parameters the system doesn't fall apart.

[mikeselectricstuff]

But of course, it depends. Sometimes the UART solution is way simpler than SPI. Sometimes you want to give a simple command. And sometimes 8 bits is enough, and UART can frame that for you!

Or you can use a single unique byte value for start-of-frame, which makes a lot of things very simple.
One characteristic of UART is that either end can initiate a message, whearas SPI is typically master-slave.  Either will have advantages and disadvantages depending on system requirements

[mikeselectricstuff]

There's no need to deal with framing in software/parsing, you can use the hardware to signal the start of frame with a break (a start bit that lasts a bit longer than a character time). DMX512 does it so too.

void on_rxErrInterrupt () {
    newFrame();
}

Out-of-band signals like breaks can sometimes be useful, but can also have subtle issues once you start having things like fifo's and UART error interrupts. At the very least these are often not well documented. It also makes life harder if you need to transport over other protocols.

[GeorgeOfTheJungle]

There's no need to deal with framing in software/parsing, you can use the hardware to signal the start of frame with a break (a start bit that lasts a bit longer than a character time). DMX512 does it so too.

void on_rxErrInterrupt () {
    newFrame();
}

Out-of-band signals like breaks can sometimes be useful, but can also have subtle issues once you start having things like fifo's and UART error interrupts. At the very least these are often not well documented. It also makes life harder if you need to transport over other protocols.

Yes, I know, right you are  , it was in response to this:

Extra complexity added by framing seems to sometimes surprise young players. How do you do that with UART? Often by actually designing a protocol and writing a parser for it, easily 100 lines of code even for a rather simple task + specification you need to keep up to date. Bugs can easily sneak in as you need parser state.

[Siwastaja]

I don't quite agree with this approach. First of all an SPI transaction can be screwed up by a single short spike on the clock line. Secondly sharing structs between various parts of the software is a major pain in the ass. If it gets changed in one place, it must be changed everywhere and how do you deal with backward compatibility? In many protocols you see a message consists of seperate strucs of data each with header which has the type, length and sometimes a version. Still not ideal but at least it has some way to deal with incompatible versions. Last but not least I'm weary of sharing large / many data structures. That is usually a sign a distributed system hasn't been partioned properly and thus there are too many dependancies which need to cross the border from one device to the other.

I'm sorry but I'm really unable to find any valid point in your reply.

UART is immune to "single short spike"?

Checksumming against electrical corruption applies to any of the mentioned schemes similarly. Clear hardware framing makes this task so much easier, you can resync right to the next packet.

I'm actually using UART as well quite a lot and have tried several ways of framing, message ID'ing, error correction, etc. Not super complex stuff, but if at all possible, I'll avoid it.

Keeping the communication structure on the both sides pain in the ass? Tough game, that's what you have in the multi-MCU system. I can't see how you are going to magically get rid of this task. In multi-MCU system, especially on the same physical board, a simple struct{} is by far the easiest, and can even share the same .h file, so only once place needs modification. It's also readable enough so that it self-documents. I can't figure out any way to get it more maintainable than that - what you suggest requires 3-4 orders of magnitude more maintaining and matching between two systems. Define packet structure - change on both sides when necessary. Define message types - change on both sides when necessary. Document everything. Keep the documentation up-to-date.

Unless, of course, the system is just simple enough. For one or two simple messages, it doesn't matter. Especially if it doesn't need to be super robust.

ASCII UART based systems are nice for human intervention; most I have seen are buggy as hell and total pain in the ass to automate. Yeah, it's OK to use a buggy ASCII parser when you are a human. Everything happens slowly when you type, so race conditions are left untested. Framing does not work reliably? You hit some random keys or reset manually until it works again. Some command is totally left unaswerred? Not a big deal, just command it again. Nothing works? The parser crashes due to wrong type of line feed in use - configure your terminal until it works. As a human, we have a great troubleshooting system called "brain" which "autonegotiates" the communication link.

Last time I needed to actually use - i.e., not test it on the lab table - such a product (a scanning 2D LIDAR using such a "simple" text-based UART interface for configuration, switching to binary communication after init so you cannot do anything with it on terminal, anyway ), it took about 300 lines of code and a few days of bug hunting development and reverse engineering to get the it work reliably. The documentation of communication is nicely laid out and looks professional, but it doesn't match the actual behavior 1:1. Things like "it randomly completely ignores a certain message" are extremely easy when you initialize it as a human. Or when it replies something completely unexpected back, you use your super capable AI Brain^tm technology to parse and decide what to do! But in actual production code, it's added complexity to the state machine, again. And they seem to be going out of business right now.

In these kind of systems, you typically have two layers of state machines (actual messaging, and message-level parsing/framing/error checking) on both ends.

And yes, with this LIDAR, it's just normal that it gets stuck or crashes and you need to reset it. They even offer a handy hardware signal to make that easy. But they provide checksumming! Never had a checksum failure, though.

Sure, you can make the ASCII UART interface work, and it has many appealing points. But for multi-MCU system? Nah, it's not super difficult. But compared to many much easier options (which I have covered already), this is completely on a different level of complexity than a simple memory swap using a framed low-level protocol such as SPI or CAN, equipped with a simple checksum automatically calculated over the framed data. Especially if you need robustness and/or high performance in the system.

My issue is that I'm doing such complex systems alone right now that I simply don't have time to play "let's design a nice protocol" games - the solutions just need to be simple and robust.

And in the MCU world, we always don't have full libc with all fancy-pancy sscanf() stuff available.

[donotdespisethesnake]

So if you would choose to use multiple processors. what would be a good protocol for the communication?
(both electronic design (diff-signals?) as software design (retry-logic?))

 

The discussion to that question will likely go on for another 10 pages. Which also shed lights on why it is not a good idea to use multiple processors if you have a choice.

To answer the original question another way, only consider using multiple processors if you have a good understanding of comms and networking. There are many traps for the unwary.

[nctnico]

I don't quite agree with this approach. First of all an SPI transaction can be screwed up by a single short spike on the clock line. Secondly sharing structs between various parts of the software is a major pain in the ass. If it gets changed in one place, it must be changed everywhere and how do you deal with backward compatibility? In many protocols you see a message consists of seperate strucs of data each with header which has the type, length and sometimes a version. Still not ideal but at least it has some way to deal with incompatible versions. Last but not least I'm weary of sharing large / many data structures. That is usually a sign a distributed system hasn't been partioned properly and thus there are too many dependancies which need to cross the border from one device to the other.

I'm sorry but I'm really unable to find any valid point in your reply.

UART is immune to "single short spike"?

Yes. Because a UART is sampling the signal (hence the 8x or 16x clock) the spike doesn't even register. Remember that UARTs are invented as part of a physical layer to transmit data over very long distances. Checksums are nice but it helps if the physical layer has immunity to spikes built in.

I think the whole world disagrees with you that text based protocols are bad. HTTP, VOIP, JSON, XML, SCPI are good examples.

[obiwanjacobi]

So you would specifically choose async UART - most MCU also support sync UART. But the clock signal can be viewed as a single point of failure. Speed may suffer, though. Is there any trick to speed things up?

[JPortici]

CAN can be simpler than UART, as well. Often it solves the framing problem way easier than UART. Often, the ID is data type directly (i.e., it tells you where to assign the data), and 8 bytes of payload is quite usable! Now you don't need headers, delimiters, or parser code either. Many CAN-based systems are complex as hell, but it's not because they are using CAN. CAN seems to be trendy among "let's do everything the complex way" folks, but you can still use it in a sane way if you want to. I have replaced a complex UART horror (my earlier revision) with a simple and robust CAN solution. It's always nice when you can just delete a few hundred lines of message parsers and just do the underlying thing "directly" by using signaling that's more suitable for the task.

In a synthesizer project of mine, many voices share a single control. I'm contemplating the use of CAN instead of multiple UARTs because the "front panel" SHOUTS the knobs potision to all the voice cards. Then implementing some sort of MIDI-Over-Can for notes on and off. The voices basically have to just listen for the main module

[MT]

In a synthesizer project of mine, many voices share a single control. I'm contemplating the use of CAN instead of multiple UARTs because the "front panel" SHOUTS the knobs potision to all the voice cards. Then implementing some sort of MIDI-Over-Can for notes on and off. The voices basically have to just listen for the main module

Dont complicate things, just use the MIDI protocol as is even a simplified handler will do (with higher baudrate if needed) from master to voice cards. And/or an extension of it , UART simplex onewire 9bit auto address mode,
all open collector for back and forth talking.

The front panel dont shout any control parameters, the master MCU does and your code allow it to send parameters
only when changed not continuously so no need for CAN. Baudrate only need to be sufficiently high to swamp out any noticeable audiodelays when a 10(or more) note chord and multiple parameter changes is made at the same time.

3 wire SPI is also an good candidate.

[mikeselectricstuff]

Dont complicate things, just use the MIDI protocol as is even a simplified handler will do (with higher baudrate if needed) from master to voice cards. And/or an extension of it , UART simplex onewire 9bit auto address mode,
all open collector for back and forth talking.

For a multi-master UART bus, open-collector/drain is rather limiting on baurate due to pullup time, and slow pullups can cause data flakiness. Better to use tri-state enabling of the transmitter during transmission. this can usually be done with no extra hardware (assuming the UART allows disabling of the transmitter output without also disabling the receiver - there are a few that don't) , using a TX-complete interrupt to disable the UART TX  after the transmission.

[JPortici]

Nah, i don't think i'm overcomplicating things. I have one shouting master and essentially 1-to-16 silent slaves and the master is talking to all of them, sometimes at the same time.
I actually thought of a solution using UART. Daisy chain all the boards, frames with header "zero" are broadcast messages that always get retransmitted.
headers "1" to "16" stop at the addressed slave. that should be easy to automate.

yes, i never used UART in a star topology

[nctnico]

Nah, i don't think i'm overcomplicating things. I have one shouting master and essentially 1-to-16 silent slaves and the master is talking to all of them, sometimes at the same time.
I actually thought of a solution using UART. Daisy chain all the boards, frames with header "zero" are broadcast messages that always get retransmitted.
headers "1" to "16" stop at the addressed slave. that should be easy to automate.

yes, i never used UART in a star topology

Daisy chaining UARTs is a bad idea. The first device gets flooded with all the messages. Better use an RS485 half duplex bus structure.

[MT]

Nah, i don't think i'm overcomplicating things. I have one shouting master and essentially 1-to-16 silent slaves and the master is talking to all of them, sometimes at the same time. I actually thought of a solution using UART. Daisy chain all the boards, frames with header "zero" are broadcast messages that always get retransmitted.

"Dont shout" be silent and efficient like mailman, yes you are complicating things by daisy chain in non auto address mode, dont garbage up your serial. just "channel access" each board. Auto addressing reduces interrupts, UART only interrupts on address match no software and buffering to decode channel/massage for slave MCU.

yes, i never used UART in a star topology

Time is now!

[MT]

For a multi-master UART bus, open-collector/drain is rather limiting on baurate due to pullup time, and slow pullups can cause data flakiness. Better to use tri-state enabling of the transmitter during transmission. this can usually be done with no extra hardware (assuming the UART allows disabling of the transmitter output without also disabling the receiver - there are a few that don't) , using a TX-complete interrupt to disable the UART TX  after the transmission.

Concur for higher speeds tristate/buffer whatever, but star uses only one pullup, i dont know how many voice cards he intend to use. STM32 USART junks RX/TX internally in single-wire half-duplex mode. RX or TX can be turned off in normal USART mode.

[JPortici]

Full duplex! I intend to update the firmware in the voice cards  the card has at least to say all ok, or error on frame XX
Still, i can't see the advantage of RS485 over CAN, the MCU price difference is like 0.15 in a 5-6€ figure, the can controller does a lot of things for you like framing, priorities, detecting transmission error and retransmitting on error..

[langwadt]

Yeah, UART is often simple and great and everything, but....

The fact that SPI provides reliable hardware framing signal with no restrictions to packet length makes it really easier to use than UART for many purposes. Some microcontrollers even support managing the chip select signal, for example, by DMA.

Extra complexity added by framing seems to sometimes surprise young players. How do you do that with UART? Often by actually designing a protocol and writing a parser for it, easily 100 lines of code even for a rather simple task + specification you need to keep up to date. Bugs can easily sneak in as you need parser state.

With SPI, synchronous data swaps of two memory areas (simple self-documenting structs, for example), arbitrary length, even tens of kilobytes if necessary, between two CPUs can happen almost 100% automatically and very robustly, often with a few lines of code, and you have the job done. With UART, you are building and specifying message formats and messages and designing how to frame them, i.e., at what character does the previous message end and the next start?

But of course, it depends. Sometimes the UART solution is way simpler than SPI. Sometimes you want to give a simple command. And sometimes 8 bits [for a complete message] is enough, and UART can frame that for you!

CAN can be simpler than UART, as well. Often it solves the framing problem way easier than UART. Often, the ID is data type directly (i.e., it tells you where to assign the data), and 8 bytes of payload is quite usable! Now you don't need headers, delimiters, or parser code either. Many CAN-based systems are complex as hell, but it's not because they are using CAN. CAN seems to be trendy among "let's do everything the complex way" folks, but you can still use it in a sane way if you want to. I have replaced a complex UART horror (my earlier revision) with a simple and robust CAN solution. It's always nice when you can just delete a few hundred lines of message parsers and just do the underlying thing "directly" by using signaling that's more suitable for the task.

and implementing (some subset of) https://en.wikipedia.org/wiki/ISO_15765-2 if you needed more than 8 byte payloads
on CAN is very simple

[Siwastaja]

Full duplex! I intend to update the firmware in the voice cards  the card has at least to say all ok, or error on frame XX
Still, i can't see the advantage of RS485 over CAN, the MCU price difference is like 0.15 in a 5-6€ figure, the can controller does a lot of things for you like framing, priorities, detecting transmission error and retransmitting on error..

Agree with CAN. Most MCUs use the same outsourced bxCAN peripheral IP, which is of fairly usable quality. You can easily configure hardware filters to only read specific CAN IDs (or masked ranges) you are interested about. You have hardware checksumming, and extremely simple framing up to 64 bits of payload, which is fairly good for synthesizer commands, I think. When 8 bytes is insufficient as is, you can dedicate part of the ID space to map certain settings or commands within the same unit, especially if you use the extended 29-bit IDs. Then, for example, just map the lowest 8 bits of the ID to denote actual "command" or "variable address" within one unit.

This is all very simple - again it's basically sharing memory, instead of developing "communication protocols" and "writing parsers".

Retransmission on CRC error, by the way, is very nontrivial in a UART message parser. CAN does this for you. You may still want to look at some statistics for error numbers and latency, though. Luckily, the CAN peripheral almost always provides easy ways to assist this, for example, error counters and message timestamping.