My way for 6502 communications, UART & SPI/I2C

[barnacle]

Proxy wrote:

maurice6502 wrote:

To avoid any error at 230Kbaud 18,432,000 Hz is the maximum clock below 20Mhz ; using oscillator insthead resonator should be possible to overclock AVR at 22,118,400 hz with zero error

interesting! i knew AVRs generate the baud rate internally, but i thought they just had a hardwired oscillator for that and didn't make use of any external clock. i guess it makes sense that they do use faster external oscillators.

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

[maurice6502]

Michael wrote:

Proxy wrote:

... so what's the maximum CPU speed you can pair this with before you need to add wait states on the CPU side?

I'm also curious about the maximum CPU speed... TIA...

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..

[maurice6502]

barnacle wrote:

Proxy wrote:

maurice6502 wrote:

To avoid any error at 230Kbaud 18,432,000 Hz is the maximum clock below 20Mhz ; using oscillator insthead resonator should be possible to overclock AVR at 22,118,400 hz with zero error

interesting! i knew AVRs generate the baud rate internally, but i thought they just had a hardwired oscillator for that and didn't make use of any external clock. i guess it makes sense that they do use faster external oscillators.

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

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..

[maurice6502]

Proxy wrote:

maurice6502 wrote:

CS0 signal is active low to select base address for device access, pins 13-14 (BA0 - BA1) are used to select 4 "pseudo" registers; BA2 at pin 2 is a further addressing to allocate more 4 bytes for polling flags

check the datasheet again, the 65C51, similar to the 65C22, has 2 chip selects: CS0 (pin 2) is active high while CS1 (pin 3) is active low. so the chip is only "selected" when both CS0 is high and CS1 is low.
but on your board only CS1 (pin 3, renamed to CS0) is being checked while the original CS0 (pin 2, renamed to BA2) is repurposed as an address line, which can and likely will cause issues in existing systems.
so overall it's not actually 65C51 pin compatible.

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..

maurice6502 wrote:

R/W lines is not mandatory, bus contention is not possible because both latch U1 and U3 are adressed throug U4 ; trying to write to read only address (U1 device) dont crash anything

Proxy wrote:

how does that work though? if BA0-2 is set to 001, CS0 is pulled low, and BO2 (PHI2) is pulled high, then U4's Y1 output (PB1_RXREG) is pulled low, causing U1 to pass it's incoming data onto the CPU's data bus. but if the CPU is currently writing as well, then you have potentially colliding data on the bus (which doesn't necessarily crash, but should still be avoided).
at what point in the circuit is that being prevented without checking the CPU's R/W pin?

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.

maurice6502 wrote:

To avoid any error at 230Kbaud 18,432,000 Hz is the maximum clock below 20Mhz ; using oscillator insthead resonator should be possible to overclock AVR at 22,118,400 hz with zero error

Proxy wrote:

interesting! i knew AVRs generate the baud rate internally, but i thought they just had a hardwired oscillator for that and didn't make use of any external clock. i guess it makes sense that they do use faster external oscillators.

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

[drogon]

barnacle wrote:

Proxy wrote:

maurice6502 wrote:

To avoid any error at 230Kbaud 18,432,000 Hz is the maximum clock below 20Mhz ; using oscillator insthead resonator should be possible to overclock AVR at 22,118,400 hz with zero error

interesting! i knew AVRs generate the baud rate internally, but i thought they just had a hardwired oscillator for that and didn't make use of any external clock. i guess it makes sense that they do use faster external oscillators.

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).

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

[Proxy]

maurice6502 wrote:

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..

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).

maurice6502 wrote:

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.

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.

[barnacle]

drogon wrote:

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.

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%

[maurice6502]

Proxy wrote:

..

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..

[maurice6502]

barnacle wrote:

drogon wrote:

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.

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 10% 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

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.

[drogon]

maurice6502 wrote:

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

[barnacle]

drogon wrote:

maurice6502 wrote:

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.

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.)

[maurice6502]

barnacle wrote:

..
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..

[BigDumbDinosaur]

drogon wrote:

maurice6502 wrote:

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.

The timing tolerance of async serial is small.  Way back when (late 1960s) when I got involved with async serial, then known as RS-232 , I learned that the recommended timing tolerance was three percent maximum—and that was when 300 bps was considered fast.  Three percent timing tolerance on an async circuit running at 115.2 Kbps would be iffy—I’d expect the number of framing errors to unacceptably high.

Quote:

Parallel links - sure - the down-side is the number of wires required.

Aside from the physical aspects of such an interface, signal skew can become a significant problem at really high data rates.  That is the primary reason parallel SCSI tops out at 320 MB/second (ultra-320).  An ultra-640 interface was proposed, but ultimately nixed because the bus cable had to be impractically short to make it reliable.

Quote:

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

There’s that, and also striking a balance between function and complexity.

[BigEd]

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.)

[plasmo]

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