RTL8019AS 16bit mode

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

I have built a device based on Renesas' H8/3068F and RTL8019AS. I have
connected the chips in the following way:
H8/3068F       RTL8019AS       Notes
--------       ---------       -----
A[0-9]         A[0-9]          other Realtek's address lines tied to GND
D[8-15]        SD[0-7]         D8<->SD0, D9<->SD1, etc.
D[0-7]         SD[8-15]
/CS4           AEN
/HWR, /LWR     IOWB            connected through HC08 (AND) gate
/RD            IORB
/WAIT          IOCHRDY         line pulled up through 10k
/IRQ0          INT0
               SLOT16          pulled down though 27k
In this HW configuration 8019AS has been working in 8 bit mode very well
for a few months.

Last week I wanted to test Realtek's 16 bit mode (i.e. word-wide
DMA transfers). The only change I made in the hardware was removing
27k resistor and pulling up SLOT16 pin through 360 ohm - just like in
a 16bit slot of a PC's motherboard. Then I switched MCU data bus into
16bit mode (by apropriate ABWCR register setting) and started playing
with Realtek's registers, especially with the bit WTS of the DCR.
Unfortunately, without success. When I read even address, upper byte
was expected register value and lower byte was 0xff. But when I read
even address, I always got 0xffff. The interesting thing is that 8019
still works well in 8bit mode when SLOT16 is pulled up.

Does anyone know how to force 8019AS to work in 16bit mode? I am
looking for any hints, source code, schematics, etc. Any help will be
appreciated.

Regards,
/J.D.
--
Jan Dubiec, snipped-for-privacy@slackware.pl, mobile: +48 602 101787

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Re: RTL8019AS 16bit mode
Quoted text here. Click to load it

In my experience, it's all in the software, and DCR bit 0 (WTS) is the
key.  I've left IOCS16 (SLOT16) floating with no effect (as have other
designs).  With as little as A[0-4], SD[0-15], IOWR, IORD, IOCHRDY
you're good to go.

Registers use 8-bit access regardless.  Have you tried your test with
the buffer ring instead?  Have you just tried a regular transmission,
sending 16 bits per I/O instead of 8?

As for init, the DCR value gets set immediately after after stopping the
NIC for 1.6mS to reset it.  Are you stopping the NIC first during init,
and are you waiting the spec 1.6mS before proceeding?


FYI, some suggestions to save MCU pins: you only need the lower 5 pins
to address the 8019AS; you can hardwire the rest unless you're using a
shared address bus.  Likewise, AEN can be wired low.  As long as you
don't strobe IORD or IOWR, you can share all the SA and SD lines with
other purposes.

For some schematics, you could check out the AVR implementation of the
RTL8019AS at http://www.picoweb.net among many others.  However, you'll
find that many implementations omit CHRDY wiring, which is hazardous.

http://www.edtp.com may also be a useful reference, as they sell 8019AS
proto boards.

Re: RTL8019AS 16bit mode
[.....]
Quoted text here. Click to load it
That's it! Thanks for the suggestion. Now 16 bit mode works very well.
Although I have found one strange thing which I cannot understand.
Assuming that during normal operation MCU's data bus width is 16 bit,
I have to switch the bus into 8 bit mode when accessing 8019AS registers
and then switch back into 16 bit. This is not a real problem because
such a switch is only one "set bit" or "clear bit" instruction (~ 90ns in
my system), but I consider it to be strange and non elegant.

Quoted text here. Click to load it
No, I hadn't. I had tested only byte or only word access to resisters/DMA
but not "mixed mode".

Quoted text here. Click to load it
Yes, I know those tricks.

Quoted text here. Click to load it
Yes, I know it. In my design I have connected this signal to MCU's
/WAIT pin in order to use MCU's bus controller features instead of
playing with IOCHRDY "manually" like it is done in other projects.
From my experience, I can also add that IOCHRDY has to be pulled up.
Without a pull up resistor I had observed really strange behaviour.

Regards,
/J.D.
--
Jan Dubiec, snipped-for-privacy@slackware.pl, mobile: +48 602 101787

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Re: RTL8019AS 16bit mode

Quoted text here. Click to load it

Not strange when you consider the part was designed for
the ISA bus.  When an 8-bit register was accessed, the
chip would de-assert IOCS16/ and the bus would automagically
run an 8-bit cycle.




Re: RTL8019AS 16bit mode
Quoted text here. Click to load it

Glad to hear it!

Quoted text here. Click to load it

No.  Just use 0's for the high byte during writes and ignore the high
byte when you do a read.  This works like a charm for me, so there's no
need to switch I/O modes.  Then again, I'm not using a memory interface
on the MCU, I'm bit-banging GPIO ports, so I might have more flexibility
in the handling.  I also enable pull-ups on the data ports during reads,
FWIW.


Quoted text here. Click to load it

The implementations I've seen have just been so slow in their I/O
routines that they never encountered the problem (though they will as
they upgrade to faster MCUs).  If you use tight I/O code, or a hardware
I/O interface that is even faster, you cannot ignore CHRDY.

Having a hardware WAIT line is a nice luxury; I had to use an ISR, but
it's still very efficient (particularly since CHRDY only gets pulled low
~10% of the time in my testing).


Quoted text here. Click to load it

Yes, I would expect so since it would float when not being driven low,
causing WAIT to be triggered incorrectly during non-blocked I/Os.  I
can't say I've seen this problem, since I used an internal MCU pull-up
from the beginning.


I'm very happy the suggestion helped.  Please post a comment on the
suggestion for 16-bit access to 8-bit registers - I'm interested to hear
if it works for you too.

Regards,
Richard

Re: RTL8019AS 16bit mode
[.....]
Quoted text here. Click to load it
[.....]
Quoted text here. Click to load it
It won't work. It's a shame - I have been working with this HW for over
three months, but just a few hours ago I found in the "H8/3068F Hardware
Manual" following information:
"The H8/300H CPU can access word data and longword data on memory, but
word or longword data must begin at an even address. If an attempt is
made to access word or longword data at an odd address, no address
error occurs but the least significant bit of the address is regarded
as 0, so the access starts at the preceding address. This also applies
to instruction fetches."

This is exactly what my tests have showed. Now all is clear for me. It
was quite interesting problem. ;-)

Regards,
/J.D.
--
Jan Dubiec, snipped-for-privacy@slackware.pl, mobile: +48 602 101787

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

Site Timeline