2nd ENET

[leutholl]

Hi and many thanks for the wonderful library!

I'm playing around with a MicroMod Teensy and have routed the 2nd ENET pads to a LAN8720A PHY which is configured to receive the clock. This pretty much follows that connection. On a MicroMod only the 2nd ENET pads are exposed on the M2 connector.

How can the library be configured to use the 2nd ENET interface? Some pointers would help me. I'm happy to share my MicroMod Teensy adaptions and hardware hookup here in return.

[ssilverman]

You will have to write a driver for it. There’s some instructions in lwip_driver.h. You can also follow the other two driver implementations as examples. I too wouldn’t mind seeing MicroMod support.

Basically, it all boils down to implementing all the functions from that header.

[leutholl]

I was afraid it’s that big. I was hoping that only some parts of the original T41 driver must be modified and was hoping for some hints where that would be. Should the pad redefinition be enough?!

I think nobody has done it so far….

OK let the journey begin. Thanks

[ssilverman]

It’s a different PHY chip, and probably has a different usage. (I haven’t read docs for that one.) If you’d like to send me some hardware, I could maybe have a look at what’s required, depending on my availability.

So far, I’ve been working on this library because I’m using it and needing it myself, which partly drives how I develop for it.

[ssilverman]

It’s also very possible that the implementation won’t be too hard to adapt from the Teensy 4.1 driver, since there’s the standard RMII interface.

I think I was seeing it from the point of view of interfacing with the Teensy 4.1 MAC itself, and contrasting it to my SPI-based W5500 driver. When I think about it more, in fact, I’d be surprised if it was very difficult. I’ve just learned, over my career, “never to assume easy.” :)

[leutholl]

I totally agree. the PHY should be compatible straight forward, the registers are de-facto standardized it seems and RMII is RMII with the exception of the clock but the PHY is teensy friendly configured to receive the clock.

So it should boil down to change the pads and maybe the MUX in lwip_driver.h/cpp to use ENET2. That's where I might need help to understand what code can stay and what not. I will give that a try later today. I live in Europe and assume you're US based, not sure if sending HW is meaningful as it should be software only by now. I made a carrier board with PoE Ethernet and all sorts of peripherals. The nice thing of the MicroMod is that it exposes FlexIO 2 pins + ENET2 + Can + 2x I2C + UARTs etc.... this together with a carrier board makes it pretty cool. The board is 22mm x 22mm - and it's really small.

will let you know when I have some progress.

[ssilverman]

My thoughts on developing for hardware, eg. drivers: I disagree that it’s “software only”. It’s hard to develop software for hardware without the hardware.

[leutholl]

that's for sure. I also need the hardware.
After investing well over 12 hours I found a routing problem on my pcb which destroys the MDC and MDIO signals - I misunderstood a reference table from the internet that I took while routing the pcb but now I see what the IOMUXC_SW_MUX_CTL_PAD with ALT8 can connect to. So I need to create my next revision of my PCB and should be must closer then.

I guess I have a basic understanding of how to port FNET to be using ENET2. It's not so straight forward as I thought but it should be possible and my hardware issue didn't help studying the code.

I need to pause this thread until I have a new revision of the pcb or I can hack something on my faulty pcb which is what I will try tomorrow, some jumper wires might give me luck and might continue the software side.

[ssilverman]

The QNEthernet library uses lwIP under the hood. I’ve already done the hard porting and integration work, and if one implements all the lwip_driver.h functions (these are my definitions), the library will just work. (That is, using an Arduino-style API.)

[leutholl]

yes this is what I will do right now. Using FNET and my two jumper wires to mitigate the pcb layout mistake, I can get link up/down.
The base address of the register for ENET2 has an offset. So this also needs to be done.
I'm confident that I can reach the goal now without waiting on a new pcb.

[leutholl]

success! I managed to get ENET2 working on MicroMod with a LAN8720A PHY. I will also design a custom board with a DP83825IRMQR PHY (the same as on the Teensy 4.1) which needs less external components (the mdi is voltage driven and it doesn't need external resistors) and it also needs other register and strap config.
For the LAN8720A an additional RESET line is needed that the main program should set towards QNEthernet. For the DP83825 two additional lines are needed. This is because on the teensy 4.1 onboard PHY these lines are predefines whereas on MircoMod the user can pick any two GPIO pins that are available on his project. The pins used on the 4.1 board are not brought out on the MicroMod so a value of the pins must be set and we can't assume defaults. For the LAN8720 with 1 RESET line I was tempted to use driver_set_chip_select_pin() which is available on the driver interface but maybe we should support Varargs on the init() to take all the pins depending on the PHY. This is a minor work put best in the hands of you as it changes things outside the driver folder.
Also I created a #define QNETHERNET_INTERNAL_DRIVER_TEENSYMM guard on my additional driver file driver_teensymm.c and driver_teensymm.h.
Then in lwip_driver.h the driver selection was extended to:
// Select a driver
#if defined(QNETHERNET_DRIVER_W5500)
#include "drivers/driver_w5500.h"
#define QNETHERNET_INTERNAL_DRIVER_W5500
#elif defined(ARDUINO_TEENSY41)
#include "drivers/driver_teensy41.h"
#define QNETHERNET_INTERNAL_DRIVER_TEENSY41
#elif defined(ARDUINO_TEENSY_MICROMOD)
#include "drivers/driver_teensymm.h"
#define QNETHERNET_INTERNAL_DRIVER_TEENSYMM
#else
#include "drivers/driver_unsupported.h"
#define QNETHERNET_INTERNAL_DRIVER_UNSUPPORTED
#endif // Driver selection

When I have a clear guideance on how to manage the additional user pins, I can push my code.

[ssilverman]

What is the function of the two additional lines you mention?

[leutholl]

The user defined Reset Pin and on the TI PHY additionally a POWER UP Pin that must be toggled by the driver at the right moment. Both lines exist for the T41 and are hardcoded due to the PHY being onboard and predefined Pads. But on MicroMod the library must respect user defined GPIO Pins for these two funtions.
I‘m in the process to design my other board with the TI PHY, will then adapt my driver for the TI PHY and would expect user-defined GPIOs towards the library so the init() can toggle the lines correctly (timing matters here, so it can’t be in the main program)

[ssilverman]

The driver_set_chip_select_pin() function is there to support the Arduino-defined Ethernet.init(chip-select-pin) function. In my opinion, ideally, specific pin selections should be done at the driver level, but is a bit of a grey area as to where it should actually go, and sometimes there isn't a completely "correct" answer. I would probably start with something similar to what I do in the W5500 driver, where configuration is done in a file (see driver_w5500_config.h). It could also be done using defines or something.

[ssilverman]

My thinking is that the hardware is unlikely to change for a given project, and so it's okay to hard-code some of these values in some configuration file or header. I also think it's unlikely that runtime control is needed for this type of configuration.

[leutholl]

ok will do so

[leutholl]

Success #2.
I managed to get the dp83825i PHY working as well. This is the same PHY as on the T4.1. This PHY has a small footprint and is harder to solder down than the LAN8720 I used previous. But the PHY is better documented and it needs only a few external components which saves board space and keeps diff pairs better impedance controlled (it has a voltage source as a MDI driver). Two new pins need to be declared to reset this PHY correctly. So this points to the same question of above but I guess some project-level defines should do the job.
As soon as I have some time, I shall consolidate all my work and make it available.