Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

<-- __Chronological__ --> <-- __Thread__ -->

Re: RTL8019AS 16bit mode



Jan Dubiec wrote:
> That's it! Thanks for the suggestion. Now 16 bit mode works very well.

Glad to hear it!

> I have to switch the bus into 8 bit mode when
> accessing 8019AS registers and then switch back
> into 16 bit.

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.


> > However, you'll find that many implementations
> > omit CHRDY wiring, which is hazardous.
> 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.

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


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

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



<-- __Chronological__ --> <-- __Thread__ -->


Usenet.com



Please check out one of the premium Usenet Newsgroup Service Providers below for access to Usenet.