Snchronyzing Clocks : Communicating between machines ...

So, I know (at least think I know) that a baud rate, synchronizes the rate at which bits'n'bytes are sent across a serial connection, or RF24, or ... flavor of your choosing.

But here I'm wondering more about the clock of each machine in the process and how often it initiates a 'send'.
E.g.
I have an app on my PC which responds to mouse movements.
Pc then sends the relevant values via serial USB to my Uno
Uno then sends the values to my MEGA via RF24
MEGA uses the values to drive servos on my bot.

What I am thinking, is that my PC's processor runs at 2.4GHz
My Uno controller runs at 16MHz

So am I right in thinking that unless managed, my PC will be sending faaaar more data across the serial, than the Uno could ever hope to process. (Sorry - 'control').

I certainly know that in the Uno's receiving code, I have to empty out the buffer or things get messy.
The above 'takes care' of surplus data, but in my mind, it's rather 'messy' and inefficient to send quite so much extra data than is ever needed.

Looking into the future, I might introduce a Due into the process, and this runs at 84MHz.
This would mean I have 2.4Ghz, a 16MHz and a 84MHz machines, all spewing and eating packets at different rates.

Hence I was looking for a better way to manage this.
Being a little inexperienced, I am thinking ..

Throw some delays in the Host's code to slow down the send rate. (not too much, or there will be delays !)
Get the Host to wait for an acknowledgement from 1 send, before sending the next. (will have to test if this slows things down )

I guess I'm here now, just to ask if there is a standard way of addressing this issue, or whether we should not worry and simply 'bin' the surplus .... am I reinventing the wheel ?

Any thoughts, suggestions, pointers - greatly received !

Many Thanks
Simon

what baud rate are you using for the RF link?

You're talking about asynchronous serial communication (RS232-like). There you have a preset baud rate. Although the PC has a processor running at 2.4GHz, a baud rate of 57600 is still 57600 bits per second. For the PC this is extremely slow, for the UNO it's quite slow, for the Due it's very slow. All of them use exactly the same speed, if they don't no communication will happen. So you don't have to worry about this. It might getting a bit of a problem if you use SoftwareSerial (because there all the work is done using normal instructions, so the processor has to be much faster than the communication speed) but with the hardware USART you're fine with the usual baud rates.

Ok,

Thanks for the replies ... but they also make me think that I have not explained my issue clearly enough.

It is not the individual transmissions that I am concerned with.
I am happy with the individual act of a device writing to serial/rf at a baud rate, and another device reading the bytes at the same speed.

It is how often these transmissions are sent.

I'll try explain this way ....

Begin Loop
Send Bytes // Host Code
Receive Bytes // Client Code
End loop

If I the transmitting host is at 64MHz, and the receiving client is running at 32Mhz,
then 200 bytes will be sent out, and only 100 read in the same time period.

As far as I know, this it to do with processor/controller clock speeds and how fast lines of code are executed.
.... and not baud rate of the individual transmissions.

Let's take an example: 9600 baud. That's 960 bytes per second. So one host is sending data with a speed of max. 960 bytes per second. If the receiving host is able to process all the 960 bytes coming in that one second it's find no matter how fast the processor speed of the sending or receiving host is. The PC cannot send more than these 960 bytes because the baud rate doesn't allow that although theoretically the PC could have done much more.

Ahh ... so I think I need to apologize to the previous posters too .. the penny drops now.

So because the baud rate is the slowest part of the process, the code loop cannot execute any faster than the baud rate ?

I do feel so stupid now .. obvious now I think about it.

Thank you for your patience - can we put it down to a long day ?

:wink:

can we put it down to a long day ?

join the club :slight_smile: