Multi Microcontroller design.

[jitece]

Hi friends,
I am working on an application where there are 2 pcb boards.

Board A : Critical task only. Cant be used  settings because of the delays involved .EEPROM is on this Board.
Board B : Mcu with lcd and switches for storing the user defined variables.


Board A is doing a critical task so it can't be used for user defined settings .

Board B is having lcd and switches so we have to use it for saving the settings. The changes made in this board will have to be reflected to eeprom on other Board A.

But these settings have to be transferred to board A so that it can be used for its working......and also we might need to read some physical parameters (unsigned long int , unsigned int type) from Board A to Board B for display on the Lcd of Board B.

The Main concern is even if the Board B is busy in doing the settings , Board A operation of operating some critical relays should not be delayed because it cannot wait if we think of putting the settings part on uc A.

What is the best approach in this kind of scenario where Communication between 2 mcus is needed without interrupting the critical operation of one of the mcus ,which is on Board A in our case.
Any specific protocol: Uart interrupt based , I2C data transfer etc.

For writing part:
I was also thinking of using a common eeprom for storing settings from Board B , and then reading by Board A when required by some extra pins used as i/o on both sides.
 For reading Part : I2C or spi read of the variables from Board A to Board B.


Please let me know how to proceed in such scenario....

[deskpro256]

Hello.

Well, there is never one best solution

There are many variables to what you should use and why.
Data transfer speed, amount of data, distance between devices, how many devices would be on the bus and many more.

What would the distance between the two boards be? Look into RS485 or CAN.

I, personally, haven't used CAN yet, but I have made a project with RS485 and some custom messaging protocol. You can also use MODBUS or other protocols.

What I have is a fairly simple system with a Master and (up to 16) Slave devices. The master is always, let's say, 0x1C and the slaves have a 4 bit DIP switch, that the user uses to set their addresses from 0x00 to 0x0F. When the devices turn on, they read their ID and their setting from the EEPROM and start doing their thing.

The master also does the same and then starts sending messages to all the devices on the bus one by one. The slaves are always reading the bus if there are messages being sent and if the message has their ID in the messages ID byte, they read the whole message, do the thing according to the command and then reply to the master.

A basic protocol would consist of:
Start byte | Receiving device address byte | Sender device address byte  | Command byte | Your data[some byte lenght] | CRC byte | End byte

If you want to have dynamic length messages, you could also add a byte for the data length, so the receiver knows how much to read next and later calculate the CRC.

I'd say use the EEPROM's the devices already have, and send the config/settings over the bus, saves you I/O, board space and money for a part.

That should get you started I guess.

I'm certain others have some other ideas and experience based opinions on this subject.

[ajb]

"Critical tasks" and user interaction do not necessarily need to be carried out on different MCUs.  Tons of applications manage to do both on one part, through non-blocking design and careful management of task and interrupt priority.  There are some applications where the critical task is too demanding to also have user interaction on the same MCU core, but turning a couple of relays on and off generally doesn't rise to that level. 

More sophisticated MCUs are of course better suited to multi-tasking, especially where you will have multiple threads of execution, because you can either use a real RTOS that handles a lot of task switching for you, or you can rely on nestable prioritzed interrupts and system interrupts to manage program flow and also use DMA to free the core up from having to manually shuttle data around.

Of course it's impossible to say what the best approach is for you without knowing what, exactly, is "critical" about the things Board A is doing. 

Anyway, if you really need to minimize the communication overhead Board A needs to deal with I would pick a part and a protocol that will allow Board A to receive messages from Board B with little or no CPU overhead--meaning a peripheral with DMA.  That way Board A can just sit there and periodically, between critical tasks, check a DMA flag to see if a complete message has been received from board B, and if so, process it and use DMA to send whatever response is required back to Board B.  I'm not sure if I2C will be good for this, that's generally harder to DMA because the slave has to respond at the master's pace (clock stretching aside), but SPI or UART or maybe even CAN should be doable.  You might need to plan for Board A's critical tasks to be able to interrupt the processing of a message, depending on how predictable those tasks are and how complicated it is to handle a message, that's generally not a big deal.

[asmi]

Take STM32H7 dual-core MCU and that will give you 2 MCUs in a single package with no routing headaches associated with multiple MCUs. It's got an M7 core good up to 480 MHz, and M4 core up to 240 MHz. I use it in one of my customer's projects and I got to say it's a beast!

[jackthomson43]

Working on multiple microcontrollers in a single project is never a good option. You can try Arduino YUN, it got the microprocessor and microcontroller embedded in a single chip.

