Overall Discussion
This is a relatively unreliable and coincidentally functional ESP8266 Ethernet driver. It only uses two pins on the ESP, the I2S pins, but does provide Ethernet. It does all its own manchester encoding/decoding, framing, FCS, etc. It mimics the ENC424J600 stack found in avrcraft and borrows the IP, ARP, UDP and TCP stacks from that project, too.
This product was created by Charles Lohr, but, will likely fall out of support by original author quickly. Additional contributers would be welcome.
The frontend i2sduplex.c is what takes the bits off wire and calls a callback in an interrupt with raw 32-bit words of what came in from the wire. It also accepts buffers to send raw bits out on the wire.
Though designed for the ESP8266 should be relatively portable, as most of the code is limited to manchestrate.c and related files. Since it is designed to operate at full duplex, it is expecting a 40MHz-in, and 40MHz-out stream. This stream mus be biased toward 0’s instead of 1’s since at 40MHz-in there are ambiguous bit patterns if you don’t bias. This takes on raw on-wire bits and puts out ethernet frames – or accepts frames and outputs raw on-wire bits.
From there, we can check the FCS and process the packets in a consistent way and have a way of interacting with buffers. net_compat.c is what handles all of that. The interface it provides mimics the ENC424J600 and is what is used in avrcraft. The reason I use that interface on so many projects is because the style of memory access and use makes it require less buffers and less copying than stacks like lwip.
For the user layer, this system just borrows everything from avrcraft, including the http server! You will notice that it’s a little awkward since it’s designed to operate with either the TCP/IP stack from Espressif OR the avrcraft TCP/IP server. It would be really cool if we could figure out some way to have consistent entry.
The Web Interface
There is a web interface that gets put on the ESPs with a “make” step from the “web” directory. It pushes the webpage to the ESP. The webpage does not need to live on the ESP, itself, it can be viewed independent of one, it just only supports the “Load Test Packet” feature in “Last Packet” version on github.io.
The webpage is what is used to look at packets, create the demanchestration table, demanchestrate_table.h and test the table on new data. This was needed considering how complicated the decoding process is. Without testing on data, a lot of data, coming up with a robust algorithm was almost impossible!!! One other feature in the web interface is you can click on the 1’s and 0’s and turn them on and off to see how the system decodes those packets.
Hardware
Option 1: recommended Use a line driver like the ILS3371 and ethernet magnetics and terminator. This is superior, and likely to work in many situations except with stringent hardware and long cable runs. An example can be found in the esp12e-ethernet.pdf.
Option 2: not recommended Just jam some capacitors and resistors onto the input and hope for the best. This is potentially hazardous and may not work on many devices. Be ready to be disappointed.
For more detail:
About The Author
Ibrar Ayyub
I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.
Follow Us:LinkedinTwitter