[En-Nut-Discussion] Re: CHRDY handling in Ethernut

[Spam Filter]

Richard,

I forwarded a copy to the Ethernut mailing list and
hence removed all references to our previous private
emails.

I created several code prototypes and implemented all kind
of ideas from colleagues, but finally had to scrap CHRDY
handling.

By default Ethernut uses address and data bus to access the
RTL8019AS. The RW signal is controlled by the CPU. However,
the ATmega128 offers the ability to switch these lines to
be controlled as port bits. This would add some initial
overhead, but that is bearable. Most CPU cycles are used
in the inner loop, where bytes are transfered to and from
the Ethernet controller.

However, running that loop with memory mapped access or port
access makes a very big difference. Port access is much
slower. Memory access uses a single ldd, while port access
needs at least 3 instructions:

   1. set control lines
   2. read byte
   3. reset control lines

As you mentioned, this could be further decreased by using
16-bit access. But still it's 50% more cycles, which may
reduce the overall performance by at least 25%. When further
optimizing the remaining code, the ratio will become worse.

I agree, that 16-bit access would enable another 8 kByte of
buffer in the Realtek, but at the cost of 8 additional port
bits. In many applications these port bits are simply not
available.

While further experimenting with the prototype versions, I
got the experience, that the current driver handles high
traffic situations quite well. It looks like the Realtek
doesn't get corrupted by terminating the write cycle to early,
but by introducing a new write cycle to early, if CHRDY had
been signaled on the previous cycle. With typical code this is
not the case, because pointer incrementing and loop counting
add extra cycles. It would be a problem only if DMA is used.

Anyway, the many hours I spend on this were not totally wasted.
I discovered, that bit 0 in the packet status word can be
ignored. After adding this modification, the driver discards
less packets and the TCP stack becomes much more responsive
under heavy traffic.

IMHO, your proposal may make a lot of sense with specific
applications and is most useful, if you are already using
port access. For Ethernut it would require a mayor redesign
of the hardware, occupy additional port bits and reduce the
Ethernet bandwidth.

I'm expecting your protest.

Regards,

Harald