My Arduino runs at 16MHz clock speed; another microcontroller runs at clock speed of 13MHz. If I send digital output directly from an output pin of the former to input pin of the latter, there will be a loss of data and the transmission will be corrupted.

Question 1: How do I get the MCUs to properly transmit the data without any corruption? Do I need to sync them somehow, or I should use another device in middle as some kind of a buffer (or maybe to send data at a lower rate)?

Question 2: If I can send data at a lower rate from MCU#1 to MCU#2 will there be a phasing difference which would result in data corruption?

up vote 5 down vote accepted

The points you make are absolutely valid. What you missing are some details that you could get by reading more on communication protocols. Here are some of them.

  1. The communication speed should always be chosen from the maximum required speed, not the one that can be achieved.

The reason for this is that with some exceptions (transceivers, buffers etc.) the data transferred must be either obtained or processed somehow. Input from human interface certainly works in completely different time dimension. And if your controller takes several seconds to process 1 MB of data, it would be pointless to transfer it at 16 Mbps speed.

  1. Because signal-to-noise ratio decreases with distance, the maximum achievable bandwidth decreases too.

There is term "bandwidth-distance product" often used in communication. This is another reason why direct MCU-to-MCU connections rarely use that high data rates.

  1. In modern MCUs the communication speeds are often independent from the CPU clocks.

For example, Xmega MCUs have peripheral clocks running at 2 or even 4 times the CPU speeds. Furthermore, controllers with USB interfaces often have their own oscillators.

  1. Various communication protocols are now supported in hardware.

Synchronous protocols like SPI (or I2C on slave side) have their clock signals coming from the different MCU. So, the hardware can use that clock to shift data to/from the buffer and only involve processor at the end of a message. More advanced MCUs with DMA support can even move the data between different peripherals or memory without involving CPU at all.

Asynchronous protocols like UART or CAN require synchronized clocks. They begin timing at start bit and then sample the inputs once approximately at the mid-clock point (UART) or up to three times at about 75% of clock pulse (CAN). Obviously the data integrity depends on the clocking precision. While CAN controllers can adjust their clocks using phase shift information, more simpler UARTs can not.

One common practice to achieve better UART synchronization is to use crystals with frequencies easily divisible to common serial baud rates. For example, instead of running aforementioned Xmega controllers at their maximum 32 MHz you can often see them with 14.7456 crystals, running at 29.5 MHz.

Regardless of the protocol, the combination of hardware buffering and DMA transfers make transfer bandwidth fairly independent from CPU clocks.

  1. Finally, when communication speeds go up it is more common to see separate controller chips rather than direct connection to MCU.

Not only that, but you can usually see parallel bus connection between MCU and high-speed transceivers like LAN or LVDS display. This is because the communication bus throughput becomes faster than can be passed in serial trough single MCU pin.

You've mentioned Ethernet in one of your comments. You should realize that with 1 Gbps Ethernet speeds no 16 MHz MCU stands a chance of processing that avalanche of traffic. For those speeds you should be looking at much more capable hardware, like used in RPi, for example.

By the way, this last point is just another form of point #1, i.e. if you cannot reduce data rate to something your MCU can handle, it logically follows that you need faster processor to deal with data flow.

  • Man thanks for the answer. that does help a lot. but as usual 1 answer creates thousand questions. and i guess few of them can be answered right on the spot. since you have said that MCU simply wont have enough speed to process the data that comes from another end, what would be a solution in general if i would like to send my sensor data to the remote server. i don't really need to receive anything back. and since it is a remote server, i would prefer HTTP as a final layer of all protocols used. or even could be UDP stream of data. – Anton Stafeyev Oct 21 at 19:55
  • Well, that's easy. Any sensor has its own data acquisition rate(s). The precision often depends on this rate, so it is common to run them slower than possible to achieve better precision. On the other hand you have a server, which also has maximum data rate defined by protocol and server capability. Not only that, but the server's availability changes with load i.e. number of concurrent requests it has to process. Figure out maximum desirable data rate of a sensor and maximum available data rate of a server at maximum load. The lesser of the two would be your target data rate. – Maple Oct 21 at 20:08
  • Since you've mentioned HTTP/UDP, I must point out that your entire question Is invalid. You are not just communicating between two MCUs. You are communicating over known transfer channel, which requires quite high data rates to handle protocol overhead. Regardless of the acquisition data rate your controller has to handle packet envelopes and basically entire TCP/IP stack. My advice would be to use some of the modules with built-in ethernet/wifi controllers and all required software for that. The reading of the sensor itself would be the lesser of your problems. – Maple Oct 21 at 20:19
  • well thats the point. a module with wifi or ethernet talks over SPI to the MCU. and that process is rising so many questions that i want to nail every single bit going in and out :) all i was asking is the direction and you guys gave it to me:) – Anton Stafeyev Oct 21 at 20:30
  • on practice i now i know that mcu wont be able to write at the speed ethernet requires, so if i would use something like micro-processor like arm cortex and implent the whole networking there. i would still need to talk over spi to my tiny mcu. so that was the seed of the question. – Anton Stafeyev Oct 21 at 20:35

You're quite right in your analysis of the problem, and it is of course solved.

The solution is a serial protocol of your choice. A microcontroller will usually have one or more of the common inter-IC communication protocols:

UART is "clockless" so each side has to decide on a clock speed. The speed is low enough that each receiver can find the right bits and solves the "phase" problem by inserting extra bits that will always be low or high adjacent to a bit of the opposite polarity.

SPI and I2C has a clock in addition to the data. The receiver will only act on the data when the clock changes. Usually the hardware takes care of everything. I2C has a standardized clock speed limit, while SPI has no such limit.

Among these, SPI is arguably the easiest to implement in discrete hardware. It is essentially no more than a shift register, and it can interface directly with a number of cheap and common logic chips. There is also no lower speed limit, and jitter is not an issue since it is driven purely by the clock so it is easy to implement in software on a slow processor.

  • i will look at how this protocols are made and how hardware handles them. big thanks. but what if i need to communicate with a device i made my self that has no built in solutions. how would i solve phasing problems. anmd clocks – Anton Stafeyev Oct 21 at 13:23
  • @AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again! – pipe Oct 21 at 14:19
  • As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement. – Peter Smith Oct 21 at 14:31
  • Just make sure your clock/sample edge polarities match on the two devices. – isdi Oct 21 at 15:33
  • just to make sure i am on the right track. for example i want to make a chip that will send data over tcp protocol. i will connect that chip to arduino via SPI protocol the, Ethernet device will receive data -> store it in buffer and then send packet over Ethernet to a pc for example. this is my short term goal for now. – Anton Stafeyev Oct 21 at 15:36

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.