[tggzzz]

Look at the XMOS xCORE devices, available from DigiKey.

An MCU can contain up to 32 cores and run 4000MIPS, and are designed for hard realtime embedded work. It is perfectly possible and simple to have some cores doing the computation, some the critical i/o, others front panel operation, others communicating over ethernet or USB.

When doing all that, the timing is guaranteed by design; the IDE tells you the exact number of clock cycles between here and there. There is no need to run the code and hope you have encounted the worst case.

I/O timing can be specified down to a specific clock cycle, and i/o clocks can be 250MHz / 4ns and are independent of the core speed.

[ale500]

The XCORE chips come in several flavours, with up to 8 (think of SMT) logical processors per core. It executes one opcode in 4 clocks but it interleaves the other logical processor's execution and does not waste any clocks (unless you use less than 4 logical processors, then some cycles are "empty"). Very clever use of resources. You get up to 500 (they say 1000 with some trickery) MIPS per logical core. I used to develop for their earliest generation back in 2008, they had at the time 64 kSRAM. Newer parts have 512 kBytes of shared memory between logical cores. The programming language, a derivative of C, called XC (also supports C, the compiler is gcc based), has extensions for thread start and such things. And very comprehensive multi platform development tools. Worth looking at.

You could also, depending on the amount of data go for a Parallax Propeller (1 or 2), they have 8 separated processors sharing some common memory. The Propeller 1 has 32 kBytes shared and gets 20 MIPS per processor, and the Propeller 2 has 512 kBytes and gets something like 180 MIPS per processor. These may be simpler to access, in my opinion very easy to work with (I have only used the Propeller 1). Very nice easy assembly .

[tggzzz]

The XCORE chips come in several flavours, with up to 8 (think of SMT) logical processors per core. It executes one opcode in 4 clocks but it interleaves the other logical processor's execution and does not waste any clocks (unless you use less than 4 logical processors, then some cycles are "empty"). Very clever use of resources. You get up to 500 (they say 1000 with some trickery) MIPS per logical core. I used to develop for their earliest generation back in 2008, they had at the time 64 kSRAM. Newer parts have 512 kBytes of shared memory between logical cores. The programming language, a derivative of C, called XC (also supports C, the compiler is gcc based), has extensions for thread start and such things. And very comprehensive multi platform development tools. Worth looking at.

The XMOS hardware is neat and simple to use, but there have been many processors like that.

The single most impressive thing about the XMOS is that the software (the xC language) and tools (the IDE) are closely integrated with the hardware. That is absolutely necessary in order to be able to make full use of the hardware.

An demonstration of the power of the system is that it is possible to have software receiving and transmitting serial 100Mb/s ethernet streams 32bits at a time, and decoding packets, while other cores are doing the application's work. The trick is to be able to guarantee that no input is missed nor output timings is violated when the other work is being done. N.B. arguably that is a waste of cores, and dedicate silicon is more appropriate. Nonetheless, that demonstration even being possible is impressive.

BTW, no indiviual XMOS component is radically new. They are a modern refinement of proven techniques: Transputer, Occam, and Hoare's CSP.

You could also, depending on the amount of data go for a Parallax Propeller (1 or 2), they have 8 separated processors sharing some common memory. The Propeller 1 has 32 kBytes shared and gets 20 MIPS per processor, and the Propeller 2 has 512 kBytes and gets something like 180 MIPS per processor. These may be simpler to access, in my opinion very easy to work with (I have only used the Propeller 1). Very nice easy assembly .

When I looked at the Propellor a few years ago, I didn't spot nice i/o nor integrated language nor integrated tools. Parallel hardware is easy; parallel software isn't.

[ogden]

Board A is doing a critical task so it can't be used for user defined settings .

If Board A can safely communicate with Board B then it can safely handle basic user interface as well. You don't need ultra-high performance multicore MCU for that. Shame to Xcore preachers who are offering overkill solution. Generic ARM MCU running at >= 4x higher frequency than existing MCU's could be enough for the job.

[tggzzz]

Board A is doing a critical task so it can't be used for user defined settings .

If Board A can safely communicate with Board B then it can safely handle basic user interface as well. You don't need ultra-high performance multicore MCU for that. Shame to Xcore preachers who are offering overkill solution. Generic ARM MCU running at >= 4x higher frequency than existing MCU's could be enough for the job.

And what, precisely, make you qualified to know what is necessary and sufficient in this case?

What is the justification for your specific advice, given that the OP has given zero information about:

