"Best" connection between two micros

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi, what is the best communication mode between two MCU  likw wise  i2c or SPI or RS232 (using txD & RXD ) . 

the current project plan to have two controller the first controller going to act nconsole and 2nd controller going act as driving some device .

Last Edited: Wed. Sep 23, 2020 - 10:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

madhavanatmel wrote:
what is the best communication mode between two MCU  likw wise  i2c or SPI or RS232 (using txD & RXD ) . 
if there was a "best" everyone would be using it !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As clawson says, if there were one "best" mode - then everyone would be using it!

 

As always in engineering, it's a trade-off; there are pros & cons to everything.

 

Consider:

 

  • Number of wires
  • Complexity of protocols
  • Complexity of hardware
  • Speed/throughput capabilities
  • Do you need a "bus", or just a simple point-to-point
  • Required distance: are the micros on the same board? in the same cabinet? in the same room? other?
  • Do you want peer-to-peer, or master/slave[1]
  • Your experience
  • Cost
  • Availability of compatible parts
  • etc, etc, ...

 

Edit

 

speed; bus?

 

edit 2

 

distance; topology

 

[1] insert preferred politically-correct terms here.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Sep 23, 2020 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Add to that

  • Speed

 

;-) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Add to that

I did.

 

wink

 

EDIT

 

and that's without even considering parallel options:

 

https://en.wikipedia.org/wiki/Se...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Sep 23, 2020 - 10:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the following requirement is my plan.

 

1, two controllers are in same board .

2. first controller like console Display and other sensor, second controller going to control stepper motor.

3. like to be master /slave 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Take awneil's list from post #3 and assign a weighting factor to each item. Then score each candidate solution against that. You have already refined that list slightly, so that leaves:

 

  • Number of wires 
  • Complexity of protocols
  • Complexity of hardware
  • Speed/throughput capabilities
  • Do you need a "bus", or just a simple point-to-point - A: point-to-point
  • Required distance: are the micros on the same board? in the same cabinet? in the same room? other? A: same board
  • Do you want peer-to-peer, or master/slave ? A: master/slave
  • Your experience
  • Cost
  • Availability of compatible parts

 

For example, I2C uses fewer wires/signals/pins than SPI but is generally slower. How does that score with your weighting factors for items 1 and 4 ? (and maybe 2 and 3 as well)

 

I'd also ask why you've decided to separate out the functions into two devices. There may be good reasons, but it does add significant complexity.

 

Have you decided on the application-level protocol yet ? Is it more like "button A has been pressed" or "stop motor" ?

Last Edited: Wed. Sep 23, 2020 - 11:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
assign a weighting factor to each item. Then score each candidate solution against that

an excellent approach.

 

obdevel wrote:
why you've decided to separate out the functions into two devices?

Is a very good question

 

madhavanatmel wrote:
first controller like console Display and other sensor, second controller going to control stepper motor.

Having one controller as the "user interface", and one to do the "real work" could be quite a good split; especially if you base the "user interface" part on something like a Raspberry Pi - which would make it easy to do a very nice graphical interface.

 

Not sure that it makes sense to have the "sensors" as part of the UI, though: what sensors are they, and what are they doing? Wouldn't they be better in the "real work" part.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

madhavanatmel wrote:
what is the best communication mode between two MCU

Infra-Red

 

Last Edited: Wed. Sep 23, 2020 - 12:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

madhavanatmel wrote:
1, two controllers are in same board .
The usual reason to split work between controllers (then face the issues of comms, synchronisation, keeping firmware versions in step, etc etc) is because you have to split the work over two boards that are positioned some distance apart. If everything is on one board then it is almost never a good idea ot have two controllers - just get "one big one" that can handle doing everything. The there's no comms link, no comms prototocl, no synch issues, no firmware matching/updating issues, etc etc.

 

So I'd take a step back and take a very hard look at whether you really want to split things and what your motives are for that - don't think it "makes things easier" ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Add also to Neils list "amount of data to be send"  and in what timeframe... effectively giving you the speed of the bus.

 

Than as said if they are on the same PCB just go for 1 processor that can do the job, or you need a really good reason to split work. Getting multiple CPUs to work together flawlesly might be a big PIA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It might help us to help you if you defined the overall problem to be solved rather than give us tidbits of your approach (i.e. two separate processors)  to solve the problem.

 

Edit:

madhavanatmel wrote:
the following requirement is my plan.

What you seem to be stating is that your plan is the requirement...

 

(That seems to be putting the cart before the horse.)

 

David

Last Edited: Wed. Sep 23, 2020 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There are a few arguments in favour of 'separation of concerns', e.g.

 

