"Better" method to load UBBRL suggestions...

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

Greets Freaks!

 

I have a little project where I am sending out a block  of bytes from the USART at different baud rates. 

 

For example:

 

I send out 10 bytes at 2400

 

then I set the UBBRL to the value needed for 4800

 

I send out 10 bytes at 4800

 

then I set the UBBRL to the value needed for 9600

 

I send out 10 bytes at 9600

 

then I set the UBBRL to the value needed for 19200

 

etc... all the way up to 115.2k

 

One way I was thinking was to set up a function for sending the bytes, and then in main a statement for each baud rate setting followed by a call to the send function

 

Example:

//BAUD RATE DEFINES
//values for various baud rates to be placed in UBBRL
//these values will give 0% error with 7.3732Mhz crystal
//2400 to 230.4K
#define BAUD2400	191
#define BAUD4800	95
#define BAUD9600	47
#define BAUD1440	31
#define BAUD1920	23
#define BAUD2880	15
#define BAUD5760	11
#define BAUD7680	7
#define BAUD1152	3
#define BAUD2304	1

#define DATA_REGISTER_EMPTY (1<<UDRE0)
#define RX_COMPLETE (1<<RXC0)
#define FRAMING_ERROR (1<<FE0)
#define PARITY_ERROR (1<<UPE0)
#define DATA_OVERRUN (1<<DOR0)


void send_stuff(void)
{
    uint8_t byte = 0x30;  //magic number...HEX value for ASCII number '0'
    
    for(uint8_t i = 0;i <= 9; i++)
    {
        while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
	    UDR1 = byte;
	    byte++;  //increment byte by one

    }
}

int main(void)
{
    UBBR1L = BAUD2400;  //load baud rate with value for 2400
    send_stuff();   //go send stuff!
    
    UBBR1L = BAUD4800;  //load baud rate for 4800
    send_stuff();
    
    .
    .
    .
    . //and so on
}

 

In theory this could work, but to me looks inefficient.  Another idea using the same base code could be:

//BAUD RATE DEFINES
//values for various baud rates to be placed in UBBRL
//these values will give 0% error with 7.3732Mhz crystal
//2400 to 230.4K
#define BAUD2400	191
#define BAUD4800	95
#define BAUD9600	47
#define BAUD1440	31
#define BAUD1920	23
#define BAUD2880	15
#define BAUD5760	11
#define BAUD7680	7
#define BAUD1152	3
#define BAUD2304	1

#define DATA_REGISTER_EMPTY (1<<UDRE0)
#define RX_COMPLETE (1<<RXC0)
#define FRAMING_ERROR (1<<FE0)
#define PARITY_ERROR (1<<UPE0)
#define DATA_OVERRUN (1<<DOR0)


void send_stuff(BAUD_RATE)
{
     UBBR1L = BAUD_RATE;  //load baud rate with value for desired speed
     _delay_ms(10);  //let USART configure
     
    uint8_t byte = 0x30;  //magic number...HEX value for ASCII number '0'
    
    for(uint8_t i = 0;i <= 9; i++)
    {
        while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
	    UDR1 = byte;
	    byte++;  //increment byte by one

    }
}

int main(void)
{
   
    send_stuff(BAUD2400);   //go send stuff!
    
  
    send_stuff(BAUD4800);
    
    .
    .
    .
    . //and so on
}

This is certainly a bigger improvement but I think this might be the best one I can come up with:

uint8_t BAUD_RATE = {191, 95, 47, 31, 23, 15, 11, 7, 3 , 1};

#define DATA_REGISTER_EMPTY (1<<UDRE0) 
#define RX_COMPLETE (1<<RXC0) 
#define FRAMING_ERROR (1<<FE0) 
#define PARITY_ERROR (1<<UPE0) 
#define DATA_OVERRUN (1<<DOR0)


void send_stuff(void)
{
    for(uint8_t BAUD_SELECT = 0; BAUD_SELECT <= 9; BAUD_SELECT++)
    {
        UBBR1L = BAUD_RATE[BAUD_SELECT];  //load baud rate with value for desired speed
       _delay_ms(10);  //let USART configure
     
         uint8_t byte = 0x30;  //magic number...HEX value for ASCII number '0'
    
            for(uint8_t i = 0;i <= 9; i++)
            {
                while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
        	    UDR1 = byte;
        	    byte++;  //increment byte by one
        
            }
    }
}


int main(void)
{
    send_stuff();
    
        while(1){}
        
}

As all the baud rates are cycled through in the one function inside the first for() loop, and the ten bytes are sent in the second for() loop.

 

My other thought would be to store the baud rates in FLASH and retrieve them from FLASH, but not sure if there is any benefit over option #3 above....

 

Looking for suggestions....

 