• specific timing constraints
• processors/boards
• application
• penalty of missing deadlines

For that matter, do you know what is necessary to guarantee that a deadline will be met? Hint: if measurement is involved, you have lost

[ogden]

And what, precisely, make you qualified to know what is necessary and sufficient in this case?

Yes you are right, I don't know for sure due to many unknowns here. My advice is as good as yours. What I said was result of guesswork based on few clues provided in the post #1. To state obvious: never take posts in the public forum for a granted

[nctnico]

Hi friends,
I am working on an application where there are 2 pcb boards.

Board A : Critical task only. Cant be used  settings because of the delays involved .EEPROM is on this Board.
Board B : Mcu with lcd and switches for storing the user defined variables.


Board A is doing a critical task so it can't be used for user defined settings .

Board B is having lcd and switches so we have to use it for saving the settings. The changes made in this board will have to be reflected to eeprom on other Board A.

But these settings have to be transferred to board A so that it can be used for its working......and also we might need to read some physical parameters (unsigned long int , unsigned int type) from Board A to Board B for display on the Lcd of Board B.

The Main concern is even if the Board B is busy in doing the settings , Board A operation of operating some critical relays should not be delayed because it cannot wait if we think of putting the settings part on uc A.

What is the best approach in this kind of scenario where Communication between 2 mcus is needed without interrupting the critical operation of one of the mcus ,which is on Board A in our case.
Any specific protocol: Uart interrupt based , I2C data transfer etc.

My first advice is: don't use 2 MCUs but do everything in one. You can use either an RTOS or interrupts to make sure the critical task gets handled. I see the interrupt controller as a hardware multi-tasking OS. Do time critical things inside an interrupt (including all the processing!) and do other less criticial things in the main thread. By having multiple interrupts and setting priorities you can have several parallel processes. But you'll need to make sure that the CPU has enough processing power and there is enough buffering to handle all processes in time. This needs prototyping / verification.

If you do need to use 2 boards then I strongly suggest to use the SCPI text based protocol which is commonly used for test equipment. Currently I'm working on a project which has a Linux SBC for the user interface and a microcontroller for a hard realtime process. Between these 2 there is an RS232 link and the communication goes through the SCPI protocol. Realtime process related settings are in the realtime board, user related settings are in the Linux SBC. But it is a bit of a mess when it comes to the settings and dividing tasks between two platforms has limitations. If you are not careful there has to be a lot of communication between the 2 platforms to stay in sync which also consumes processor time. Also the 2 platforms should handle the situation where one is no longer responding. The latter is the biggest hurdle to overcome when dealing with multi-microcontroller designs and it is often under-estimated.

All in all, think about what your problem actually is: you don't know how to make processes work in parallel on a microcontroller, 1 microcontroller doesn't cut it and you are unfamiliar with one which does, 1 microcontroller (even the fastest one) is not fast/good enough or there are regulations saying you must use 2 microcontrollers. Only the last 2 reasons are good to go for a multi-microcontroller system. The others mean you have some learning to do.

[jitece]

Well I would share some more details regarding the application.

Board A :The mcu used is PIC 24 series running at 40 MHz.
It is involved in reading 3 phase AC voltages , READING KWH (ENERGY) FROM 3 phase Load by continuously reading the registers of the energy meter ic within one second based on interrupt, It cant be delayed .i.e the code is polling every second to read energy.

Based on the values of 3 phases which can change anytime ,it switches a sequence of 10 relays  in 3 -4 seconds interval.

It is also running some logic to continuously do the automation part , driving 3 relay boards , reading some 12 input conditions like faults , driving separate 20 relays as output.
It is also sending data to (gsm modem with another mcu) for logging to server.
Logging Faults in eeprom on this Board A only.

I have tried running the user interface (LCD and Switches ) on this board.But the problem is The moment i go into setting menu The relay operation retains the last value as i am not operating it using timer.

Also the user interface which is a graphic lcd doesnt respond properly to the switches as there is a lot operating behind using timers and interrupts.
So this is the reason why i m planning to add another mcu to drive the glcd and switches to change the settings flawlessly.
However this will put another challenge to me of how to read the data from this Board A (data like energy , voltages ,faults to be displayed )from mcu RAM  to my new Board B(dedicated  Glcd,switches).

The data to be transferred to Board Will be around 50 variables of unsigned int type.And there is data to be read also from eeprom settings as well as faulty logs.

I hope That clarifies some doubts.

The distance between 2 boards is not much .Around 2 feet.
 