- if the motor driver is a safety-critical system, the architecture should be as simple as possible, and not cluttered with code to manage buttons, indicators and displays

- dev teams can work in parallel, specialising with different skill sets

- dependencies between the two teams can be reduced, e.g. each team can work with mock-ups of the other system, at least until system integration testing

- the console can be replaced in the future by an alternative or 'better' solution, as long as it implements the same protocol

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

This sounds more like a school project focused on multi-processor comms!

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW I personally favour SPI but that's probably because I'm a simpleton and like things easy !! ;-)

 

(things generally don't come any easier than SPI).

 

Actually, thinking back, I once did a "split" design in this:

 

 

 

From the late 90's that has a 10 line LCD display which was a catalogue for the 60 CDs it contained (yup, folks, the world's first iPod only with real CDs and an auto-changer!!). The main board had a 16bit M16C processor but the front display (which hinged down to allow insertion/extraction of CDs) had some kind of ST7 (think it was) 8 bit micro. as it was "audio" (but only in the Amstrad sense of the word audio!) then we didn't want a lot of electrical noise from the link between the main CPU and the display so we went for 3 wire synchronous serial (in shielded cabling). So while I would always advocate for one CPU when you can, this was an occasion we broke the rule and split things. But it was containable/do-able in this case as the "slave" micro (am I allowed to say that?) only really has one job and that was display and buttons and pretty much nothing else to do.

 

(it actually made writing the simulator we always used in developments easier as it was really just simulating all the UI functions of the 8 bit micro).

EDIT: found a second picture which reminds me the front panel micro was also driving a VFD too.

Last Edited: Wed. Sep 23, 2020 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also add:  Why do you want to exponentially increase complexity, along with cost and space and power, just to drive a simple stepper that an AVR can do in its sleep?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm going to throw in a vote for async UARTs, at least up through "moderate" speeds (2Mbps?)

Because they seem to be more likely to have FIFOs, increasing allowable latency of service and/or system-level performance.

There were several threads recently in several forums on the difficulty of achieving good SPI slave performance on most microcontorllers :-(

Haven't seen any 60MHz UART interfaces to flash chips or displays, though.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Important question: will there EVER be more than the two devices on the bus?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP's original post stated two MCUs,

so I'd infer point to point.

 

Having two processors on the same board might be useful as an organizational tool.

E.g. one processor might communicate with the human, the other with the dam.

The first decides what to do. The other knows how to do it.

In case of surprises, tapping into the communication

channel can help determine which processor got it wrong.

Admittedly one can get much the same effect in a single chip.

Two rubs: knowing one has done it correctly and tapping the channel.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a board in production that has seven AVRs on it. 

 

The reason why is because there are six channels of inbound information, and they have to react to it fast.  The seventh AVR collects their information and ships it onward.

 

The interface bus is eight-bit parallel with control lines, if that helps any.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
In case of surprises, tapping into the communication

channel can help determine which processor got it wrong.

ah - there's another one for the list:

 

  • Ease of test/debug

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And so the mad OP has disappeared without defining the characteristics of his definition of "best". Personally, I prefer the colour blue.

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


But which blue is best ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


My friend worked for Best for a while, but best went out of business.  

Nothing better has come along since.

 

 

 

Best filed twice for Chapter 11 bankruptcy protection. The first bankruptcy period began in January 1991 and lasted through June 16, 1994. The second and final filing was made on September 24, 1996. At the time of the second filing, Best operated 169 Best stores and 11 Best Jewelry stores in 23 states, and a nationwide mail-order service.

Best Products was traded on the NASDAQ exchange as "BESTQ." It was de-listed on November 29, 1996, and Best did not appeal the NASDAQ decision. The last Best stores closed on February 9, 1997.[5][6][7][8] By May 1997, Best had liquidated most of its assets and was declared insolvent. Best vacated its corporate headquarters in Richmond in January 1998 

 

I got a nice wall of stockroom shelving for a few bucks & a 100 CD Cd player super cheap (which I have yet to use)--they had a huge amount to dispose of.  

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One way of doing this, without using actual "communications" is a register or something like dual port RAM.   CPU one writes to said register and tells CPU what it needs to know, and CPU two reads it and replies back to CPU one.  If bus contention is an issue (both reading/writing at the same time), you can use a dual port scheme or even a dual port RAM.   After all, they're on the same board.

 

Just a suggestion.   It's fast too.  (note, I didn't say easy, but not all that hard depending on requirements)

 

 

Just gettin' started, again....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dual port ram isn't quite the magic bullet you might think it is - what happens when one side writes and the other side reads or writes the same location at the same time? Flip a coin as to what gets stored or read out. Dual port ram isn't something you see on a board much these days - usually hidden in fpgas

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want complexity, cost-inefficiency, reliability, high speed, low latency, only 4 wires and experience a terrible headache, I'd suggest USB! laugh