Thanks

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I wouldn't bother with flash until its needed. Doesn't look like its needed, so no need to optimize when 99% ram goes unused.

 

The first two I would not use, a variation of last one which is the better one-

https://godbolt.org/z/EJ5M3a

 

better (I messed up the txc, need 1 byte out before that is valid)-

https://godbolt.org/z/JpFGdV

 

 

I would rather split up into functions that do specific jobs, even for simple apps. The wanted string of chars may change, if so its already handled. More baud rates, handled. Other tx needs, handled.

Last Edited: Sat. Nov 23, 2019 - 03:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@curtvm

I like that.  Even more compact.  Although I do not intend on changing the bytes, I like the idea.  Food for thought

 

For those who do not want to click on the link:

#include <avr/io.h>

uint8_t BAUD_RATES[] = {191, 95, 47, 31, 23, 15, 11, 7, 3, 1};
char SEND_DATA[] = "0123456789";

void U1tx(uint8_t v){
    while ( (UCSR1A & (1<<UDRE1)) == 0 );
    UDR1 = v;
    UCSR1A |= 1<<TXC1; //clear txc flag
}
void U1baud(uint8_t v){
    while( (UCSR1A & (1<<TXC1)) == 0 ); //wait for txc
    UBRR1L = v;
}
void U1puts(char* str){
    while(*str) U1tx(*str++);
}
int main(void){
    for(uint8_t i = 0; i < sizeof(BAUD_RATES); i++){
        U1baud(BAUD_RATES[i]);
        U1puts(SEND_DATA);
    }
    for(;;){}
}

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

See my post edit- I messed up the txc- it would wait forever for txc when setting baud first time.

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

I'd suggest putting a delay after changing the baud rate to ensure the baud rate divider has completed a cycle - this was done in the original code. 

 

Stylistic suggestion - don't have the array names in uppercase - this suggests a #define. MISRA would have a suggestion or two.

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

DONE!

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

DONE BETTER.

 

Keep your original names for the array of Magic Numbers.

Now when you come back to this code in a few weeks time it's clearer why uint8_t BaudRates[] contains such low numbers; and what they relate to.

 

#include <avr/io.h>

//BAUD RATE DEFINES
//values for various baud rates to be placed in UBBRL
//these values will give 0% error with 7.3732Mhz crystal
//2400 to 230.4K

#define BAUD2400	191
#define BAUD4800	95
#define BAUD9600	47
#define BAUD1440	31
#define BAUD1920	23
#define BAUD2880	15
#define BAUD5760	11
#define BAUD7680	7
#define BAUD1152	3
#define BAUD2304	1

#define NR_BAUDRATES (sizeof BaudRates / sizeof (*BaudRates))
const uint8_t BaudRates[] = {
    BAUD2400, BAUD4800, BAUD9600, BAUD1440, BAUD1920,
    BAUD2880, BAUD5760, BAUD7680, BAUD1152, BAUD2304};

const char SendData[] = "0123456789";

void U1tx(uint8_t v){
    while ( (UCSR1A & (1<<UDRE1)) == 0 );
    UDR1 = v;
    UCSR1A |= 1<<TXC1; //clear txc flag
}
bool U1txc(){
    return UCSR1A & (1<<TXC1);
}
void U1baud(uint8_t v){
    UBRR1L = v;
}
void U1puts(const char* str){
    while(*str) U1tx(*str++);
}
int main(void){
    //init stuff

    for(uint8_t i = 0; i < NR_BAUDRATES); i++){
        U1baud(BaudRates[i]);
        U1puts(SendData);
        while( U1txc() == false );
    }

    for(;;){}
}

 

Obviously you'll consider using __flash where appropriate.

 

Last Edited: Sat. Nov 23, 2019 - 09:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then you may as well go to the next step-

 

#define F_CPU 7373200ul

#define MKBAUD(v) (F_CPU/v/16 -1)

 

const uint8_t BaudRates[] = {

  MKBAUD(2400),  MKBAUD(4800),   MKBAUD(9600),

  MKBAUD(14400), MKBAUD(19200),  MKBAUD(28800),

  MKBAUD(57600), MKBAUD(115200), MKBAUD(230400)

};

 

There is never an end to improving code, but eventually you have to put something in the mcu. Working out improvements in simple code is good practice that does pay off later, though.

 

>I'd suggest putting a delay after changing the baud rate to ensure the baud rate divider has completed a cycle - this was done in the original code. 

 

I'm not sure I follow. The code waits for txc before changing baud so there is no ongoing transmission, and writing to ubrr loads the new value into the down counter. Maybe I'm missing something.

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

I didn't write this it was

Kartman wrote:

I'd suggest putting a delay after changing the baud rate to ensure the baud rate divider has completed a cycle - this was done in the original code. 

