Hi @peekay123 and @fishstickjesus, just wanted to chime in to say this interests me too. I have a product that is normally most convenient to use with Wi-Fi, however in some circumstances it would be nice to have a wired ethernet option as a backup. I’d be happy to hear if you make any progress with porting the library and/or a roadmap for the most efficient way to accomplish this. I’ve never attempted any library porting, but if there’s something I can try to help with just let me know. Thanks!
@sddw - sorry for the slow reply. I am attempting to pick up where peekay left off. Will keep you posted on any progress we make.
2 Likes
I’m interested in this as well and have been checking up on the progress periodically. I read the thread on the core when it came about in the forums and hope to see it on the photon. I’d be interested in porting the arduino opc library
to the particle platform if possible and have several of these reporting energy usage on a factory floor. End product I’m thinking a POE photon reporting on AC current usage. But hey that’s just me.
@sddw Unfortunately I did not. My skills weren’t strong enough and we needed something in a hurry. Ended up pursuing an Arduino-based solution. However I would still love to see something like this come about. Would open up a world of opportunity in the industrial controls space.
2 Likes
Hi, I was wondering if anyone here had a solution for connecting a Particle Photon via ethernet rather than Wifi. Perhaps with an Adafruit breakout? Thanks, Sam
W5100 photon library. I was looking for this to use along with the arduino MUDBUS library for a modbusTCP bridge on the photon or electron eventually. i want to implement for the photon to publish data from legacy systems. is there a repository for it? i looked at your public stuff but did not find it…
@1bit, I partially completed the port for others to take and complete. I posted the code in my dropbox here if you are interested.
Thankyou, I got the folder and will have a look at it.
@1bit, when I ported the library it was meant to run as an independent user library with no integration with the Particle system firmware since it already has wifi/cellular network objects. As such, I had to rename all the “standard” network objects so they would not conflict with existing Particle objects. This was a “quick and dirty” approach to get something working without making major changes to the system firmware.
OK, And Thank you for the DIGOLE lib direction. I did buy maybe 8 of them to play with recently.
I have been poking around with this Ethernet issue for the better part of the day. (along with writing a bit of code for for a client.) and I think the ENC28J60 library will work more easily for this..issue ..GitHub - njh/EtherCard: EtherCard is an IPv4 driver for the ENC28J60 chip, compatible with Arduino IDE
Here is why:
the functions and classes were named differently already to coexist with most of the other Ethernet stuff. This would leverage that prior work. Also that board is very similar in function and pretty widely tested. Also it is very cheap. That library is pretty much gcc. I loaded all of the library stuff and it built fine in DEV along with the wire library and the Digole stuff and I also put in some other i2c and digital and analog components. That application compiled without complaint until I got into the PROGMEM bootloader and avr/io.h stuff. I also did port an example of one of my aps from MUDBUS to this library that I had bee using a while back. and that was easy.
As far as internal protocols go...industrial internal hardwired (or modbus TCP , S7, or CIP ) and whatever is the most reliable /secure commerce protocol for the mobile gadget world..... i am focused on the still growing industrial ethernet segment. .I also did port an example of one of my aps from MUDBUSand SNAP7 to this library that I had bee using a while back.
I only liked the MUDBUS because of the way I can handle the register tables and because it has proven very robust.
If I understand some of the other posts you have made on this topic regarding hardwired Ethernet and router capabilities of the time
Thisi s a relaed thread.....
then this MODBUS library may be worth my time to look into as it was made for the the cc3000 stuff...
Also look at Snap7 for Siemens protocol support....this WILL move here easily. I use that one on several platforms. even wireless as it is cleverly a push/publish type protocol and really puts the smaller processor in charge of what it CAN do, well suited for a connection dependent link.
It may end up that I knit a Teensy 3.2 or 3.6 to a particle ELECTRON as a "CELL PHONE" exchange bridge to a secure, external, protocol for the mobile user. If I go that way I can keep the hard real time stuff in the Teensy and treat the particle as another buffered Ethernet port.
After playing with the photon for a couple of days only,,,,I get a feel for it. The ELECTRON might have its hands full with a protocol conversion anyway and buffering anyway. The database size would be small atmost
255 holding registers (int)
128 input registers (int)
255 coils (bool)
255 contacts (bool)
maybe 2K-5k depending on buffering.
I have got them on a Nano with smaller structures and still have room to do useful stuff the teensy will plug into a nano form factor.
I would like to understand what tools can prioritze tasks on the particle; mission critical may need to be on a different processor. I do have a lieweight shceduler I use for the arduino and every task is looked at and the ones who need I/O gt it... but HARD I/O does real things and should preempt connectivity.
I guess I would look at having the particle as a SPI device to a Teensey if I cant have a Hard port on the PARTICLE. This would not require a PI or that level of OS i dont think at this point but I will go back to the office in berkeley an talk about it with my colleagues. We did have a meeting on the topic yesterday for a few hours.
Thanks ...
1 Like
@1bit, did you end up porting and using the ethercard library for the ENC28J60 to use on the Photon? If so, any chance you can make the ported library available? 
I took The idea that I wanted to send my small register database on demand over SPI to the particle. I am looking into the particle Electron as a paired up communications processor with a Teensy 3.2 or 3.6. Today I set up my Electron/Teensy testbed. If I run into trouble with that then I will go back to the porting route. I will however get some advice on the topic next week. That discussion may put me back on it.
I am playing with Teensyduino 1.31 beta#2 under arduino 1.6.12 . I am looking to put the electron on board optionally as a cell interface independent of the hard ethernet port…but I will look back at it…the library mostly was just having some macro work needed in the abscence of Arduino libraries. Let me look back at where I left it.
include i2c_t3.h is giving me some issues.
Hello @peekay123. I would like to take on the work you have done and try to finish it. My question would be, given that there is already a Ethernet Shield v2 will the port you have so far still work? Is the w5500 backwards compatible to the 5100? Or would I have to also port that as well. Seeing what you did with the 5100 it might not be difficult at all but doesn’t hurt to ask.
I would plan to make it work first as a user library rather than integrated to the firmware. Once it is working I would like work on it to add it to the firmware if it is useful.
New to the Photon particle and it would be my first port to it too, so guidance would be appreciated.
Thank you
@sensen88, part of the challenge with the original Ethernet Library was the conflict with the network objects in the library and the Particle firmware. Another member suggested using the ENC28J60 ethernet module instead. He found an Arduino library which was specifically designed not to conflict with other ethernet objects. I have ported the library but I haven’t tested it yet since I’m waiting on cheap module to arrive.
@peekay123 What did you do about the Stash in EtherCard.cpp??
I’ll burn a few of my Enc28J60 and invest a photon…if you need a guinea pig…this one should run at 3.3 V and plugs right into my utility boards…
@1bit, the RAM stash stays the same but I did my best to adapt the EEPROM code. Without an ENC28J60 and some testing, I can’t be sure it works.
I will have a couple of ENC28J60 boards in the near future and have photons to spare so I can join the testing process as well. If you can provide the code it would be great for testing. Though @1bit seems to have a better understanding of whats happening.