AVR as UART/ACIA IC

[BigDumbDinosaur]

cbscpe wrote:

All these wait state generators generate a fixed predicted number of wait states. Has anyone a more bus related wait-state generator? I mean something like used in typical bus protocols where the CPU is always halted until a ACK signal is generated by the selected device (IO, Memory, ROM etc). Preferably the ACK should be a edge sensitive signal. E.g. in a PDP-11 system the CPU always stalled when performing a read or write until a CONT signal was asserted on the bus. Even Memory had to create the CONT signal.

Why would you need something like that?

[BigEd]

> Why would you need something like that?

Surely you'd need this in any system which a peripheral unable to clock at full speed. That's pretty common - but the usual workaround is to clock everything at the slowest speed.

[cbscpe]

Exactly I have the requirement that I have peripherals that do not responds with a known speed, but they known when they have finished the transfer. I want to avoid to use a VIA as these peripherals have a normal bus interface. On the other hand I want the system to run at maximum speed when it comes to memory access or when peripherals are accessed that support high clock rates. Clocking everything at the lowest common speed is definitively what I want.

[GARTHWILSON]

Quote:

Using a VIA to interface with the AVR is possible but very slow and it uses a lot of pins. Also it is not trivial to build a bidirectional bus between the AVR and the VIA, as each side decides on the direction of the IO pins. Instead of a VIA I would use something like the 74HCT652.

For saving pins, you could use the VIA's shift register. This post shows how to do it with two computers talking to each other through VIAs, and you can see how to do it replacing one end with your preferred microcontroller. OTOH, if you go through a VIA, why not just use an SPI-interfaced UART like the 14-pin MAX3100.

[BigDumbDinosaur]

cbscpe wrote:

Exactly I have the requirement that I have peripherals that do not responds with a known speed, but they known when they have finished the transfer.

Shouldn't you be able to start and stop the MPU via RDY, using glue logic to detect the peripheral's status?

[cbscpe]

Let's say you want to interface a fast running 65C02 with all the IO features of a AVR (using the AVR as peripheral, not only the USART). So as soon the IO selects the AVR I need to assert RDY (=low) and wait until the AVR did what he should do. Typically it would just pass through the byte from/to the selected internal register to/from the 65C02 data bus. When he did it's job the AVR needs to tell the logic that keeps RDY asserted that it's done. You could use a pulse generated by the AVR to clear the RDY status. But the shortest pulse you can generate is 50ns with an AVR running at 20MHz. But you must make sure that the pulse is finished before a low-to-high transition of PHI2 because when you de-assert RDY before PHI2 transitions from high-to-low this low-to-high transition could be another access to the AVR and then the logic that asserts RDY must not be disturbed by a still lasting clear pulse from the AVR. Else the 65C02 will run over this cycle without that the AVR would have don it's job. This limits the clock speed of the 65C02 to approx 10MHz. But I want go much faster. I could somewhat alleviate the requirement by saying that there are no 2 consecutive cycles that access the AVR, but then I loose the option to provide instructions from the AVR to the 65C02. You might say, that this would be very slow, but on the other hand, if I use this only to download a ROM image, speed for this phase does not matter.

The reason I would like to do so is that with that I only need a 65C02, a fast RAM, some glue and a AVR and would have a very small system with a lot of IO features.

What I would need is equivalent of a D-type FF with the IO select connected to the D input and PHI2 connected to clock, this would provide the logic to assert RDY when required, and then I would need a edge triggered input to de-assert RDY again and not the typical level triggered clear/set inputs of a 74xx74.

[GARTHWILSON]

The many wait states that would be needed in any I/O intensive situation sound like quite a performance killer. To read a status register or port for example requires the microcontroller to go through its interrupt sequence (which someone said was 7 cycles on the AVR), then negate RDY, decode the "register select" as an instruction, fetch the contents of the desired register, and put them on the 6502's bus, bring RDY back up (assert it), then do the return-from-interrupt before it's ready to start the process over again. R-M-W instructions might be totally out of the question. Doing the other things on a polled basis (to avoid the interrupt overhead) may not allow doing other things the AVR needs to do. Going with dedicated parallel I/O ICs of even other families sounds like a much better solution. I believe BDD likes the 28L92.

BTW, RDY is a positive-logic signal. Pulling it down constitutes negating it, meaning "No, I'm not ready to move on. I need more time." High (asserting it) means, "Yes. Ready. Go."

[Dr Jefyll]

