[En-Nut-Discussion] temporary hack in the thread NicRx

[Harald Kipp]

Dear Tomohiro Haraikawa,

Problems with the LAN91C111 interrupts took all my attention.
But it seems to work reliable now. This response is not only
related to your post, but contains some general statements
about the status of the stack.

>   Additionally, as you may be aware, the NIC is immediately started
>if NutRegisterDevice() => NicInit() => NutNetLoadConfig() succeeded.
>Thereafter, if the MAC is supplied through NutDhcpIfConfig(), it is
>never passed down to the NIC registers and ethernut confused by two
>different MACs will not work properly.
>
># This might not be a serious problem because the MAC once supplied
># through NutDhcpInConfig() is stored in EEPROM and they supply the
># same address from the second boot.

What I did now: NutInit() resets the controller, returning an
error if it's not there. Otherwise it starts the receiver
thread. This thread polls for the MAC address until it's not
all FF. This polling is still bad, but acceptable for now.
NutDhcpIfConfig()/NutNetIfConfig() reads the EEPROM configuration
only, if no MAC address parameter has been supplied. It copies the
MAC address into the nif structure. This lets the receiver thread
fire up the NIC. I guess that this is the point to add your
EEPROM support, but not sure. Are you able to determine, wether
an EEPROM is attached or not? Should be possible, right?
I'd like to support this, because there is a growing interest
in the Low Cost ISA Board solution.

I'd prefer to have an ioctrl interface similar to PPP, which
avoids the bad polling. But time is running away and I need to
implement and test the patch from Richard Hornbaker next,
before checking in a new release. This patch will significantly
improve the RTL8019 transfer under heavy traffic.

I also redesigned parts of the TCP data buffering to avoid
copying the data two times. so_rx_buf is now a NETBUF queue.

Kind regards,

Harald Kipp