AVRs have in the past been notoriously inaccurate in their internal clock frequencies. It was always necessary to use an external crystal or resonator if you wanted serial comms to work reliably (at any baud rate - it's a dependency on the percentage error, not the actual rate).

I don't know if they've changed their internal clocks since PIC took them over; given that the problem is solved with e.g. STM parts, I would expect so. But I wouldn't guarantee it, and certainly not with the older parts.

Neil

Michael,
I have in use this circuit with 65C02 that run at 1.832 Mhz ; I can estimate that - vhitout variation - should be possible to increase speed up to 2.5 Mhz.
Replacing AVR resonator with acrive oscillator is possible to run AVR at 22,118,400 Hz , theorically speed up 65C02 to 3 Mhz..

Neil,
you are right, but if you look schematic on first post you can see that AVR use 18.432 Mhz resonator; internal oscillator is too inaccurate to grant stable serial communications..

You are right, but this expedient only affect base address of device; BA2 is CPU buffered Address 2(weight 4) , this move base address (selected with CS0 that come from one external HC138) at +4 . This involve that base address should be moved +4 but 6502 code must anyway be modified and code recompiled..
This device is hardware compatible, not software..




This device expose only two 8 bit latch, U3 is write only for 6502 , U1 is read only; all operations on 6502 bus are under complete control of 6502
I ask: how is possible to make two concurrent operations with 6502?
If 6502 read U1 no other device contend bus; if software want to write on U1 should be corrected and U3 latch have only inputs on 6502 bus.



Sorry but use of internal AVR clock is not reccomanded for hi speed communications, I use resonator (or actrive oscillator to overclock)

FWIW: I've used ATmegas for many years now - 100s of them in little commercial project and many in my hobby stuff.

I've read this about the internal 8Mhz oscillator often, but have never experienced it myself. The internal oscillator (on the '168/'328 and newer) is 8Mhz derived via an RC circuit and out of the factory its accuracy is +/- 10%. This is good enough for serial comms up to 9600 baud and maybe a bit faster.

Fortunately they can be calibrated to +/- 1% (or slightly better) This is more than good enough for baud rates up to and beyond 115200.

And oddly enough, the most common way to calibrate is via serial. You have code running on the to read a known byte (or several) at a set baud rate, time the byte read with a software loop and use that to calculate and apply the calibration byte. It's not automatic and you have to apply the calibration byte every reset - but then you have some on-board EEPROM to store that in...

The baud rate generator runs directly off the AVRs clock (internal or external, whatever one is running) and the calculation to derive it is relatively straightforward - picking an external crystal frequency to be a "nice" multiple does make sense from that point of view. It makes other things harder such as accurate timing, but that's the swings and roundabouts of it all. There is also a voltage vs. max. xtal frequency graph too. I worked on a system at 12Mhz some time back and that was marginal (according to the manual) for a 3.3v system - in practice it was rock solid and the system worked well at 16Mhz but of-course overclocked, so outside the spec...


230,000 baud ... That's 23,000 characters per second, or 43µS per character. You'll need a fast 6502 to keep up with that.

(note: edited to fix a dyslectic typo)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

oh i think i see what you mean... you assume that CS0 (pin 2) is always tied to a CPU address line, in which case you are right and it would function, but keep in mind that that case is not guaranteed.
for example a system could simply tie CS0 (pin 2) directly to 5V and only use CS1 (pin 3) to select it. or the other way around, tie CS1 low and only use CS0. both cases are perfectly valid according to the datasheet but niether would work with your board.

as practical example: the 65C22 on my 65816 SBC. i have CS1 always pulled high, and only use CS2 to select it (names are off by 1, but you get the point).



i assume you mean that programs that try to write to U1 should be re-written to not do that... which is not the best safety net as you cannot predict software bugs like accidental writes.
and it's a very bad idea to design hardware that assumes that software written for it is perfectly functional all the times... always assume that software breaks and does thinks to your hardware that you don't want.
which in this case means to correctly handle the CPU trying to write to a read-only register, or read from a write-only register.

As long as you can do the calibration, yes. The internal oscillator is generally stable (a bit variable with temperature) but one of the most frequent questions on AVRFreaks was why the comms wouldn't work.

Irrespective of your data rate, the two ends of an async RS232-style link have to be within 5% of each other; otherwise one of them ends up half a bit or more out of sync by the middle of the stop bit. With faster speeds, the divisor is smaller and so errors are magnified because the speed can't be set as an exact divisor and so the rate is wrong before you start.

Neil

edit: corrected 10% to 5%

Ciao,
I agree with you that it is not a replacement for the 65C51, it couldn't be for many reasons other than those you mentioned, starting from the 8 bytes occupied..
On the other hand WDC also failed to make one compatible with the old 6551..

I agree with you that asynchronous serial communication without perfect frequency matching is a pure gamble..
A parallel and bidirectional link is certainly preferable as well as being faster.

It shouldn't be a gamble - that's why there are permitted tolerances - If you do the sampling right then the accumulative error isn't bad - you wait 1.5 bit times (or the hardware waits 1.5 bit times for you) after the start of the start bit then sample every 1-bit time after that, so creeping errors ought to be fine - but yes, there is less wiggle room the faster you go.

Parallel links - sure - the down-side is the number of wires required. I worked on a system that had 8-bit wide synchronous parallel transfer links in the early 90s implemented as differential pairs - the data rate was something like 75Mhz (so 75MBytes/sec, or about 50 after protocol overhead) This was over 15m long wires. The backplane for the boards was quite something else when bringing out some 15 (or 16? I forget) of these links per board. It was not a trivial operation to plug the boards in/out!

But we're talking here about low Mhz 8-bit CPUs not early 90s supercomputers...

There is a balance though.

I do like this idea of plug-in hybrid ICs - make them pin/function compatible with existing chips and give them extra features using otherwise unused pins (or ones that we can do away with these days).

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I hate to disagree with you, Gordon, but this isn't strictly the case. If your baud rate generator is wrong (as is often the case with an AVR on an internal clock) then the creeping error is always there and always in the same proportion.

Assuming the most common 8-n-1 format, you have ten bits including the start bit. Hardware detects the falling edge of the start bit and waits half a bit period; if it's still low, then it assumes a valid start. It then repeatedly waits one bit period to sample the next bit; the final sample is the stop bit which should be high.

If you have a rate difference between the two ends, then the sample time gets closer and closer to a transition; if the receiver is faster then towards the eighth bit instead of the stop bit and past the end of the stop bit if the sender is faster. At a >5% differential then the last sample is of the wrong bit - and its worse if the receiver does best-of-three filtering, as many do, since that shaves the permissible timing difference.

This is apparently worse if you have a fast baud rate because with most clock/baud rate combinations (if you're using a non-baud-rate-generator clock) you have small non-integer divisors for the clock and the error is proportionally greater. So it's worse because you're starting with an incorrect baud rate to begin with.

But for accurate and reliable async communications, you need accurate baud rate generators. They _must_ be within 2.5% of a standard baud rate, or if you're using non-standard rates at each end, withing 5% of each other.

Neil (pedantic mode = off)

(of course, there are encodings like biphase mark which are much more robust and don't give a hoot about baud rates, but I don't know of any hardware that encodes them; you need to roll your own.)

..or more simply use a quartz or a 0.5% resonator (or an active generator) that is exactly the necessary frequency..

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I don't see that anyone has pointed out anything wrong with Gordon's statement of the situation - perhaps this is what we describe as violent agreement. (It's not a gamble, it's a calculable margin of a certain size. Arguably that's a matter of perspective. But a precisely incorrect clock is, I think, the situation under discussion.)

Interesting topic and not at all academic for me because I bit-bang serial transmit for many designs. Lately I’m even bit-bang serial receive which is tricky because software can be busy doing something else thus causing delay in detection of the start bit. The timing in bit bang serial is a software delay loop which is coarse. My practical experience is 3% deviation at 115200 is well tolerated—no error at all with few feet of cable. 5-6% start to be problematic. I used to calculate the timing loop very carefully, but now I just adjust timing loop value up and down and use the middle value. 0.5% ceramic resonator is plenty accurate—I’ll be delighted if my software loop is accurate to 0.5%
Bill