I have all the HW to test it…and some ready made testbeds…I do have applications for this.
1 Like
@1bit, do you need the ported library?
I would be glad to use it and provide discussion here for all to use. Does it have a home?
@1bit, I’m just porting a few of the examples. As for the stash, I am not yet confident whether it will work or not. Once you test the examples, I’ll port the stash test and you can try it then. Stay tuned.
1 Like
Hi all, we just started following this thread. We want to add an ethernet shield to particle electron so that we can communicate with a PV inverter over modbus tcp/ip. The particle then becomes a modbus master…
We want to use this modbus master library: http://myarduinoprojects.com/modbus.html
I’ve uploaded your zip file to github with the necessary manifest so that it can be uploaded in the particle IDE: https://github.com/alex254/ethernet
Peekay123 feel free to add your email to the manifest.
When I import it in particle IDE we are running in compilation errors. It seems that Client class is also still conflicting with an internal spark class.
Anybody have experience with Enc28J60 yet?
Alex
@alex254, I ported a library for the ENC28J60 module that I haven’t tested yet. The network objects were designed not to conflict with other network objects so it is a good library to test. The library also uses a “stash” which is meant to use EEPROM. I am not confident with my port on this part of the code and I am waiting on the ENC28J60 modules I ordered to test. If you want to play with the library, you can find it here:
The .ino files are the examples so only use one at a time. I suggest you compile with the latest Particle CLI and put all the files in the single directory. Let me know how it goes!
1 Like
@peekay123 hello,i have used the library that you shared on dropbox and it compiled without any error and executed one of the example but without any output.
I have connected the ENC28J60 module on SPI1 i.e A2 to A5.
Can you please suggest necessary changes in firmware?
@dpk9170, in your application, SPI referes to SPI1 on pins A2-A5, and SPI1 refers to SPI3 on it is on pins D2-D5.
I never tested the library and the ENC28J60 modules I ordered from China never arrived. Until I get a module, you are the first to test!
Hi guys,
What’s the current status of the ported ENC28J60 library? Did anyone have a chance to play with this?
Wow this i really like because this so good
@peekay123 I’ve just hooked up the ENC28J60 module to the electron board. ENC28J60 board is conneded to electron’s SPI eg. SI to A5, SO to A4, SCK to A3 and CS to A2.
I gave a try to the simplest example that is backSoon.ino compiling locally against 0.6.1 firmware. Code indeed compiled without any major issues. I just had to change the line initializing the EtherCard and pass explicitly the CS pin this way:
ether.begin(sizeof Ethernet::buffer, mymac, A2)
Without CS pin set explicitly there simply was no communication with the module.
Then I tried to use DHCP but it failed. There were no packets on the wire. It turned out that ENC28J60::isLinkUp() returns false all the time irrespective to the link state.
bool ENC28J60::isLinkUp() { return (readPhyByte(PHSTAT2) >> 2) & 1; }
I played with manually setting speed and duplex on my PC but with no luck. According to PHSTAT2 register the link is down.
Is there anybody willing to share experience and some tips regarding further troubleshooting?
I gathered some more intelligence around this topic. I’ve tried to connect the ENC28J60 module to Arduino Micro and it worked perfectly. Thus there’s no problem with the module itself. I powered the module from 3.3V, but Arduino Micro runs on 5V logic while electron runs on 3.3V. I don’t know if this is important or not.
Nevertheless this experiment leaves me with the conclusion that the issue is related rather to the ported library and not to the hardware.
Looking forward for any comments on this.
@gkujawsk, I JUST received the ENC28J60 modules I ordered last December!! Thanks for the great work. One big thing I noticed is that the module has an operating current of 180ma when transmitting and 120ma when idle. This current is NOT available on the 3V3 pin of the Photon. As such, a separate 3.3v LDO is required to power the module. I’ll be testing with a protoboard power supply.
In short, I believe this to be the real problem though there may be little things needing to be tweaked in the library. 
@peekay123 I indeed didn’t check power draw, but I’m afraid that this is not the issue here. According to the arduino micro datasheet maximum power draw on 3.3V is 50mA but still the module worked for me. I used the EtherCard lib you’ve ported and I was able to get the ip address from DHCP and even get the response to ping request.
I just tried to power up the module from arduino 3.3v and connect SPI to my electron board and again isLinkUp() method returns false.
I’m courious if in fact powering module from separate 3.3v with enough power will actually resolve this link state detection.
@gkujawsk, I’ll be playing with the module this week so I’ll let you know what I find.
1 Like
In case somebody follows this topic. So far I can confirm that the module initializes itself properly. I was able to read the revision number from the chip too. Thus the SPI bus seems to be working ok.
I still didn’t receive 3.3v power regulators, so I couldn’t check the behavior with the external power source. However, according to the datasheet electron’s 3.3v is able to provide up to 800mA so I believe that power is not the issue here.
–
/G
4 Likes
@gkujawsk, I couldn’t get my ported library to work. I tested the module with an Arduino and it works so now I am going back to the original code to restart the port. 
@gkujawsk, using Serial.prints to compare the data going out on the Uno versus the Photon, everything is exactly the same until DHCP hits the “isLinkUp()” function. At that point everything but the final byte of the readPhyByte() function call is the same. On the Arduino, the return of “isLinkUp” is 0x04 on the first call. On the Photon, the return is 0x00 and continues on subsequent calls. I tried injecting delays in case the Photon was too fast but had no success. I even tried slowing down the SPI speed, again without success. So the only difference besides the 5v logic of the Arduino may be found in SPI timing. I’ll need to break out my logic analyzer to probe both boards to see what the difference is, if any.
1 Like
@peekay123 thanks for checking this out! My experience is exactly the same. I just ordered the logic analyzer too 
My other observation is that in the initialize procedure for this chip there are some register writes that set up the MAC address.
writeRegByte(MAADR5, macaddr[0]); writeRegByte(MAADR4, macaddr[1]); writeRegByte(MAADR3, macaddr[2]); writeRegByte(MAADR2, macaddr[3]); writeRegByte(MAADR1, macaddr[4]); writeRegByte(MAADR0, macaddr[5]);
I tried to read the same registers after these writes and all I get in return are zeros, which suggests that something’s wrong on SPI bus. On the other head readRegByte(EREVID) indeed returns the revision number, which proves that there’s SPI communication. I cannot logically arrange these two contradicting facts ;(
–
/G
1 Like
@gkujawsk, I didn’t try reading back the MAC but I did slip a readRegByte(EREVID) in just before the problematic status read and did get the correct value. One thing I found which may or may not be related to my logic analyzer (DSLogic) is that on the Arduino, the MISO line is mostly low with occasional data. However, with the photon, the MISO line is very chatty with non-zero data appearing on every SPI transfer.
The only difference is the voltage threshold I set my DSLogic for (3.3v vs 5v logic). The clock timing is fine and the MOSI data is as expected. The timing looks right. The only thing I can think of trying at this point is to adapt xferSPI to run a software SPI.
1 Like