Ethernet interface for Particle using W5500 User Library Complete


Thanks for your quick response. Oh right, so you can attach an Ethernet port directly to the chip because it’s RMII compatible or something like that? Is the WICED stack that you’re talking about generic or device-specific?

My plan was to attempt to find the parts of the Photon’s firmware (found here: where Wifi is configured and attempt to make modifications to instead route Particle cloud traffic through this Wiznet Ethernet module I have (essentially what IOTrav mentioned but I’m using a W5100 instead of a W5500).

My problem is that there are so many libraries that I don’t know where to start. I guess looking through the WICED folder in that github link would be a good first step? Thanks for the heads up about the device ID needing authentication with Particle themselves and the WebIDE limitation


I am also heading down a similar path. @Maddy5075, would you be able to provide any further insight on how you edited the HAL and WICED stack? Thanks alot!


You should replace the wifi part with the STM32 ethernet driver to initialize the MAC, get ip via dhcp and use the sockets to create tcp connection and to send/receive data. Bit tricky, but very much doable if you spend sometime to understand the firmware architeture. It needs some minor changes to wiced stack as well.


Its a different MCU altogther (STM32F207), where as photon’s is STM32F205 without ethernet MAC. Yes it is RMII compatible. What you find in the hal directory are the wiced libraries. You ought to download the wiced stack and make some modifications as to hook the ethernet driver of STM32, compile/link and include these modifed library in the hal.

If you plan on using W5100, follow the steps and procedure what Travis has suggested.

In your case, initialise the W5100 and get the ip via dhcp or use static ip for now and make use of socket hal files to setup the tcp and send/receive data and not the one provided by w5100, instead make use of particle socket drivers.


In my opinion it is better off to use the shield and libraries what Travis has for you. Even if you are able to use W5100 or any other with Ethernet MAC, you cannot download any firmware over the air since Particle WebIDE restricts to do so and they are quite right as well in order to prevent the rogue devices to connect to their cloud. There is a strict process at particle and we have to abide that.


Okay awesome, this is seeming much more achievable now. I’ve actually finished writing libraries for the W5100 (which are very similar to the ones Travis has written for his Ethernet overlay shield) and it’s working with the Photon.

When you say “you cannot download any firmware over the air,” do you mean flashing firmware I’ve written for these third-party devices using the Particle WebIDE? At this point, like Travis I’ve only written firmware for the Photon itself, which uses SPI to read and write from the W5100 chip and this works fine

Or are you referring to the unique device ID again? If I were to build 5 of these boards that interface the Photon with the W5100, I would have to notify Particle of each of their device IDs so they can grant each of them permission to access the cloud right? I understand why they’d be reluctant to do this for multiple devices because of the reason you stated. Thanks again for the clear and thorough explanation though. I’ll share any progress I make


Yes you cannot OTA firmware from the WebIDE and the modified particle firmware doesn’t show up on the console and I reckon it wont even let you compile the firmware in the first place. And for the custom boards we have to use different Platform ID (unlike 6 as in case of Photon) and the device will be flagged as others in the console.


In your case it should work since you are not modifying the particle firmware and interfacing the W5100 using spark spi wiring.


Just curious, if you’re encountering these problems without using a photon, how come you didnt consider implementing ethernet on a photon with an ethernet module? Sounds like you wouldn’t have the Web IDE issues if you did.


The intention earlier was to make a device which behaves like a photon using ethernet instead of wi-fi. And there were couple of posts and suggestions to use STM32F207.

Refer this post


@IOTrav great work on the Ethernet Shield! I was fairly easily able to get it up and running with the TCP Server example. One thing I am a little confused about, however, is why we need to manually enter in a MAC address to use in the firmware byte mac[] = ... ? Doesn’t the W5500 have an integrated MAC, can we not just use that somehow? If we have more than one device, is manually changing the firmware for each one the only way to give it a unique MAC? Thanks!



I did not see where the W5500 had an internal Mac address so to my understanding it must be set. Now mind you that could be completely inaccurate :).


After further reading it looks like you are correct and the W5500 chip does not have an internal MAC address, sorry about that! The W5500.h library has a getMACAddress() function, but I think it needs to be set first before being read?

If we have a number of devices and would like each to have a unique MAC address, while using the same firmware in each device, any suggestions for how to assign the MAC addresses?


You are right, the Mac must be set first, then you can read it back anytime in runtime using the getMACAddress function.

I prove a good point though. I am not exactly sure what would be the best way to set unique Mac addresses on devices for a production run. Let me chew on that for a while and see if I can think of anything. Right now I am thinking the best thing you could do is to expose a function on the USB port of the Photon and send a MAC address in that way, then store it into EEPROM so it is retrieved at startup and used to initialize the W5500. If I come up with something better I will let you know.


Hey @IOTrav, have you had a chance to probe into this any further?


Hi @tommy_boy,

The best thing I can come up with is to use the MAC address of the photon module. I really wasn’t able to come up with anything better than that.


If you are making a product, the best thing to do is buy a range of MAC addresses from the IEEE.

A “small” block of 4096 addresses is US$705 at the time of this writing.


@bko is definitely right. That is the proper thing to do, and I would say pretty much required if you plan on selling a product based on the W5500.


I notice that although the ethernet.init(SS) call takes an argument for an alternate chip select, the actual calls to the hardware down in w5500.cpp are hard coded to A2.

I modified the source to run on another CS and all seems to work fine.

Is this an over-site, or am i missing something on my end?


This library was designed to work with our Ethernet overlay shield here:

Since our Ethernet module is hard wired to A2 for SPI select it only made since to hard code that pin. We were trying to develop a library which made using our Ethernet interface module as simple as possible to use rather than making it flexible enough to work with someone else’s hardware.