cbscpe wrote:

You could use a pulse generated by the AVR to clear the RDY status. But the shortest pulse you can generate is 50ns with an AVR running at 20MHz.

I modified one of my other wait-state diagrams, Peter -- see what you think of this (below). This will tolerate the 50ns pulse lagging into the following 65xx cycle, so it offers faster operation than your 74xx74 solution. OTOH I'm not 100% convinced the "problem" needs to be solved! Perhaps you've already considered this. If you're willing to avoid 65xx R-M-W operations on the AVR, then any 65xx access to the AVR will be followed by at least two non-AVR accesses. The 65xx will need to fetch its next instruction, so you're guaranteed to have several cycles of delay before another AVR access.

AVR wait-state generator.gif (3.63 KiB) Viewed 5900 times

GARTHWILSON wrote:

BTW, RDY is a positive-logic signal. Pulling it down constitutes negating it, meaning "No, I'm not ready to move on. I need more time." High (asserting it) means, "Yes. Ready. Go."

I agree, Garth, but I think the explanation can be made even plainer:

• asserting a signal called READY means, "I am ready"
• negating a signal called READY means, "I am not ready"

IOW "assert" means "do what the English word says." Negate means do the opposite. Notably, this requires no consideration of active-high versus active-low.

Active-high or active-low is a secondary detail, and it doesn't change the rule. "Assert means do what the English word says." At least that's how I keep myself from muddling things up!

-- Jeff

[BigDumbDinosaur]

GARTHWILSON wrote:

Going with dedicated parallel I/O ICs of even other families sounds like a much better solution. I believe BDD likes the 28L92.

The reason devices such as UARTs exist is they do very efficiently in hardware what a microcontroller less efficiently and more slowly in software. Even non-65xx peripheral devices are relatively easy to interface to the 65xx bus. In my case, I prefer the UARTs made by NXP, having used the 2692A, 26C92 and 28L92 dual channel units in my POC units, and in the past, the 2698B eight-channel UART. Currently, POC V1.1 has a 28L92 installed. POC V2 will have a 28C94, which has four channels.

[BigDumbDinosaur]

Dr Jefyll wrote:

I modified one of my other wait-state diagrams, Peter -- see what you think of this (below).

The only thing I'd add to that circuit is a small Schottky diode in between the flop's Q output and the MPU's RDY pin, as RDY is bi-directional.

[cbscpe]

GARTHWILSON wrote:

The many wait states that would be needed in any I/O intensive situation sound like quite a performance killer.

Depends how you do it, I naturally also thought that a select would cause the AVR to enter a interrupt routine. But this is not necessarily so. You could also poll the CS signal. Then you need to read the relevant address bits and RW status and jump to the appropriate routine, using a 256-instructionword aligned jump table would use only very few cycles

Code: Select all

	ldi	zh, high(iotable)


	cbi	PIND, DONE		; Prepare for next IO
	sbic	PIND, CS
	rjmp	housekeeping   ; If you want something be done, else it's just jumping to the cbi
	in	zl, PINA		; Assume we read A0..A6 and RW with this
	ijmp


	align	8	
iotable:	
	rjmp	readioreg
	.
	.
	.
	
	rjmp	writeioreg
	


readioreg:

thats only 7 cycles. Then you do your task, that is transfer the byte from/to the register to a buffer (e.g. a 74HCT652 type interface between the 65C02 and the AVR). In other words a non-disturbed IO read/write
would take about 20 AVR cycles. Michael's 3-chip design uses 16 AVR cycles to do everything a 65C02 expects to happen in one PHI2 cycle. When you think about the number of IO access a IO routine does in relation to the code it must execute (LDA ioaddress and a Bxx LOOP) the relative performance degradation is not that that important. Imagine that a 20MHz AVR would only throttle systems running at more than 1MHz and only during AVR IO cycles. In a typical application only a few cycles. If you are doing some real-time stuff and require a lot of IO cycles due to your system requirements, then this is definitively not the solution. So whether the performance penalty is relevant or not depends a lot on your application.

GARTHWILSON wrote:

BTW, RDY is a positive-logic signal. Pulling it down constitutes negating it, meaning "No, I'm not ready to move on. I need more time." High (asserting it) means, "Yes. Ready. Go."

Yes of course, I got it all messed up. Thanks for clarifying.

Dr Jefyll wrote:

I modified one of my other wait-state diagrams, Peter -- see what you think of this (below).

