usart@8mhz problem

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

Hi,
I have the following problem:

I have a mega128 which runs at 8mhz (internal clock). It is connected to another controller via USART. The problem is that at the second controller I cannot change the baudrate, it always uses 115200. So my question is:
The error AvrCal calculates is nearly 8%. Does this work? Is there another prescaler or something like this in order to "finetune" the usart baudrate?

Thanks,
Tappo

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

can't you change the Mega128's crystal to the 7.xxx MHz one which reduces the error?

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

Quote:

Does this work?

No. Certainly not reliably.

Quote:

Is there another prescaler or something like this in order to "finetune" the usart baudrate?

Not really. You can get very good results if you "tune" the internal oscillator to as close to 7.3728MHz as you can get. This can either be done one time (not as good due to the drift with changes in temperature and supply voltage) or peridically/continually using some kind of a fixed time base.

Do yourself a favour and spend US$1 on a 7.3728MHz crystal & a couple of loading caps. After all, you have selected the most expensive AVR processor at >US$10.

Lee

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.

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

You may use "double speed"; the relative error will be aprox. 3.5%.
HTH.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Hi,
thanks for the answer. Unfortunately, I can't change the clock frequency. I is important for my application that the clock is exactly 8mhz, which is bad for the uart...

The double speed idea is good. How bad are 3.5% error?

Thanks,
Tappo

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

Quote:
The double speed idea is good. How bad are 3.5% error?

Hmmm, statistically speaking, there is a "chance" to get 3-4 erroneous chars at 100 chars...
There might be a way to improve this situation by software (you may use checksum or CRC).
[or you may use parity bit in your transmission… if possible].

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

Last Edited: Thu. Jun 9, 2005 - 08:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How bad are 3.5% error?

Bad, for reliable communications at high speed.

[flame] "I gotta adapt this app to use exactly XYZ module and interface it, but I cannot change anything. What's wrong?" I call it "system design", but I guess I'm just too old to understand all these new-fangled ideas. "It is important for my application that the clock is exactly 8mhz, ...", indeed. Like I've never had to re-work an application's timing to accomodate changing requirements or peripherals. [/flame]

Lee

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.

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

P.S. I hate to tell you this, tappo, but using the 8MHz internal oscillator you are >>not<< running at "exactly 8MHz".

Lee

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.

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

Atmel doesn't recommend serial communications on the internal clock, maybe you should consider adding an external clock to the circuit. If you send 1 word and then pause and so on, there should be no problems with communications. That being said, 3.5 % error will still mean that when youy get to your 15th bit in a frame, you're in trouble.

an object at rest...
cannot be stopped!

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

OT : Hhehehe Lee, we're on the same wavelength.

an object at rest...
cannot be stopped!

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

Final conclusion: tappo, you better buy a 7.3728MHz crystal & two caps :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Tell us what its supposed to do that requires exactly 8mhz.... some critical timing? Something that has to run real fast? And why wont it work at 7.3728? I bet if you say what the requirement is, we can tell if it can be done with the 7mhz baud rate xtal. Since a 128 will run at 16, why run at 8? Use 14.7456mhz xtal.

Imagecraft compiler user

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

If I need different clock rate in one program (for example: serial communicating for uploading some infothru USART, and after sending this via PWM), then I used 2 calibrated values for internal ossc, and change this value before perform next operation.
It's works for me for Anouncement machine with uploading WAV files to memory...

Pavel.

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

14.7456MHz xtals work great. Try one of those.

Imagecraft compiler user

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

Hi,

@Stanley and the others

Quote:
Hmmm, statistically speaking, there is a "chance" to get 3-4 erroneous chars at 100 chars...

????
Or: 3-4 erroneous bits per 100 Bit? With 8N1 3-4 error Bytes at 10 Bytes?
Would be bad....
????

I think it is not so bad.
I am not sure of it, but I thought, that RS232 synchronizes with every START bit.
If so, with a deviation of 3.5% I would not expect (much) errors.
The deviation is max. 0.35Bits @ 10 Bits.
In AVR there is a "noise filter" with sth. like 4 x oversampling.
Maybe 1,5 or 2 StopBits can improve transmission.

Again: I do not know if it works. Try it. I also recommend CRC or sth else.

You need exactly the 8MHz or a devided frequency?

Klaus
********************************
Look at: www.megausb.de (German)
********************************

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

@Klaus:
Well... maybe you're right. But, notice that there are 2 problems here:
1) the baud rate error 3.5% due to 8MHz xtal;
2) the frequency itself (that may not be exactly 8MHz).
Of course OP may use the current "HW/configuration", but with some helping tricks:
- checksum or CRC;
- parity bit, extra stop bit;
- HW/SW tuning;
- bla-bla-bla.
Finally, wouldn't it be better to spend one buck for a 7.xxxx Xtal & two caps.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Hi,

@Stanley

Quote:

Finally, wouldn't it be better to spend one buck for a 7.xxxx Xtal & two caps.

Yes, of course - far better. I fully agree with you.

But the OP stated twice that he needs the 8MHz.

And that´s why i tried to say that there is a chance (even it´s no good solution) to hold on the 8MHz and the baudrate.

I asked if he needs the devided frequency because there is a chance for a workaround to get his desired frequency of the 14...MHz.

It´s his own secret why he needs the 8MHz :roll:

Klaus
********************************
Look at: www.megausb.de (German)
********************************

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

Quote:

But the OP stated twice that he needs the 8MHz.

I think at least once "exactly" was mentioned. And I responded that with the internal oscillator, it ain't gonna be exatly.

Lee

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.

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

Well at such a high data rate of 115200 and a error of 3-4% it can really tough.
One way of avaiding the error is by using some type of protocol. One of the good
protocols that is open source and easy to implement is SNAP. se the link :.
http://www.hth.com/snap/
Its really cool and the Most customizable .

AVR Rulez...;-)

Warm Regards,
Boseji
http://m8051.blogspot.com/