I say that's unnecessary because I found this in the mega328 datasheet and it’s likely to be identical for all AVR USART,

• Bit 11:0 – UBRR[11:0]: USART Baud Rate Register
This is a 12-bit register which contains the USART baud rate. The UBRRnH contains the four most significant bits,
and the UBRRnL contains the eight least significant bits of the USART baud rate. Ongoing transmissions by the
Transmitter and Receiver will be corrupted if the baud rate is changed. Writing UBRRnL will trigger an immediate
update of the baud rate prescaler
.

{My emphasis}

 

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

I won't argue with that!

 

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

I did something similar in a project, but instead of precalculated magic numbers, I used a formula:

 

#define BAUD(rate) (uint8_t) (F_CPU/(rate*16.0) - 0.5)

So the array would be:

 

const uint8_t BaudRates[] = {
    BAUD(2400), BAUD(4800), BAUD(9600), BAUD(14400), BAUD(19200),
    BAUD(28800), BAUD(57600), BAUD(76800), BAUD(115200), BAUD(230400)};
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There really are no magic numbers per se. The numbers come right from the datasheet and are defined rather than just dropped into the application.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:

                while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
        	    UDR1 = byte;
        	    byte++;  //increment byte by one

Spurious indent?  "Help" from IDE or text editor?

I generally use {} for an empty body.

As I do not have spurious braces,

I would know that the indent was spurious.

Iluvatar is the better part of Valar.

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

skeeve wrote:
I generally use {} for an empty body.

So do I, but this was  a quick throw together, and the CV wizard that generated the:

 while ((UCSR1A & DATA_REGISTER_EMPTY)==0);

omitted the braces>which I have seen elsewhere< and runs without issue.  I do understand your point.

 

skeeve wrote:
I would know that the indent was spurious.

What difference does it make?  none as far as the code working.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Writing UBRRnL will trigger an immediate update of the baud rate prescaler.

Well, even that is just slightly uniformative...so the divisor is changed immediately, what about resync of the counter that the divisor is compared to? Hopefully, it is also immediately reset.   Note, this is always a non-issue when increasing the divisor, but could be when decreasing.  Hopefully they use >= as a comparison, rather than =.  Adding a delay ensures everything is synced back up (though maybe it is moot).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

The change to UBBRnL is done after the last byte leaves, and there is a 10ms delay before the app continues. I will agree up front that 10ms is excessive, but the app is not timing critical so it's not an issue

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

>what about resync of the counter that the divisor is compared to? Hopefully, it is also immediately reset.   Note, this is always a non-issue when increasing the divisor, but could be when decreasing.

 

You have a down counter and some fixed dividers. When the uart clock generator prescaling down counter reaches 0 (clocked by fosc), a clock is generated (to the dividers) and the down counter reloaded from ubrr. When you write to ubrr, the value is loaded into the prescaling down counter. The only comparison is the down counter compared to 0, which produces a clock to the first /2 divider input (and directly to the rx recovery clock).

 

It doesn't matter when that first clock edge reaches the transmitter through the /2 /4 /2 dividers, as long as the following clocks are equal in length, and a tx is not in progress when the change is made. You have no control of the divider state, but there is also no need to know. A consistent clock from start bit to the end of the stop bit is all that is needed.

 

Then again, this thread is mostly suggestions that in the end make no difference to the end result. Any of the original examples would work equally well and the other end of tx would never know which version is being used.

 

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

jgmdesign wrote:
What difference does it make? 
It makes it more difficult for others reading the code to follow what's going on (and you when you come back to maintain it in 18 months). Most IDEs have some kind of "fix indent" feature.

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

clawson wrote:

It makes it more difficult for others reading the code to follow what's going on

THIS is that hard to read and understand:

 

while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
    UDR1 = byte;
    byte++;  //increment byte by one

When it's inside function braces?  C'mon...thats being really picky.  Even my novice self can figure out what that is doing.

 

Incidentally as we all know the Code Editor removes the original format/alters it not that it means much.

 

I went and did a little light reading on indentation in C programming.  Some really good stuff out there too.  Lots of different styles too.  K&R, Allman, GNU, Whitesmiths, Horstmann, Pico, Ratliff, Lisp, Haskell etc.. Does this mean that should I say, choose Lisp style, and post in that format, someone says its unreadable do I now have to post in every other style to please the masses?

 

One comment I found in several spots was to write the way you want, but be consistent.  I will agree with you Cliff that it should be clean, but complaining about a couple spaces indentation is just ridiculous. JMO

 

I did a search of the Freak Show and this topic has come up...quite a bit.  One long ago member found a Studio extension called AStyle and in it there are a lot of features including the style of programming you wish to use and ways to set it up to ones liking.  I downloaded, and installed it on my machines and chose "Whitesmiths" format.  The extension went and cleaned up a few things for me and does not add any squiggly lines or what have you to leave me scratching my head.

 

