@peekay123 Do you know infinite monkey theorem? That’s me by the typewriter
I started experimenting with various SPI settings and eventually these settings seems to be what we were looking for! Just try to add the following two lines in ENC28J60:initSPI() just after SPI.begin(selectPin).
Now module no longer has problems requesting ip address using DHCP. I didn’t check anything more so far, so further testing is definitely required. I powered ENC28J60 using electron’s 3.3V pin.
@gkujawsk, WTF!!! I had the SPI_MODE0 but set the clock for 8MHz without the reference. I will test tonight for sure. I hope all that monkeying around has paid off!
PS. I’ll test the software SPI and keep it if it works so that folks can map to any any pins at the cost of performance.
@peekay123 Here’s the link to all the source files.
I compiled this locally against 0.6.1 firmware. AFAIK no more changes were made than these two lines I’ve mentioned, but I didn’t run diff against mine and the orginal files. I used the code you’ve posted on dropbox as a starter. There’s a lot of commented out Serial.print*.
@gkujawsk, after checking a few things I realized what I had changed. The library is now working! I also tested with software SPI but I’m not sure I will implement that feature. I plan on making the migrate the library to v2 and post it to the IDE. Thanks for your help!
@peekay123
So, with the working library, could one simply enable the use of the hardwire ethernet connection to make use of all the online functionality of the particle cloud (i.e. particle publish/subscribe, tcp client/server, downloading firmware, etc.)? If so, that’s a game changer for my industrial photon applications where WiFi is not an option, but a simple Cat5 connection easily is. Regardless, great work @peekay123 and @gkujawsk.
@jenschr, I am working on packaging the whole think in a V2 library and posting it on the web IDE. Stay tuned!
@gkujawsk, I am not entirely confident with the stash code. I ran the test app in the examples but with no documentation, I wasn’t sure if what I saw was correct. Did you get a chance to test that?
@peekay123 - stash code crashes electron with the hard fault. I didn’t do any deep troubleshooting. Basically you can do byte sd = stash.create() but any subsequent operation like printing into the stash will not work and will crash firmware with the hard fault. So far I only managed to send data just by populating buffer this way Stash::prepare("TEREFEREKUKU STRZELA BABA Z LUKU") and then calling ether.tcpSend(). This will cause electron to setup the tcp connection, send what’s in the buffer, receive the reply and close connection.
TCP implementation in client mode actually do not support any other scenario. If you set ether.persistTcpConnection(true); the connection will not be closed right after receiving the reply, but it will not read any more data either. It should not be difficult to repair but according to library author it’s not recommended.
And be aware the frames are always send to the default gateway even when the destination host is on the same network. Usually the default gateway will send in this case the ICMP Redirect messages to the source indicating that frames should be send directly on LAN which are silently ignored by EtherCard library.
Now it’s time to add Modbus TCP support on top of EtherCard. There’s MsgModbus lib http://myarduinoprojects.com/modbus.html that probably can be ported or rather heavily modified to work with ENC28J60.
@gkujawsk, I like it! Seems more robust as well. I’ll work on the port starting tonight. I did, however, notice that some of the class names (eg. IPAdress, upd, etc.) will conflict with Particle names. These will need to be modified so as not to clash. This is a big reason for using Ethercard as it was already written so as not to clash.
@gkujawsk, this new library will require a LOT of work. I tried compiling it yesterday just to see how far it would get with the new arduino pre-processing and it basically go nowhere. I couldn’t even figure out the error I got! I’m going to try compiling with the local toolchain to see if I can get more insight.
That’s what I affraided of. Since the basic TCP connectivity is all I need I’m just going to add modbus tcp support to this library we’ve started with. It’s not going to be too robust since every modbus request will be done over a new tcp connection. Ugly, but good enought for this moment.
I can only offer you help with testing. I’m not that advanced to be any help with the port itself.