[oPossum]

The mcu used is PIC 24 series running at 40 MHz.

There are dual core 16 bit PIC... https://www.microchip.com/design-centers/16-bit/products/dspic33c/dspic33ch

[nctnico]

Well I would share some more details regarding the application.

Board A :The mcu used is PIC 24 series running at 40 MHz.
It is involved in reading 3 phase AC voltages , READING KWH (ENERGY) FROM 3 phase Load by continuously reading the registers of the energy meter ic within one second based on interrupt, It cant be delayed .i.e the code is polling every second to read energy.

Based on the values of 3 phases which can change anytime ,it switches a sequence of 10 relays  in 3 -4 seconds interval.

It is also running some logic to continuously do the automation part , driving 3 relay boards , reading some 12 input conditions like faults , driving separate 20 relays as output.
It is also sending data to (gsm modem with another mcu) for logging to server.
Logging Faults in eeprom on this Board A only.

I have tried running the user interface (LCD and Switches ) on this board.But the problem is The moment i go into setting menu The relay operation retains the last value as i am not operating it using timer.

Also the user interface which is a graphic lcd doesnt respond properly to the switches as there is a lot operating behind using timers and interrupts.
So this is the reason why i m planning to add another mcu to drive the glcd and switches to change the settings flawlessly.
However this will put another challenge to me of how to read the data from this Board A (data like energy , voltages ,faults to be displayed )from mcu RAM  to my new Board B(dedicated  Glcd,switches).

The data to be transferred to Board Will be around 50 variables of unsigned int type.And there is data to be read also from eeprom settings as well as faulty logs.

I hope That clarifies some doubts.

The distance between 2 boards is not much .Around 2 feet.

This project doesn't need 2 microcontrollers (or dual core). Just use a RTOS to make the tasks run in parallel; that will be much less painful to develop compared to trying to make 2 seperate microcontrollers work together.

[jitece]

The mcu used is PIC 24 series running at 40 MHz.

There are dual core 16 bit PIC... https://www.microchip.com/design-centers/16-bit/products/dspic33c/dspic33ch

Hi My application requires around 100 pin mcu , Not available in PIC 16 bit series yet.

[jitece]

Well I would share some more details regarding the application.

Board A :The mcu used is PIC 24 series running at 40 MHz.
It is involved in reading 3 phase AC voltages , READING KWH (ENERGY) FROM 3 phase Load by continuously reading the registers of the energy meter ic within one second based on interrupt, It cant be delayed .i.e the code is polling every second to read energy.

Based on the values of 3 phases which can change anytime ,it switches a sequence of 10 relays  in 3 -4 seconds interval.

It is also running some logic to continuously do the automation part , driving 3 relay boards , reading some 12 input conditions like faults , driving separate 20 relays as output.
It is also sending data to (gsm modem with another mcu) for logging to server.
Logging Faults in eeprom on this Board A only.

I have tried running the user interface (LCD and Switches ) on this board.But the problem is The moment i go into setting menu The relay operation retains the last value as i am not operating it using timer.

Also the user interface which is a graphic lcd doesnt respond properly to the switches as there is a lot operating behind using timers and interrupts.
So this is the reason why i m planning to add another mcu to drive the glcd and switches to change the settings flawlessly.
However this will put another challenge to me of how to read the data from this Board A (data like energy , voltages ,faults to be displayed )from mcu RAM  to my new Board B(dedicated  Glcd,switches).

The data to be transferred to Board Will be around 50 variables of unsigned int type.And there is data to be read also from eeprom settings as well as faulty logs.

I hope That clarifies some doubts.

The distance between 2 boards is not much .Around 2 feet.

This project doesn't need 2 microcontrollers (or dual core). Just use a RTOS to make the tasks run in parallel; that will be much less painful to develop compared to trying to make 2 seperate microcontrollers work together.

Never used RTOS before . Can you brief some more detail how it works , does it need some new software in case of PIC24 series.

[nctnico]

You can look here: https://www.freertos.org/portpic24_dspic.html
You likely want to use pre-emptive scheduling so the OS divides the CPU time across the tasks. But you will have to do some work yourself as well like using sleep or a (OS provided) timer so tell the RTOS a task doesn't need any processing time right now.

Also a good book on using microcontrollers and creating parallel tasks without using an RTOS is this: 'Making embedded systems' written by 'Elecia White'. This book shows an approach using state machines and interrupts to achieve parallel tasks.

[snarkysparky]

