Mixing
Communicating between 2 different microcontrollers
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
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?
microcontroller avr communication
edited 19 mins ago
vaxquis
9361021
asked 12 hours ago
Anton Stafeyev
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
5
down vote
favorite
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?
microcontroller avr communication
edited 19 mins ago
vaxquis
9361021
asked 12 hours ago
Anton Stafeyev
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
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?
microcontroller avr communication
edited 19 mins ago
vaxquis
9361021
asked 12 hours ago
Anton Stafeyev
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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?
microcontroller avr communication
microcontroller avr communication
edited 19 mins ago
vaxquis
9361021
asked 12 hours ago
Anton Stafeyev
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 19 mins ago
vaxquis
9361021
asked 12 hours ago
Anton Stafeyev
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 19 mins ago
vaxquis
9361021
edited 19 mins ago
vaxquis
9361021
edited 19 mins ago
vaxquis
9361021
9361021
asked 12 hours ago
Anton Stafeyev
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 12 hours ago
Anton Stafeyev
334
asked 12 hours ago
Anton Stafeyev
334
334
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Anton Stafeyev is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
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.
- 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.
- 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.
- 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.
- 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.
- 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.
answered 5 hours ago
Maple
4,3702223
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
5 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
 |Â
show 3 more comments
up vote
5
down vote
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
- SPI
- I2C
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.
answered 11 hours ago
pipe
9,29931951
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
11 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
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
9 hours ago
 |Â
show 2 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
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.
- 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.
- 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.
- 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.
- 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.
- 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.
answered 5 hours ago
Maple
4,3702223
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
5 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
 |Â
show 3 more comments
up vote
3
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.
- 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.
- 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.
- 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.
- 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.
- 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.
answered 5 hours ago
Maple
4,3702223
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
5 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
 |Â
show 3 more comments
up vote
3
down vote
accepted
up vote
3
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.
- 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.
- 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.
- 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.
- 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.
- 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.
answered 5 hours ago
Maple
4,3702223
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.
- 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.
- 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.
- 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.
- 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.
- 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.
answered 5 hours ago
Maple
4,3702223
edited 5 hours ago
answered 5 hours ago
Maple
4,3702223
answered 5 hours ago
Maple
4,3702223
answered 5 hours ago
Maple
4,3702223
4,3702223
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
5 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
 |Â
show 3 more comments
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
5 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
5 hours ago
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
5 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
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
4 hours ago
 |Â
show 3 more comments
up vote
5
down vote
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
- SPI
- I2C
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.
answered 11 hours ago
pipe
9,29931951
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
11 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
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
9 hours ago
 |Â
show 2 more comments
up vote
5
down vote
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
- SPI
- I2C
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.
answered 11 hours ago
pipe
9,29931951
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
11 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
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
9 hours ago
 |Â
show 2 more comments
up vote
5
down vote
up vote
5
down vote
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
- SPI
- I2C
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.
answered 11 hours ago
pipe
9,29931951
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
- SPI
- I2C
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.
answered 11 hours ago
pipe
9,29931951
edited 10 hours ago
answered 11 hours ago
pipe
9,29931951
answered 11 hours ago
pipe
9,29931951
answered 11 hours ago
pipe
9,29931951
9,29931951
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
11 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
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
9 hours ago
 |Â
show 2 more comments
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
11 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
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
9 hours ago
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
11 hours ago
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
11 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
@AntonStafeyev I hope my recent edit to the answer helped with your question, otherwise just ask me to clarify again!
– pipe
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
As SPI bidirectional is in reality a circular buffer, it is indeed quite simple to implement.
– Peter Smith
10 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
Just make sure your clock/sample edge polarities match on the two devices.
– isdi
9 hours ago
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
9 hours ago
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
9 hours ago
 |Â
show 2 more comments
Anton Stafeyev is a new contributor. Be nice, and check out our Code of Conduct.
Anton Stafeyev is a new contributor. Be nice, and check out our Code of Conduct.
Anton Stafeyev is a new contributor. Be nice, and check out our Code of Conduct.
Anton Stafeyev is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f402400%2fcommunicating-between-2-different-microcontrollers%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password