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.
@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.
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.
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.