Doesn't seem like the real time requirements are that hard.  You mention seconds for timing.

they key is non blocking code.  If possible never pause anywhere.   Scan for work needing to be done.

Is the LCD code doing so much per call that it is blocking a long time?

Try to break the work up over multiple short duration scans of all the code.

That said I must confess to having just made a board with 17 microcontrollers on it.  One master 16 slaves.
Ducks for thrown objects

[mikerj]

Working on multiple microcontrollers in a single project is never a good option.

Never is a strong word.  Occasionally it can be a reasonable, or possibly the only option.

[SiliconWizard]

Working on multiple microcontrollers in a single project is never a good option.

Never is a strong word.  Occasionally it can be a reasonable, or possibly the only option.

Indeed.

Interesting how in this thread we can read a lot of very strong, one-sided opinions, sprinkled with never's and always's.

Actually using two different physical processors, if just for safety concerns (isolating), is a pretty reasonable option. It might take a bit more effort, but it's also much easier to properly ensure tasks are fully isolated. Ensuring that on a single physical processor is of course possible (to some extent), but takes cautious approaches and is often a lot harder to prove correct.

And then of course, it all depends on the project, its criticity, other technical requirements, cost requirements, and many more criterions.

[donotdespisethesnake]

Doesn't need multicore or RTOS, just some basic multitasking. There is a lot more to real time techniques than a polling superloop.

[Doctorandus_P]

What is this "critical task" hookaboora?
And why would it mean a single uC would not be able to handle a display as well?

There can be many reasons for splitting a design over multiple uC's, but from OP there simply is not enough info to give any reasonable advice.
How much work does the uC have to perform?
Maybe the simplest 8-bitter is good enough, or he needs a multi GHz device. 

A simple UART based control is easiest to split with optocouplers, if that is an advantage.
Simplest protocol would be a one-way communication. the "critical uC" then sleeps during the "critical stuff" for lower noise in analog stuff, and periodically sends it's results through a opto to "elsewhere".

The other uC could for example assume there is no "critical task" ongoing just after it received a message from the "critical task", and then spit out some bytes to change settings or such for the next measurements.

The main thing though is that you have to work out some kind of protocol and both sides need to speak the same protocol.

If galvanic isolation is not mandatory, then I2C may have an edge over other protols. Every decent implementation of I2C has slew rate limited drivers, which help to keep the noise down.

A uC continuously scanning a matrix keyboard, while simultaneously using the ADC is very difficult to get right on Vero Board.

[Siwastaja]

These threads are always fun; no one has freaking idea about anything that's needed to solve the problem, yet the opinions are strong. tggzzz's silver bullet is the XMOS, and nctnico's silver bullet is never ever even considering multi-MCU.

Task:
Turn some relays on/off without delays.

Solution:
Use XMOS so that the IDE proves timing to 4ns!!!! You LOSE otherwise!

Reality:
Relays have milliseconds of delays and timing jitter!

What we really need, is better specification of the problem.

For really tight timing in really complex situations, options are FPGA, CPLD, or maybe the XMOS product series if it hits the sweet spot.

Sometimes, multi-MCU is a fairly easy, also low-cost solution, but I'd default to not recommending it. You'll see if it makes your life easier instead of making it harder in your particular design.

In most cases, any properly selected single MCU does the job. ARM MCUs implement interrupt priorities and pre-empting interrupts; they also implement 12-cycle interrupt latency; running from flash induces slightly variable timing, but it's easy to prove the timing approximately. It's irrelevant whether the "turn off the relay" operation takes 15 or 20 cycles, if the specification requires doing it in less than 20000 cycles. Also the most common use cases tend to be covered by the peripherals, IN HARDWARE, for example cycle-by-cycle current limiting and safety cutoffs in motor control applications.

The chances are, the problem in the opening post is easily solved by making the safety critical things happen in a highest-priority interrupt, and the UI code run in the main loop. Make the highest-priority interrupt unmaskable by modifying BASEPRI instead of turning interrupts on/off completely. But yes, this is just guesswork. It may be that XMOS is just the tool that the OP happens to need in this completely unspecified problem.

Or maybe the OP needs a bicycle, or a potato. We don't know.

[nctnico]

nctnico's silver bullet is never ever even considering multi-MCU.

Sorry but that is not true.

What I have seen many times is that novices tend to use multiple MCUs in order to make a project easier. At least they seem to think they do. The OP seems to be no exception to my observations. In a previous post in this thread I already outlined good and bad reasons to go for a multi-CPU solution (which you also re-iterated).