Jeff, thanks a lot, looks promising. Just that with J=H and /K=L the ff will toggle, so I will probably add another flip-flop between DONE and J to limit the DONE=High time to one PHI2 cycle. But the good thing about your approach is that each state change is synchronous to PHI2 and that is what is important in such a circuit.

BigDumbDinosaur wrote:

The reason devices such as UARTs exist is they do very efficiently in hardware what a microcontroller less efficiently and more slowly in software.

Contrary to the subject of this post (which was not started by me btw.), I'm primarily interested in the following IO features of the AVR: I2C, SPI, ADC, Timers with PWM outputs. The USART is interesting because of it's synchronous mode. So you can connect a PS/2 keyboard and a Mouse and the USART does all the frame checks (start-bit, parity-bit, stop-bit). Also using the USART of the AVR we do not do anything in software related to the RS-232 protocol. The only difference in efficiency comes from the fact that a read/write to a register is slower than that of your preferred UARTs.

BigDumbDinosaur wrote:

The only thing I'd add to that circuit is a small Schottky diode in between the flop's Q output and the MPU's RDY pin, as RDY is bi-directional.

Yes of course and also the pull-up should not be to weak.

[Dr Jefyll]

cbscpe wrote:

Jeff, thanks a lot, looks promising. Just that with J=H and /K=L the ff will toggle, so I will probably add another flip-flop between DONE and J to limit the DONE=High time to one PHI2 cycle.

You want the flipflop to toggle then, as I think you know. Yes there are limits on the max and min duration (measured in 65xx clocks) that DONE may be high. Still, I have a feeling the limits may be acceptable as-is. If not, they could be extended with another FF as you say. (As-is, the min duration is one 65xx clock plus a few ns for setup time. The max duration would depend on whether R-M-W instructions will be applied.)

Another suggestion, just to stir the pot... The need for wait-states -- and some of the performance compromises mentioned -- would disappear if you used a registered bus transceiver (such as 'hc646) as the connection point between the 65xx and the AVR. Each processor would be able to leave a one-byte message for the other -- then continue with its own business immediately.

[GARTHWILSON]

What we need is something like the WSI (Waferscale Integration, Inc.) WSD3XX family. I remembered this in a 1992 WSI data book I have; but looking them up online, it looks like they were bought out by ST Microelectronics (formerly SGS Thomson), who later dropped the line. WSI made these ICs that had RAM, ROM, and I/O all in one IC, to connect to a microprocessor. I suppose that idea went out as microcontrollers took over. They were definitely not ubiquitous yet in 1992, and the options were quite limited, especially if you couldn't afford to get masks made for your program.

[BitWise]

Several PICs have an 8-bit 'parallel slave port' (PSP) that interfaces with a microprocessor bus (e.g. with /CS, /RD, /WR lines) but on the 16F and 18F devices you only get one addressable location.

Some of the 3V3 16-bit PICs have a 'parallel master port' (PMP) with either a legacy PSP mode with optional 4 byte deep fifos (for both read and write) or a single an enhanced PSP mode that adds two address lines so you can have four memory locations.

In your code you latch the state of each location and an interrupt occurs when either the value has been read or overwritten by the bus owner. You must code the interrupt processor to process the read/write and update the latch before the next access. On 18F and PIC24s you can prioritize interrupts to make sure this is as fast as possible.

I've been meaning to try using them in a circuit. Only having a single location makes the 16F/18F PSP seem a bit limited but you could use a VIA driving other PIC input pins to indicate if the access is for data or control operation and check in the interrupt handler.

[cbscpe]

Dr Jefyll wrote:

Another suggestion, just to stir the pot... The need for wait-states -- and some of the performance compromises mentioned -- would disappear if you used a registered bus transceiver (such as 'hc646) as the connection point between the 65xx and the AVR. Each processor would be able to leave a one-byte message for the other -- then continue with its own business immediately.

This does not work for reads. Let's assume you want to read the status register, so you first need to inform the AVR that you want to read a register and then read the register. Of course the cycle to exchange the byte via the registered bus transceiver does not need to wait. But the protocol overhead will kill you. I'd rather take a 30MHz X-Tal for the AVR to speed up things (which I eventually will do anyhow )

BitWise wrote:

Several PICs have an 8-bit 'parallel slave port' (PSP) that interfaces with a microprocessor bus (e.g. with /CS, /RD, /WR lines) but on the 16F and 18F devices you only get one addressable location.

Yes that's the issue no addresses.