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 .
what is the best communication mode between two MCU likw wise i2c or SPI or RS232 (using txD & RXD ) .
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:
Edit
speed; bus?
edit 2
distance; topology
[1] insert preferred politically-correct terms here.
Add to that
I did.
EDIT
and that's without even considering parallel options:
https://en.wikipedia.org/wiki/Se...
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
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:
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" ?
assign a weighting factor to each item. Then score each candidate solution against that
an excellent approach.
why you've decided to separate out the functions into two devices?
Is a very good question
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.
what is the best communication mode between two MCU
Infra-Red
1, two controllers are in same board .
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" ;-)
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
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:
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.)
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
This sounds more like a school project focused on multi-processor comms!
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.
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?
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.
Important question: will there EVER be more than the two devices on the bus?
Jim
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.
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.
In case of surprises, tapping into the communicationchannel can help determine which processor got it wrong.
ah - there's another one for the list:
And so the mad OP has disappeared without defining the characteristics of his definition of "best". Personally, I prefer the colour blue.
But which blue is best ?
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.
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)
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
If you want complexity, cost-inefficiency, reliability, high speed, low latency, only 4 wires and experience a terrible headache, I'd suggest USB! 
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 ... ?
So, as this is about chips on the same board, you'd only need 2 ... ?
Right. Just like I2C.
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.
If you want complexity, cost-inefficiency, ...
USB software doesn't have to be complex if willing to reduce scope (class-less)
... and experience a terrible headache, I'd suggest USB!
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
all we need is for him to come back & say what he's decided ...
Wow, madhavanatmel certainly got his money's worth in this thread! One post, 30 replies.
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.
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.
skeeve wrote:
To me, that would mean the UART.
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...
OP wants master-slave,
We're not doing 'Master/Slave' anymore. Instead, we should use 'Early Bird / worm'. Thank you. 
S.
skeeve wrote:OP wants master-slave,
We're not doing 'Master/Slave' anymore. Instead, we should use 'Early Bird / worm'. Thank you.
Edit: tipo
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
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.
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.
