## Baud rate got me bamboozled

41 posts / 0 new
Author
Message

Hello all,

I am in dire need of help from you. I come from a computer programmign background, and have basic idea of what baud rate is and what role clocks serve in synchronous circuits. However, I had np idea that something as simple could give me so much pain. The more documents I read on this subject the more frustrated I become, therefore I have resroted to asking in forums instead of reading books. I really need someone who I can ask stupid questions to. Will you help?

Question one:

The way I understand it:

• Bitrate = Oscilator frequency / Clock divisor;
• Baud rate = Bitrate / Size of one baud;
• Size of a baud= Start bits+ Data bits+ Parity bits+ End bits

Therefore, to calculate baud rate, we need the following info: oscilator frequency, clock divisor value, baud size.

Nowhere in the documentation of AT89S52 (the first Microcontroller that i tried to program) do they mention the internal oscilator frequency. However, it does mention that it can accept an external oscilator, which is very good and dandy until I realized that it does not mention the divisor value anywhere.

I have tried to program many other microcontrollers since; including ATMega 8, ATMega 328p etc, and none of the documentations seem to mention any of the required data for calculating baud rate. Instead, they keep talking about internal baud rate generator, mention a lot of formulas, UBRRn, Fmod, SMOD, TCLK, T2CON, RCAP2L etc etc. Previously I had the idea that baud rate will be among the first things mentioned in the documentation alongside voltage tolerances, footprint, pin mapping etc. Where in the documentations do I look for the data required to calculate baud rate?

Question two:

The crystals I use are two legged. The tutorial videos like this one (https://www.youtube.com/watch?v=...) also seem to use the two legged ones. But ric from Microchip forum mentions that the two legged ones are just crystals, not the whole oscilators. That thread mentions there are three types of crystals:

• Two legged barebone crystals,
• Three legged crystals with capacitors,
• Four legged complete oscilators that require power and ground.

The last ones are the only ones that release logic level square waves.

So what's really up with the value KDS11.0592 that is writen on the two-legged crystals I have? Do the microcontrollers have internal oscilators and only need a crystal between XTAL1 and XTAL2 ? If I connect a crystal between XTAL1 and XTAL2 on a chip, how can I determine the actual oscilator frequency from the crystal value?

1. Kerry D Wong,s baud rate calculator spreadsheet requires "crystal baud rate". How can crystals have baudrate? I thought all they do is to release a square wave.
2. Wormfood's baud rate calculator requires bitrate as well as crystal frequency. So those two are different somehow? How?

Question three:

When trying to program an IC using Arcuino ISP and AVRDUDE, I keep getting unknown signatures of the format 0xffff00 / 0xff8000 instead of 1E 52 06 / 1E 95 0F. If I try to force write, all I get is : Writing |  ***failed;
***failed;
***failed;
# ***failed;
***failed;
# ***failed;
***failed;

and so on. I have been hard ressed to find any information on this error in Google search. It seems this error is pretty rare. What am I doing wrong here? Any idea?

BTW, it is not the fault of the IC because I have tried multiple copiess of AT89S52 as well as ATMega8A and ATMega328P. I am assuming that this is baud rate issue because I have no idea about that one parameter. Or is this something else altogether?

About why I am using an Arduino as ISP instead of an USBASP, the answer is: fischl's USBASPs are not available here. I bought a local one but that is not even being detected as a COM port. However, it is another matter altogether.

This topic has a solution.
Last Edited: Thu. Feb 1, 2018 - 08:45 AM

If you don't know how to calculate it just look it up in the 328 datasheet in the table about "examples of baud rate setting". That has most common CPU frequencies. When you first buy a 328 it arrives running at 1MHz. if you are using baud rate this may not be the best idea as you cannot, for example, use the common 9600 baud as that has too big an error on 1MHz (though there is a workaround). Far better is to use ISP to change the fuses to deactivate "CKDIV8" so the 328 then runs at 8MHz not 1MHz.

An alternative to simply using a number from the datasheet will depend on the programming language you choose but if you use avr-gcc it has this:

http://www.nongnu.org/avr-libc/u...

The only "input" you have to provide to that are #define's for BAUD (the baud rate you want to use) and F_CPU which is the CPU frequency and, as I say by default that would be 1000000UL and after changing CKDIV8 it would become 8000000UL

From general communications theory:

bitrate is the number of bits per second.

baudrate is the number of "symbols" per second.

https://en.wikipedia.org/wiki/Baud

For "simple" stuff such ar microctontrollers uarts these are usually the same.

But these are general terms and in communications theory there can be multible "bits" in each "symbol".

Think for example about an optical fiber where light of different frequencies goes through a single fiber.

Or "QAM" (Quad Amplitude Modulation) where a symbol can have 4 amplitudes and a symbol is 2 bits.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Take a deep breath, that post was all over the place.   Start by telling what it is you want to accomplish?

Jim

Or in your terms: size_of_baud=1 bit

sbcontt wrote:

If I try to force write, all I get is : Writing |  ***failed;

Never, ever, ever, use the 'force' option unless you really, really, really, understand why you might want to use it. If you do, you stand every chance of bricking your chip. If you can't read your chip's signature there is never any point in trying to write to it.

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Actually, I just wanna write a hex file in the chip :(

Okay I see. So for AVR microcontrollers, bit rate=baud rate in every sense?

Thx for the suggestion. I have only ever attempted force write on the 8051 chips, so hopefully all my ATMega chips are still alive.

Last Edited: Tue. Jan 30, 2018 - 06:01 PM

Much appreciated. I have some clue about the documentation now.

The table uses terms like U2Xn, UBRRn etc. As far as the datasheet is considered, those are registry values. So I can't modify them unless I manage to upload a hex file in the chip in the first place. As the error % seems zero for all baud rates (except 76.8k), does this mean I can upload the first hex file at any standard baud rate?

I will look into the wiring next.

"So what's really up with the value KDS11.0592 that is writen on the two-legged crystals I have? Do the microcontrollers have internal oscilators and only need a crystal between XTAL1 and XTAL2 ? If I connect a crystal between XTAL1 and XTAL2 on a chip, how can I determine the actual oscilator frequency from the crystal value?"

Well, it is a 11.0592 Mhz Xal.

Micro controllers (most) have internal oscillators; it seems a good news; it is a good new if you do not need accurate timing (blinking a LEd, control a motor...); it is a very bad new if you want to use asynchronous communication, as they drift.

The only comfortable solution is to use a Xal (cheaper than external stable oscillators) , with its 2 capacitors or a resonator (oscillators are more expensive ) .

Once you program it -did you see Clawson's gravatar?-, you should verify it works. Traditional way is to have a LED blinking, at a given rate:

set the LED's port as output

DO

put the LED on

wait 1 second

put the led off

wait one second

DONE repeat for ever

can do the job: you can verify the Xal is working

The delay is deduced from the Xal value: if the Xal is not recognised, it will blink at a strange speed (not 0.5 hz).

This works for any MCU, AFAIK.

The avr-specific is ... Clawsons' gravatar.

Other method is to connect a frequency meter, if you have -more expensive than LEDs, any way_ But, avr's clock may be divided by 8 (nasty fuses) and an eye is enough to discriminate between, say, 0.5 and 0.1 hz.... Anyway, such a trivial program is the "only" cheap and comfortable way of being sure of the configuration and soldering.

Edited : saw jstampfl post:

my post assumes one is able to program the MCU....

Last Edited: Wed. Jan 31, 2018 - 08:39 AM

Here is a step by step explanation origramming a ATMega328 using an Arduino UNO.

https://www.open-electronics.org...

There are 2  communication domains in what you are asking:

the first is an SPI communication from the master Arduino running the Arduino ISP sketch to the target AVR chip.  The master is usually running at 16MHz, but the target could be running at a lower speed.  Since SPI is a synchronous protocol there is a clock, SCL, driven by the master.  the clock speed must be adjusted depending on the cpu clock on the target.

Here is some code from the Arduino ISP sketch:

```
// Configure SPI clock (in Hz).
// E.g. for an attiny @128 kHz: the datasheet states that both the high
// and low spi clock pulse must be > 2 cpu cycles, so take 3 cycles i.e.
// divide target f_cpu by 6:
//     #define SPI_CLOCK            (128000/6)
//
// A clock slow enough for an attiny85 @ 1MHz, is a reasonable default:

#define SPI_CLOCK 		(1000000/6)

```

The second domain is in the application that is programmed into the target.  For this, refer to the datasheet.  This will depend on the clock selected for the target when running the application that you just programmed.

sbcontt wrote:

Actually, I just wanna write a hex file in the chip :(

Then what has that got to do with "baud rates" at all?

AVRs are (generally) programmed using a technique called ISP (In System Programming) that is really just SPI. That is a synchronous serial protocol where one of the wires actually supplies a clock so their is no need for concepts like "baud rate". That link just runs at whatever the clock rate on the SCK line is - always less than 1/4 the speed of the AVR but typically something like 250kHz.

"baud rates" are for when you use an asynchronous link (which means both ends independently clock the bits but they have to agree on what rate they are using between them). That comes into play when you use a UART (the A there is Asynchronous). But you can only start to use the UART in an AVR once you have put some software in the chip and like I say, for that you use (usually) ISP.

but they have to agree on what rate they are using between them

The logical consequence is that clocks values should be as close as possible, leading to the use of Xals/resonators.

IMO , OP had two issues:

a) understanding notions of asynchronous transmission

b) has some issues with avr-dude (got an error message: did not post the command)

sbcontt was the first to adress point (b) -it one wants to program -too?- fast, it is the point which should be treated first;

OTOH if some documentatiion is needed (: I remember abcminiuser has good tutorials w/r UART), the order (a -UART understanding) then (b -hailing avrdude- ) is logical.

Your second answer makes the problem very clear. I was editing the Arduino ISP code to change the baud rate (because I was focussing entirely on the freaking baud rate), but not the SPI clock.  As it seems to me now, baud rate was a red herring all along.

Thx for the help. I would have never guessed it myself.

However, I am really confused after reading the tutorial you provided. It does not use the Arduino ISP sketch at all, nor does it use avrdude to uoload the sketch. Does this mean that the ArduinoISP sketch is fundamentally useless? Is this the reason I was failing to communicate with the AT89s52 all along?

That would be very disheartening because I need a generic method for programming different MCUs.  I am assuming that the tutorial you provided only works for programming ATMega chips?

AT89 != AVR

Why do you think the ISP sketch in Arduino would know how to program an 8051?

sbcontt wrote:
Nowhere in the documentation of AT89S52 (the first Microcontroller that i tried to program) do they mention the internal oscilator

Probably because it doesn't have one?

Well, I was tearing my hair apart on the baud rate because so far I have been unable to put a single bit into the chips, and baud rate was the only avrdude parameter that I was not sure of... but now that you mention it....

8051 needs a shift clock that is less than 1/16th of the CPU clock, which means 11000000/16 (because I was using a 11MHz crystal), but that is still more than the default in Arduino ISP sketch (1000000/6). And I had edited the sketch to make the baud rate 9600 which is the value that I was supplying to avrdude. I had also inverted the reset pin using a hex inverter and followed this instruction: http://ernstc.dk/arduino/at89s.html for the rest of the wiring.

To my inexperienced eyes, the only remaining possible fault seems to be a voltage issue. All of the components (Arduino, AT89S52, MC74F04N, and indicator LEDs) are currently being powered by my laptop's USB port. Today I received my variable voltage supply, and will give it another go, provided the 8051 is not already dead thanks to my force write attempts.

Last Edited: Wed. Jan 31, 2018 - 12:39 PM

Did you miss clawson's comment in #17?

The 8051 is an entirely different architecture from AVR - so nothing Arduino is going to work with it!

It does have an SPI programming interface though and people use USBASP programmers to program it. Unless the Arduino ISP has some specific limitation that prevents it from working with anything other than AVR chips, it should work.

I was aware of the possibility that the 8051 might need a dedicated USPASP programmer, but the one I received was DoA. I can't find a fischl VID/PID compatible one anywhere locally, hence I am hesitating to order another. The local ones only work with a chinese software called ProgISP.

This reply has been marked as the solution.

sbcontt wrote:
people use USBASP programmers to program it.
That is USBAsp programmers with specially modified software. To achieve the same with ArduinoISP you'd need similar mods. there.

The "simple" solution s probably to forget ArduinoISP and just get a (\$2!) USBAsp that offers AT89 support.

EDIT: this did get me wondering "has anyone already modified ArduinoISP to do this". What I actually found was this:

http://www.instructables.com/id/...

So that appears to not be a modification to the original sketch but a completely new piece of software that turns the Arduino into an 8051 programmer.

But your original post mentioned mega8 and mega328 too. Those two should be programmable using ArudinoISP.

Last Edited: Wed. Jan 31, 2018 - 12:37 PM

You have provided an excellent answer. Never knew that SPI is not as universal as UART.

I did buy an USP ASP device, but it is not being detected as a COM port and that is another issue I am struggling with. I have no idea whether the product is faulty or I am doing something wrong. I am in contact with RoboIndia support for a resolution.

It is a good thing that I did not just order another though... because I did not know about the whole compatible issue, and manually programming the ATMega8 chips found on those devices for AT89XX support would have been a bigger doozy.

I'll give the AT89XX a last try using the tutorial you provided, then I will move on to AVR chips. Thanks again.

SPI is "universal" in operation (once one of 4 modes is agreed and both ends are happy that it won't all be "too fast") but all it does is get a byte (usually) from one end to the other. In that sense it differs little from UART. But it's the bytes you send that matter. Imagine me typing across a UART link to another human only I type English at him (so I know what the byte sequence 'h', 'e', 'l', 'l', 'o' mean) but he's Chinese and has no idea what I'm typing. Your AVR vs AT89 thing is a bit like this. They might exchange the bytes OK but one won't understand what is intended for the other.

sbcontt wrote:
I will move on to AVR chips.

sounds like the best option - AT89XX support is, as you've seen, somewhat lacking these days.

Just for the sake of curiosity, it is the difference in serial encoding scheme (RZ, NRZ, Manchester, Differential Manchester etc) that causes the incompatibility issue, right?

You’re getting way too complex! The main difference is the values that are sent and the timing. The relevant datasheets outline the methods involved. You could also look at the source for ponyprog which would bit bash the PC printer port to program devices.

Thaks to everyone in this thread, my problem seems to have been solved. Although I learend a lot about the fundamentals through my conversatiosn with you all, the problem itself turned out to be pretty stupid at the end. There were faults in three areas: the AVRDUDE params, the AVRDUDE config file, and the wiring of the RESET pin.

The GUI I was using for AVRDUDE turned out to be utter crapola, and the config file I was using might also have been crap (although the GUI still doesn't really work even with tobychen's config, but at least it reads something).

I might have also taken the instruction to invert the reset signal a little too literally and previously had passed it through a HEX inverter (which probably saved the ICs while I was doing force writes). What's the reasoning behind that resistor-capacitor setup as showin in tobychen's guide? I need to consult a few books to understand the deal behind the RESET pin.

If anybody is interested, I was using Jak's AVRDUDESS GUI with Joy Sukla's config. I did not realize that the fault was in the GUI due to the fact that it was detecting the ATMega328p sitting on the Arduino pretty fine (Detected 1e950f = ATmega328P). Now I am using avrdude directly from the command line. No more GUI.

P.S: After reading the link clawson provided, I found out that the ArduinoISP sketch actually does natively support AT89S52. I did not need to alter it a bit.

This is where I am at right now:

C:\Users\sbcontt\Desktop>avrdude.exe -C avrdude8051.conf -c stk500v1 -P COM6 -p 89s52 -b 19200

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.14s

avrdude.exe: Device signature = 0x1e5206 (probably 89s52)

avrdude.exe: safemode: Fuses OK (E:FF, H:FF, L:FF)

avrdude.exe done.  Thank you.

If this works, then the ATMega chips will surely work as well. Now I can finally proceed to programming the thing. I have marked clawson's post as solution because that is what helped in the end, but I thank everybody who helped. I was about to go into depression for failing to do a most basic task .

Last Edited: Thu. Feb 1, 2018 - 09:39 AM

Thanks for your idea of reverting to the command line when guis are lazy (this happens with some, very old versions of Arduino one cannot upgrade easily) . May give some avr/arduino resurrection to some of my xxxPis....

BTW : have you taght about using Arduino to have already working libraries for avrs -GUI works well under W7).

Well, I don't quite understand your suggestion. I am new in this domain.

But if you are talking about using Arduino IDE and taking advantage of  already present libraries, then sure. That is the reason I bought a bunch of ATMega328p. I am well aware of the fact that it is the most popular MCU for DIY and enthusiasts thanks to Arduino uno, and on top of that I can just use a Uno board to program it using Arduino IDE as long as it comes with the required bootloader, which most of them probably do out of the box.

Last Edited: Thu. Feb 1, 2018 - 09:50 AM

sbcontt wrote:
it is the difference in serial encoding scheme

No, it isn't.

SPI and UART are both NRZ.

As already noted, it's not to do with link hardware - it's to do with what you send over the link.

EDIT

https://en.wikipedia.org/wiki/Non-return-to-zero

Last Edited: Thu. Feb 1, 2018 - 12:06 PM

awneil wrote:

sbcontt wrote:
it is the difference in serial encoding scheme

No, it isn't.

SPI and UART are both NRZ.

As already noted, it's not to do with link hardware - it's to do with what you send over the link.

EDIT

https://en.wikipedia.org/wiki/Non-return-to-zero

What else could be different? SPI isn't even framed, is it?

I checked the Arduino ISP code for a bit, and the only suspect I could find were a few 8 bit values the program sends using SPI.transfer. I have not checked the SPI class yet, but I assume those are EEPROM OPCodes?

But Microchip's documentation shows Opcodes as two bit values....

Last Edited: Thu. Feb 1, 2018 - 04:38 PM

sbcontt wrote:
What else could be different?

See #25

I wonder whether my questions are bothering you. Because #25 is a layman's answer Digital communication at its simplest form is nothing but a bunch of highs and lows. It is universal lanuage because it is math based.... has nothing to do with English or Chinese.

If I write wrong bytecode on the target EEPROM, the MCU won't boot, but as long as the clock and memory addressing scheme are same, houldn't it at least accept the write? Does SPI invoke the CU of the target chip? I will be pretty surprised if it does, because the -F option would not have made sense if it did.

BTW, I was asking it not because I need to know it for my task. I was just curious. If this is not the place to do so, pls ignore it.

Last Edited: Thu. Feb 1, 2018 - 04:53 PM

I'm kind of totally lost here on what you need/want/question.

[It appears that the original question(s) are related to ISP.  Yes, "Serial Downloading" on many/most AVR8 models including the ones you listed is very "SPI-like", and on many/most models the programming (ISP) pins are the same as those for the SPI peripheral.  Is that what you wanted?]

sbcontt wrote:
The more documents I read on this subject the more frustrated I become,
sbcontt wrote:
I have tried to program many other microcontrollers since; including ATMega 8, ATMega 328p etc, and none of the documentations seem to mention any of the required data for calculating baud rate.

Given the above, I've not heard "baud rate" used in this context.  It might be used in certain ISP contexts such as avrdude?  Anyway, the fastest data bit rate, with is also the clock frequency, for the Serial Downloading/ISP/SPI-like interface is in all the datasheets, isn't it?  It relates to the frequency that >>your<< target AVR is running at.  As virgin AVR chips run at ~1MHz and that bit rate can be no more than 1/4 of that (datasheet quote below) then a "safe" bit rate for ISP is ~250kHz.  If you run your AVR at a higher frequency then indeed many of us would use a faster bit rate so that ISP doesn't take as long.

Depending on CKSEL Fuses, a valid clock must be present. The minimum low and high periods for the serial
clock (SCK) input are defined as follows:
Low:> 2 CPU clock cycles for fck < 12MHz, 3 CPU clock cycles for fck  12MHz
High:> 2 CPU clock cycles for fck < 12MHz, 3 CPU clock cycles for fck  12MHz

Does that take care of question 1?

Question 3 may well be related.  Possible causes:

-- Too high an ISP bit rate.

-- Improper connections.

-- No power on target.

-- Improper circuitry on the /RESET pin

...and others.

Yes, do Read Signature first.  If that fails then ISP will fail.  If that succeeds then ISP [probably] will also.  See http://www.avrfreaks.net/comment... for my check list and discussion.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Feb 1, 2018 - 09:50 PM

You need to refer to the relevant chip’s datasheet. Things like commands, sector size, timing etc are described. Even for the same family of chips, the sector size may differ, thus the code generating the bit twiddling needs to know this. Side note - flash memory is programed in sectors - not as individual bytes. If the sector size is 64 bytes, then thats what you have to provide.

Careful with your terminology - you’re loading machine code, not byte code. As for CU, i gather you mean the processor control unit. Flash programing is usually handled by dedicated logic.

Because #25 is a layman's answer Digital communication at its simplest form is nothing but a bunch of highs and lows. It is universal lanuage because it is math based.... has nothing to do with English or Chinese.

I don't know the exact details so I'm simply going to make them up but while SPI is universal and will get one byte from one micro to another (and always one back at the same time) the difference between 8051 and AVR is like the difference between English and Chinese.

So when an ISP programmer has a dialog with an AVR (using SPI as the actually communication transport) it happens to choose to use 4 byte command packets. The first thing it sends is something like 0x1E, 0x55, 0xA3, 027. The expected response is that the AVR returns some unknown value (may be 0x00?) on the first byte transfer then the delayed send byte (0z1E, 0x55, 0xA3) in the next 3 bytes.

I can only guess that the 8051 does but let's say it uses 3 byte command packets and the first command it expects to receive to start its own ISP dialog is 0xBD, 0xF7, 0x28.

If you fed the 0x1E, 0x55, 0xA3, 027 intended for an AVR to an 8051 that was hoping to see 0xBD, 0xF7, 0x28 it wouldn't have a clue what was being said. It would be just like a Chinaman being sent something in English - no hope of understand even if the way you send byes to one another is a common system.

That was my point in #25. I'm sorry you weren't able to understand - I was aiming the description at your level.

Thanks for the response. I did not know that even EEPROM chips have their own opcodes. This makes things quite complex, but now that I know the reasoning behind it, I can do a little bit of programming on the Arduino or a Raspberry Pi to make things compatible.

After being able to program the ATMega, I was actually trying to flash a dead router I have lying around which also uses SPI. But seemigly the MX25L6433F does not have MOSI/MISO pins and requires FT232H or CH341 programmer for the job. After finding that out, I was thoroughly confused as to why every chip requires a different SPI flasher.

But if those codes are the only things that differ, it should be possible to program a Raspberry Pi or Arduino to do the job. I can already find some documentations on such mods, which suggests that the difference between different SPI programmers is indeed in software/firmware level, and not in hardware level.

Last Edited: Mon. Feb 5, 2018 - 06:36 PM