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

[Tomohiro HARAIKAWA]

Dear Halald, 

> Problems with the LAN91C111 interrupts took all my attention.
> But it seems to work reliable now.

  Very attracting!

> 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 try to draft what I am planning and partially implemented now:

   1) NutRegisterDevice() => NutInit() calls NutNetLoadConfig() and 
      set up ifnet structure.  Then, reads the MAC from a 93C46 and 
      OVERWRITEs dev->dev_icb->mac[6] if the 93C46 exists.

        mac[6] contains:
          - Unique MAC address if the 93C46 exists.
          - Programmable MAC address in EEPROM if written.
          - egnite_null_mac (obsolete?) otherwise.

   2) IF A USER WISH TO PRIORITIZE EEPROM AGAINST 93C46, ADDITIONAL 
      NutNetLoadConfig() CALL HERE ALLOWS TO DO THAT.

   3) NutDhcpIfConfig()/NutNetIfConfig() starts the reciever thread 
      and fires up the NIC with ifnet structure.

That is, the strategy I'm thinking now is RegisterDevice() offers a 
relevant MAC through dev_icb->mac[6] and IfConfig()s fix the MAC.


  A case analysis follows:

   A) NutRegisterDevice(); => NutDhcpIfConfig( , 0, );
        Typical application.  A 93C46 is prioritized over an EEPROM. 
        That keeps a compatibility with prior Nut/OSs, and allow us 
        burning same binaries.  Applicable for 93C46-based mass pro-
        duction.

   B) NutRegisterDevice(); => NutDhcpIfConfig( , mac, );
        The other form of typical application.  Individual binaries 
        are used.  Compatible with prior Nut/OSs.

   C) NutRegisterDevice(); => NutNetLoadConfig(); => NutDhcpIfConfig();
        Particular applications like a router.  Usually 93C46-based 
        MAC is used but it is also programmable.

The drawback of this way is that mac[6] is no more usable as a mark.
I need one event flag in dev_icb; it also eliminates the polling.

> Are you able to determine, wether an EEPROM is attached or not?

  Yes.  According to the referencial design of Realtek, a JP pin of 
RTL8019AS should be explicitly or implicitly pulled up when a 93C46 
is installed.  We can check the existence of a 93C46 by referencing 
a JP bit of CONFIG0 register in RTL8919AS, because the JP pin is ex-
plicitly pulled down in the schematics of original ethernut boards.

With my respect, 

---
Tomohiro Haraikawa
Faculty of Information, Shizuoka University
E-mail: hal at cs.inf.shizuoka.ac.jp