Realtime EtherCAT Master for Raspberry pi using W5500


Hello all,
I am using W5500 to build the hard-realtime EtherCAT Master for Rapsberry pi. If you are interested in it, check here:

Several demonstration videos:



The Raspberry Pi Zero board looks great. Is it open hardware?
Where is the source code for the W5500 driver located?
I’ve done a user-space implementation using the BCM2835 library ( I am eager to learn from your implementation.

Thanks, Arjan


Yes, the PiCAT board (the white board in rpi zero form) is open, I will transfer it to Eagle and make public soon.
Currently, I didn’t open W5500 driver yet. Basically it is also implemented in user-space using mmap to peripheral registers like bcm2835.
Thanks your interest!


Hi, what is the status of your project? I am looking into an option how to connect 2 W5500 to Raspberry Compute Module CM3 and use it for EtherCAT together with Codesys. Your driver or the PiCAT board design would help me a lot. Can you please share it? Thank you very much!



Hi Martin,

I’ve made my W5500 implementation available here ->

It runs on both Raspbian Linux and baremetal.



Sorry for late response, board design is available here


Hi @vanvught and @mophong,
thanks to both of you for your responses!

I looked at your implementations and although I am not a hardcore C developer nor a low-level Linux programmer I think that neither of your code is actually a kernel driver, which would make the W5500 accessible as a network interface. It is more of a library to be used in other solution. Am I correct?

The Codesys expects a network interface, such as eth0, for EtherCAT communication. Do you have some pointers of how to mangle your implementations into a kernel driver by any chance?

Thank you very much for a response and have a nice day,


Hi @Martin_Kudlacek

Yes, the solution is a library. It is not using any Linux (driver) code at all. This makes the solution easy portable to embedded systems (with no Linux). Moreover, it give a performance improvement not using Linux drivers.

There are Linux device drivers available here :


Hi Martin,

I have managed to get the linux kernel driver working with a dt-overlay. It took me a while to understand what to do (I’m still new to this stuff). Maybe this will help you (and others) with what I managed to find.

After searching a lot I came across an adaption made by someone for the beaglebone. which is “a hack for dt support for w5500” according to his own commit :).

Using this together with the attached w5500-overlay.dts (which is a copy and adaption of the encj28060-overlay.dts) I managed to get it networking to work with the w5500 chip.

With the kernel sources you can (re-)compile the kernel after replacing the w5100-spi.c file from above in linux/drivers/net/ethernet/wiznet/ with the following config added

With the attached w5500-overlay.dts you can create a the w5500.dtbo file and place that in /boot/overlays.

Getting it all to work is the same as for the enc28j60 (for example

I myself wanted to see what the performance would be using this kernel driver together with etherlab and the ec_generic driver. It actually sends frames to the slave (EK1100 in my test), but It doesn’t receive anything back. I’ve used @vanvught lib-wiznet code and examples to check and change settings, but haven’t found anything that worked.
Does anyone (@vanvught and @mophong maybe?) know why the frames aren’t received? I’ve kind of gotten stuck. Any help would really be appreciated!

Mark (663 Bytes)


@mpvmpv Hi Mark, I have just worked with the provided example and it is working fine. The ’ 14:Art-Net… …’ packages are received from an Art-Net controller. We need more information from you in order to be able to assist.


/development/lib-wiznet/examples $ sudo ./w5500_static_ip
–> src/bcm2835_prereq.c:bcm2835_prereq:40
<-- src/bcm2835_prereq.c:bcm2835_prereq:55
Interface :
Netmask :
Gateway :
MacAddress : 02:08:dc:ab:cd:ef
W5500 configuration
Interface :
Netmask :
Gateway :
MacAddress : 02:08:dc:ab:cd:ef 14:Art-Net… … 14:Art-Net… …


@vanvught Thanks for the quick reply. Sorry for the confusion I may have caused: I do have your example working.

I was changing the settings of the phy (force full duplex and 100mbit) and also changing socket settings by browsing through the code you provided. This I did to try and get the Etherlab to receive frames via the kernel driver I am using. ethtool doesn’t seem to support this chip (or maybe I have to do something in addition to what I have already done).

Anyway, the things I have played with haven’t helped. Etherlab is sending frames, and I can see activity on the LED of the EK1100, however, there are no frames being received.

root@rtpi:~# ethercat master
  Phase: Idle
  Active: no
  Slaves: 0
  Ethernet devices:
    Main: 6e:a3:44:75:dd:a8 (attached)
      Link: UP
      Tx frames:   1095
      Tx bytes:    65700
      Rx frames:   0
      Rx bytes:    0
      Tx errors:   0
      Tx frame rate [1/s]:     50     44     15
      Tx rate [KByte/s]:      2.9    2.6    0.9
      Rx frame rate [1/s]:      0      0      0
      Rx rate [KByte/s]:      0.0    0.0    0.0
      Tx frames:   1095
      Tx bytes:    65700
      Rx frames:   0
      Rx bytes:    0
      Lost frames: 1095
      Tx frame rate [1/s]:     50     44     15
      Tx rate [KByte/s]:      2.9    2.6    0.9
      Rx frame rate [1/s]:      0      0      0
      Rx rate [KByte/s]:      0.0    0.0    0.0
      Loss rate [1/s]:         50     44     15
      Frame loss [%]:       100.0  100.0  100.0
  Distributed clocks:
    Reference clock: None
    Application time: 0
                      2000-01-01 00:00:00.000000000

I was wondering if I need to set something specific in the HW, or that there may be a problem with auto-negotiation.
Once I get my hands on a hub I will be checking with wireshark.

Just something I just found in an application note for slave controller development:

3.10 Why must I configure the PHYs for auto-negotiation instead of forcing 100 Mbit+FD?
EtherCAT requires that the Ethernet PHYs are configured to use auto-negotiation, and not 100 Mbit +
full duplex in force mode. The reason is interoperability.
While two devices which are forced to 100 Mbit + full duplex (FD) are perfectly operating together with
EtherCAT, a problem arises if one device uses auto-negotiation, and the other one forced mode. In
this case, the auto-negotiation device will fall back to 100 Mbit + half duplex (HD), because it has no
knowledge of the capabilities of the link partner. The half-duplex operation can lead to communication
issues especially at the master, but probably also at the slaves. That is why auto-negotiation is
mandatory for EtherCAT PHYs.
Another issue is the Auto-MDIX feature of the PHYs, which often depends on auto-negotiation being
enabled. So, without auto-negotiation, some EtherCAT links would require a cross-over cable, others
a straight cable, which complicates the situation even more.
Refer to the AN PHY selection guide for more information.


Today I got my hands on an old fashioned hub and used wireshark. I managed to find out what was happening. When using the integrated usb NIC I saw that the EK1100 sends it reply with the source mac address the same as the masters but starting with ba instead of b8. When going via the w5500 and the default mac-address it has at start-up the EK1100 uses exactly the same source mac-address, which ofcourse the wx5500 will ignore… All I did was change the mac-address of the w5500 with ifconfig to a similar address as the integrated usb NIC and now it works!. I don’t understand why this is happening, but hey, that’s for another day maybe :wink:


Have you seen this commit ->

This replaces the need for using ifconfig. The root cause looks to me a bug in the driver with retrieving and setting the MAC address.

This adds support to specify the MAC address by ‘mac-address’ or
‘local-mac-address’ properties in the device tree. These are common
properties for the Ethernet controller.


Thanks for pointing that out. I will give that a try and report back.