So, hopefully this will make the majority happy.  If not, well I tried.

 

 

Keep the feedback coming!

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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


jgmdesign wrote:
When it's inside function braces?  C'mon...thats being really picky.  Even my novice self can figure out what that is doing.
It's what I do professionally. All our code is subject to "peer review" so when I write stuff, before it can merge into our main code tree, one of my colleagues has to "score" it to say it is acceptable. It works the other way too, I act as a reviewer for my colleagues work. So I spend a lot of my time critiquing other people's work on various bases but one is about readability and maintainability. Your example here is a kind of classic. The indentation structure looks like the intention might have actually been:

while ((UCSR1A & DATA_REGISTER_EMPTY)==0) {
    UDR1 = byte;
    byte++;  //increment byte by one
}

As well as human critique (which is more about an informed view of "is this the best way to implement what's being required?") we also have computerised critique from tools which range among cppcheck, lint, Klockwork, QAC and other code checking tools. Some of these also apply the MISRA rule set. All these things are likely to reject code with bad indentation.

 

To be honest most C programmers should be made to d a couple of years of Python, a language that simply will not let you get indentation wrong !

 

I just searched "indentation clawson site:avrfreaks.net" at Google. A good illustration of the difference between good/bad indentation is seen between #1 and #2 here:

 

https://www.avrfreaks.net/forum/problem-spic

 

It really can obfuscate code to the point of almost total illegibility. (and that's not the best example we've seen here, just one of the first results in a search!)

 

You may think this is trivial but in software terms I see it no different between some one who would accept this:

 

 

versus someone who will only accept this:

 

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

Love the Soldering/PCB analogy!!

 

Again, I am not arguing that code should be as cleanly written as possible, but what I am arguing is the 'pickyness' of some. 

 

As I wrote, I went and added the Astyle extension to Studio, and I'll tweak it to make sure things are as clear as possible.  If this is not good enough for some, well I tried.

 

Lets not take the thread even further off its topic.  I think this horse could be beaten to death elsewhere.

 

Cheers,

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

One more swipe at the horse.

The issue is not about whether said the source for send_stuff produces the correct object code.

So far as I can tell, said source is perfect in that regard.

The issue is not whether it can be read at all.

Certainly it can be.

The issue is that even if the source for send_stuff never needs to be changed,

it can still hide bugs.

The complained-of code is slower to read

than it would be if it were correctly indented.

It certainly slowed me down.

If one is on a bug hunt and only has so much time,

the extra time might keep one from finding one more bug

 

Iluvatar is the better part of Valar.

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

Funny nobody have noticed that this : 

 

#define BAUD2400	191
#define BAUD4800	95
#define BAUD9600	47
#define BAUD1440	31
#define BAUD1920	23
#define BAUD2880	15
#define BAUD5760	11
#define BAUD7680	7
#define BAUD1152	3
#define BAUD2304	1

is full of errors ;)

So perhaps use the calculation.

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

sparrow2 wrote:

Funny nobody have noticed that this : 

 

#define BAUD2400	191
#define BAUD4800	95
#define BAUD9600	47
#define BAUD1440	31
#define BAUD1920	23
#define BAUD2880	15
#define BAUD5760	11
#define BAUD7680	7
#define BAUD1152	3
#define BAUD2304	1

is full of errors ;)

So perhaps use the calculation.

WHat errors?  The numbers have been taken directly from the datasheet.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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


As Jim says, this is from a typical AVR datasheet (328P in this case):

 

 

As far as I can see his #define's match this exactly. So is the suggestion that Atmel have got this wrong in all their datasheets?

 

Actually, just to be sure I just checked with:

D:\>python
Python 3.6.2 (v3.6.2:5fd33b5, Jul  8 2017, 04:57:36) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> for i in [1, 2, 4, 6, 8, 12, 16, 24, 32, 48]:
...     print(i * 2400, (7372800 / (16 * i * 2400)) - 1)
...
2400 191.0
4800 95.0
9600 47.0
14400 31.0
19200 23.0
28800 15.0
38400 11.0
57600 7.0
76800 5.0
115200 3.0

 

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

???  From #25 it very clear that 57600 and 76800 baud is wrong

#define BAUD2400	191
#define BAUD4800	95
#define BAUD9600	47
#define BAUD1440	31
#define BAUD1920	23
#define BAUD2880	15
#define BAUD5760	11 should have been 7 , 11 is 38400 baud
#define BAUD7680	7  should have been 5
#define BAUD1152	3
#define BAUD2304	1

 

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

I stand corrected! Good catch.

I guess had I indented properly it would have never happened? ;-) :P

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user