Slow and Steady!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pajuhesh80 wrote:
 only 4 wires 

aren't 2 of them for +5V and GND ?

 

So, as this is about chips on the same board, you'd only need 2 ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

So, as this is about chips on the same board, you'd only need 2 ... ?

Right. Just like I2C.

Slow and Steady!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

dual port ram isn't quite the magic bullet you might think it is - what happens when one side writes and the other side reads or writes the same location at the same time? Flip a coin as to what gets stored or read out. Dual port ram isn't something you see on a board much these days - usually hidden in fpgas

 

 

 

Correct, that's why I mentioned the bus contention issue.   And registers instead of actual dual port RAM, assuming the OP didn't need to read/write lots of data.

 

But setting up something like a 8 bit port with ready/and strobe would work fairly well.   CPU writes data to the register/port, then sets the strobe line, which interrupts (or the other CPU is polling).   CPU reads byte, clears the strobe and writes its own byte and sets the ready bit.

 

I did that some when working with the Z80 (PIO) and the AL0256 speech chip.  The only difference is the speech chip didn't write back any data.

 

 

Just an option, I'm thinking why serialize the data if you don't have to.

Just gettin' started, again....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pajuhesh80 wrote:
If you want complexity, cost-inefficiency, ...
Indeed for USB full-speed akin to an Ethernet MAC; the price of either can exceed a limit (MCU die area)

USB software doesn't have to be complex if willing to reduce scope (class-less)

pajuhesh80 wrote:
... and experience a terrible headache, I'd suggest USB! laugh
Some effort to get USB complete, precise, and correct though on completion one can reuse their creation.

There are automotive and industrial use cases for USB.

 


https://github.com/rrevans/ubaboot/blob/master/ubaboot.S#L411

in GitHub - rrevans/ubaboot: USB bootloader for atmega32u4 in 512 bytes

 

approximately 1000 SLOC though one can likely grok it :

C code for Teensy: USB Raw HID - for building custom USB devices

 

USB Protocol Analyser | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, madhavanatmel certainly got his money's worth in this thread! One post, 30 replies. surprise

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

all we need is for him to come back & say what he's decided ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Wow, madhavanatmel certainly got his money's worth in this thread! One post, 30 replies. surprise
3 posts and 29 replies at the time of clawson's writing.

 

OP wants master-slave,

Given OP's list of choices,

methinks he would rather not add chips.

 

If the issue is responding to human input,

reliability of coding would seem to be the main issue.

To me, that would mean the UART.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

skeeve wrote:

To me, that would mean the UART.

 

Makes it easy to mock up the other end too; just use a terminal. Almost all my projects have a text command interface, even if it's only single characters. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

To me, that would mean the UART.

obdevel wrote:
Makes it easy to mock up the other end too; just use a terminal. 

Indeed.

 

That's what I had in mind with #22

 

See also: https://www.avrfreaks.net/commen...

 

And: https://www.avrfreaks.net/commen...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

OP wants master-slave,

 

We're not doing 'Master/Slave' anymore.  Instead, we should use 'Early Bird / worm'.  Thank you.  cheeky  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
skeeve wrote:

OP wants master-slave,

 

We're not doing 'Master/Slave' anymore.  Instead, we should use 'Early Bird / worm'.  Thank you.  cheeky  S.

That would seem a rather temporary relationship.

 

Edit: tipo

Iluvatar is the better part of Valar.

Last Edited: Sun. Oct 4, 2020 - 11:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It occurs to me that there's a simple answer to the OP's original question. The best connection between two micros is the one that works... that meets the timing, accuracy, software limits, power, and latency requirements.

 

Once those are defined - or at least roughed out - then and only then can you start making an intelligent decision. Many of us old timers would jump on a UART just from habit, but as posters upthread have pointed out, there are many other options.

 

Neil

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
It occurs to me that there's a simple answer to the OP's original question. The best connection between two micros is the one that works... that meets the timing, accuracy, software limits, power, and latency requirements.
Also the ease with which one can get it right and the ease with which one can tell if one gets it wrong.
Quote:
Once those are defined - or at least roughed out - then and only then can you start making an intelligent decision. Many of us old timers would jump on a UART just from habit, but as posters upthread have pointed out, there are many other options.
Admittedly it was only a hint, but OP did hint that the channel would only be required to operate at something resembling human speeds.

As the UART can do a Mbps with a latency of a few microseconds, it would seem the likely choice.

Neither SPI nor I2C is going to do much better.

If the UART is not sufficient, OP might have to bit-bang something involving whole ports.

Iluvatar is the better part of Valar.