Split from: #define F_CPU and data types

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

Hi All,

 

I have an application where my transmitter is #define F_CPU 16000000UL and my receiver #define F_CPU 8000000UL.  Is this the normal transmitter receiver clocking for each boards micro-controller?  Or are these to match?

 

We are seeing an intermittent race condition which we are investigating between the transmitter and the receiver.

 

Thanks,

Marlon

Marlon E. Robinson

Last Edited: Wed. Nov 6, 2019 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Marlon,

we have no idea what boards your talking about, TX, RX???

try again, tell us what your trying to do and with what equipment, be specific, provide links to hw and or data sheets.

 

jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Please be aware of the following:

 

#define F_CPU does NOT control the MCU clock frequency. Instead it provides a number for the software so that the software "knows" what the CPU frequency is. 

 

This allows things like delay times and baud rates to be set correctly for the actual CPU clock rate. 

 

If there is F_CPU 16000000UL on one board and F_CPU 8000000UL on another board, there should be ONLY one reason for this difference. That reason is that one board has a 16MHz clock and the other has an 8MHz clock. 

 

A further side note since it looks like you are just starting. Asynchronous serial (also known as "UART") requires that the the two ends of the link have VERY close to the same baud rate. There can be no  more than a few percent difference between the two ends. This is NOT true for SPI or TWI/I2C. UART baud rate is counted down from the CPU clock. Thus, in order set the countdown value, the CPU clock frequency has to be known.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Nov 5, 2019 - 10:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You might want to say HOW the two micros are connected. Can we assume UART ?

 

But, yeah, my 16MHz AVR regularly talks to my 1.9GHz PC so, no, it's not unusual for two devices running at different speeds to communicate (and reliably).

 

The whole purpose of UART (assuming that is what we're talking about) is to get two ends to communicate at a common, agreed clock speed (often 9600 or 115,200 bits per second). How they derive that speed from 16MHz, 1.9GHz or 8MHz, etc is up to them. As long as it's fairly accurate (+/-2% at either end) then they should communicate reliably.

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

You originally tagged this onto a 4-year old thread:

 

https://www.avrfreaks.net/forum/define-fcpu-and-data-types

 

The moderators have split it off from that thread, as it really wasn't related to the question asked there.

 

reply #3 in that thread explained what F_CPU means:

I wrote:
it is the frequency at which the CPU operates; that is, the speed at which it executes instructions

 

So, as clawson says, there is no reason why different CPUs running at different speeds should not communicate successfully.

 

In fact, it will generally be the case that two communicating devices will not have the same CPU, and will not be operating at the same speed.

 

The important thing is that the interfaces are compatible - not that the CPUs are the same.

 

Imagine if every device connected to the internet had to have exactly the same CPU running at exactly the same speed - clearly, that would not be much use!

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

ka7ehk wrote:
it looks like you are just starting

Here is a good tutorial on Asynchronous (ie, UART) communications:

 

https://learn.sparkfun.com/tutorials/serial-communication/all

 

 

EDIT: fix quote

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. Nov 6, 2019 - 02:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Marlon Robinson wrote:
We are seeing an intermittent race condition which we are investigating between the transmitter and the receiver.

Others have assumed the UART is involved but go on; tell us what event or condition your transmitter and receiver are racing towards.

 

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

N.Winterbottom wrote:
Others have assumed the UART is involved
not entirely - this is why I asked...
clawson wrote:
You might want to say HOW the two micros are connected. Can we assume UART ?
and said:
clawson wrote:
UART (assuming that is what we're talking about)

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

N.Winterbottom wrote:
Others have assumed the UART is involved

I was quite careful to keep #5 generic - just talking about "communication" in general ...

 

 

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

Thanks Everyone for your feedback.  Will keep you posted as we progress.

Thanks again!

 

Marlon

Marlon E. Robinson

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

Would be helpful is you replied to the clarifications requested.

 

Are you talking about UART ?

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

After looking at the schematics etc ... the design doesn't use UART.

 

Marlon

Marlon E. Robinson

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

So what kind of interface is it?

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

RFC1149 perhaps? :)

 

Neil

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

barnacle wrote:
RFC1149

laugh

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

Ahhh, yes, the infamous RFC1149. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

RFC1149 - Oh of course . I should have guessed.

 

Marlon Robinson did say there was a RACE condition.