W6100 support and general dependance on lwIP

[veecle-stefan]

TL;DR: I'm trying to get the W6100-EVB-Pico board, an RP2040 and a Wiznet W6100 Ethernet chip, working with earlephilhower's Arduino core, but I’ve hit several roadblocks. Below are my findings and current challenges.

Hi everyone,

I recently got a couple of W6100-EVB-Pico boards, which are essentially Pico clones with an onboard Wiznet W6100 Ethernet chip. The W6100, though similar to the W5500, isn't register-compatible and offers hardware IPv6 support.

My goal is to use the W6100 with earlephilhower's Arduino core, but I've yet to find a compatible combination of drivers, cores, and libraries. Here's what I've attempted so far:

1. Current Core Limitations: The core in question supports the W5100 and W5500 via lwIP drivers, but there's no support for the W6100. The lwIP drivers in this core are not compatible with the W6100 source.
2. Official Wiznet Resources: Wiznet’s official site links to two repositories, neither of which supports Arduino (one is ARM Mbed, the other FreeRTOS).
3. Wiznet's Fork of this Core: I found a post on Hackster.io referencing a Wiznet repo with a fork of this core, including an adapted Arduino Ethernet library for the W6100. However, this repo hasn’t been updated in two years, and while the W6100 works with this library, a lot of bugs that have been fixed in this core in the meantime, don't work. For example FreeRTOS-related or OTA (littleFS) stuff doesn't work. I would much prefer not to use an outdated core of course.
4. Wiznet's Other Repo: Wiznet also maintains another repo focused solely on the Ethernet library. A specific branch for the W6100 compiles* with the latest version of earlephilhower's core, but it's completely independant of lwIP and only mimics the standard Ethernet class of Arduino. A lot of stuff in this core here seems to rely on lwIP, so many libraries like MDNS and OTA don’t work and crash as lwIP stuff results in a nullptr. Only those based on the Ethernet object function correctly.

So I'm now asking myself if there's merit into trying to port the /libraries/lwIP_w5500 to W6100, or if it's a more sane approach to greadually replace any code that relies on lwIP instead of Arduino Ethernet objects. I would personally prefer the lwIP way because then I'm not modifying too much of this core, potentially creating incompatibilities. For me, the 'software IP' stack is even an advantage as I can see wether the micro has crashed by pinging it - using the W6100 Ethernet driver, actually instructs the chip to offload TCP/IP+ICMP resulting in pings when the micro has already crashed.

*) To get this working, I had to manually resolve a duplicate LinkState enum definition, which requires cloning and modifying the repo locally rather than using it as a standard dependency.

I’m sharing this in the hopes of finding advice or a solution that integrates the W6100 with the modern Arduino environment. Any suggestions or pointers would be greatly appreciated.

Thanks!

[JAndrassy]

it is easy to write lwIP_w6100. just modify the lwIP_w5500

[veecle-stefan]

I've actually implemented a W6100 driver, derived from the W5500. It had some peculiarities that are different than the W5500.
But it is working! Finally, all the ArduinoOTA, lwIP, MDNS etc. is working (unlike with the Wiznet Ethernet library).

I'm currently doing some performance/stability testing and I hopefully have some time tonight to fork your repo and create a PR. If I don't manage tonight, It'll take until next week as I'll be travelling.

PS: I think the general lwIP wrapper is not well suited for the way Wiznet wants us to use their interrupt and register handling. For example, this is where the IRQ is handled:

arduino-pico/libraries/lwIP_Ethernet/src/LwipIntfDev.h

Lines 544 to 553 in f45db86

	err_t LwipIntfDev<RawDev>::handlePackets() {
	int pkt = 0;
	while (1) {
	if (++pkt == 10)
	// prevent starvation
	{
	return ERR_OK;
	}
	uint16_t tot_len = RawDev::readFrameSize();

Wiznet actually wants us to first check for the IRQ reason and then decide what to do (Receive packet, acknowledge successful send etc.). And based on that, de-mask the socket-specific interrupt mask clear register (Sn_IMRCLR) to acknowledge we've handled the IRQ. This seems a bit different to the W5500 where we could simple mask the IRQ and go ahead. I've now implemented the Sn_IMRCLR write to de-mask only the receive flag to acknowledge the receival

 // Clear interrupt flags
    setICLR(W6100_Sn_IRCLR_RECV);

And only allow receival interrupts to be firing by disabling everything else in the begin() method:

        // Configure socket 0 interrupts
        setSn_IMR(W6100_Sn_IMR_RECV); // we're not interested in W6100_Sn_IMR_SENDOK atm

        // Enable socket 0 interrupts
        setSIMR(W6100_SIMR_S0_INT);

        // Disable unused interrupts
        setIMR(0);

        // Enable interrupt pin
        setCommand1(W6100_SYCR1_IEN);

I think this is not the best/intended way, since the lwIP code calls RawDev::readFrameSize on every IRQ... But it works for now using this hack above.

[earlephilhower]

@veecle-stefan would you like to make a PR with it in the current state? "Not working optimally" is much better than "not working at all!"

I'm not sure I grok the difference in IRQ senses here, but there is a possibility of doing a template specialization for the specific chip/function to essentially override the packet polling in handlePackets with something more complicated.

[veecle-stefan]

sure, I did create a PR. Let me know if something's not working or I can test something. But I'll be travelling until next week and probably not have the hardware with me. Do you have a W6100 to test on real HW?

[earlephilhower]

Awesome, thanks! I unfortunately don't have a chip to try out, but if you've had success with the code and there are no CI issues then it's good enough to give it a release and see if there is +ve or -ve feedback. If things do crash and burn I'll see where I can find a board. They're really pricey from the CN disties, but if they're in stock Mouser has good prices...

[sstaub]

@earlephilhower You can buy the boards directly from WIZnet https://eshop.wiznet.io/?ckattempt=1 (for US)
The W6100-EVB-Pico cost about $ 10.-, the W6100-EVB-Pico2 is on the way and will delivered in September.

[sstaub]

There is an branch for W6100 there https://github.com/Wiznet/Ethernet/tree/W6100
It is very old and I don't know if it is well tested. The handling of the register is very different to the W5x00 chips because they are 16bit wide.

[veecle-stefan]

I realised that with the wider registers. But after my first half hour of despair, I stumbled upon the fact that appending (0x01) FixedDataMode1 to the block register byte forces the old-school 1 byte wide register 😎 So I didn't have to change too much of the W5500 code

[sstaub]

@veecle-stefan Good to know. Does IP6 also work?

[earlephilhower]

This hooks into the LWIP stack on the Pico, so IPV6 should work fine (when you select the IPV6 library option, of course!).