I was hoping the shield would utilize the 2nd SPI port instead of the 1st SPI port on the analog pins. Could a possible future implementation use the digital pins instead?
That is absolutely possible but would require designing a new board. In hind sight it would have been nice to have on board jumpers for between the two.
Thats a great idea!
Which files in particular did you have to modify? Are they in the WICED folder here: https://github.com/spark/firmware/tree/develop/hal/src/photon? I’m trying to do the same thing using the Photon and a Wiznet module which uses the W5100.
I’ve managed to connect to hosts using their server names and send HTTP requests but I’m stuck on the next step of actually incorporating this into the Particle firmware. Any help would be appreciated
Owen, the setup we had was entirely different. It was STM32F207 with its built in Ethernet MAC which was used to connect to cloud. This needs modification in HAL and the wiced stack. You can use the stack available at cypress developers site. And to authenticate the device to connect to cloud, you ought to share the device unique ID with particle folks and they shall grant the permission.
Note you can only view the device on console and you can’t use the WebIDE to download the firmware.
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: https://github.com/kbowerma/particle/tree/master/photon_firmware/firmware/hal/src/photon) 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.
@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.