Ethernet interface for Particle using W5500 User Library Complete


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.


Were you able to get it working with SPI1? I have the NCD shield and using jumpers to try and use SPI1 instead of SPI. But after making the changes the A2 and SPI references to D5 and SPI1, I can’t get it to work.


Hi @Michael297,

Are you saying that you have the Ethernet Overlay Shield? If so it is hardwired to the SPI connections as documented by Particle here:

It is not possible to use our Ethernet Overlay Shield with SPI1


Yes I did. Search for A1 and change them all, plus the initial call. It is working for me.


You will have to rewire as well but I’m sure you know that.


The product says on it webpage:

“Does Not Yet Support Communications to the Particle Cloud”

What does this mean? If this gets the Photon on the network, why can’t the cloud be reached?


Connecting to Photon via Ethernet

Because you can’t tell the system firmware to use that application code library for its internal tasks.

Native cloud communication is a system task, not an application task. User applications can only use the dedicated functions to hand parameters to the system which in turn runs it through its own network stack.
There is currently no way to redirect the system to a different network stack than then one in its own bowels - you’d need to fork the system firmware and adapt that.


Thank you @ScruffR for your prompt response.

I do not understand though. The shield comes with TCP client/server examples. So can I use this shield to communicate to my own TCP server on a public IP address?

I thought this thread was no loner alive so I posted a separate post. I will try to delete it.


Particle Cloud communication is a very special kind of communication and has its own security layer. Without feeding the data through that, the Particle cloud will not accept the conversation.


I see. So what can this shield be used for? Just to communicate to another machine on a local hub using a local IP (

Thanks again.


I think you are confusing Particle Cloud and internet.

You can connect not only locally but also to the internet but you cannot talk to the Particle Cloud (a very specific target) with this.


Thank you @ScruffR, indeed I was. OK, it is clear now.

In my application, I do not need the Particle Cloud, so this is good news.

Thanks again and sorry for the double post.


Hi @IOTrav, overall your W5500 library has been working great, thanks again for the hard work on that!

However, I have now run into a difference between the standard UDP module and your EthernetUDP module, which is that the former includes methods joinMulticast() and leaveMulticast(), while the latter does not.

These methods are used for example in the MDNS library for Photon. I tried looking deeper into this myself to see if I could port the methods over but it led down a rabbit hole leading to wiced_multicast_join() within the Photon’s socket_hal.cpp which requires a wiced_wlan_interface() as one parameter. I wasn’t sure where to go from there.

Any ideas for how these methods could be added to EthernetUDP, or more generally how the MDNS library could be used with the W5500?



I think you can do this but you will get better advice over in the WizNet forum: