ESP8266 Community Forum

- Sun Jan 29, 2017 4:45 pm #61738 Hi, I've been looking for sth like UIPEthernet for a long time. I need to connect ESP8266-12F with ENC28J60 and make them work together. I've tried various libraries, but with no luck so far...

I've got ESP8266 with adapter like this:
http://imge.pl/p/126579/n/1265795589550.jpg
There are pull-ups on gpio5, gpio0 and pull-down on gpio15.

Board works ok when I use one of my older projects, but when I try to upload one od the examples, the module doesn't start properly. There is only trash on the serial monitor.

This project is quite important and I need to make it work really soon.
Please, if You've got any idea what's wrong, share it.

- Wed Feb 08, 2017 7:10 pm #62282 Ave, Cicero,

I'd like to try to get wired ethernet to the "nodemcu ecosystem", which in my eyes is not only a hardware variant of the ESP8266, but a lua based high-level-language extension of the IoT / event driven computing concept on top of the "bare" esp-SDK.

I placed an issue at their github account where I collected my findings so far.

As far as I can figure out till now, the important differences between bare esp-SDK and nodeMCU are:

• nodeMCU has an lwIP network stack, so we might try to keep the driver part as tiny as possible. I think that most we need is in your enc28j60.c / ...h file.
• we are supposed to untilize the spi framework as it is existing in the nodemcu-firmware to configure spi stuff from "lua-land". I see that there are only two tiny functions in enc28j60.c implementing the spi interface, so I hope adaptation is not a big issue.
• as far as I can see, your driver expects and delivers "raw" ethernet packages, not IP-packages. The netif interface of lwIP expects IP-encapsulated packages. I think there is a a etharp.c and cousins in lwIP bridging the gap, but haven't yet checked this in detail.
• there are hooks for if-up / if-down and link-up and link-down in the lwIP netif interface. I think they can be called by the initialisation wrapper. Maybe we have to poll/monitor some status for "link up" as long it is down. I would not spend too much effort for the "...down" bretheren, since when stuff does not work, modules usually are rebooted anyway.

Is it correct that your driver does not utilize interrupts? Are there any severe obstacles? Can you estimate the penalty in latency by not using interrupts?

I don't dare to ask you for your valuable time and energy, but of course I'd appreciate any help.
Are you aware of any efforts of porting your code to nodeMCU firmware already?
May I hope for some assistance as soon as I get stuck in the inevitable details?
Is there some quick'n dirty firmware to flash so that I can test the hardware connectivity before I delve into software issues?

- Thu Feb 09, 2017 5:12 am #62299

Ave, Cicero,

I'd like to try to get wired ethernet to the "nodemcu ecosystem", which in my eyes is not only a hardware variant of the ESP8266, but a lua based high-level-language extension of the IoT / event driven computing concept on top of the "bare" esp-SDK.

I placed an issue at their github account where I collected my findings so far.

As far as I can figure out till now, the important differences between bare esp-SDK and nodeMCU are:

• nodeMCU has an lwIP network stack, so we might try to keep the driver part as tiny as possible. I think that most we need is in your enc28j60.c / ...h file.
• we are supposed to untilize the spi framework as it is existing in the nodemcu-firmware to configure spi stuff from "lua-land". I see that there are only two tiny functions in enc28j60.c implementing the spi interface, so I hope adaptation is not a big issue.
• as far as I can see, your driver expects and delivers "raw" ethernet packages, not IP-packages. The netif interface of lwIP expects IP-encapsulated packages. I think there is a a etharp.c and cousins in lwIP bridging the gap, but haven't yet checked this in detail.
• there are hooks for if-up / if-down and link-up and link-down in the lwIP netif interface. I think they can be called by the initialisation wrapper. Maybe we have to poll/monitor some status for "link up" as long it is down. I would not spend too much effort for the "...down" bretheren, since when stuff does not work, modules usually are rebooted anyway.

Is it correct that your driver does not utilize interrupts? Are there any severe obstacles? Can you estimate the penalty in latency by not using interrupts?

I don't dare to ask you for your valuable time and energy, but of course I'd appreciate any help.
Are you aware of any efforts of porting your code to nodeMCU firmware already?
May I hope for some assistance as soon as I get stuck in the inevitable details?
Is there some quick'n dirty firmware to flash so that I can test the hardware connectivity before I delve into software issues?

HI there wjr,

I've had a quick glance over what you're proposing and its similar to my "first prize" end-goal of having the ENC28J60 interface directly into open-sdk, fully integrated using lwip. Alas though, at the time when I looked into it, it wasn't open enough and still required some closed binary blobs which restricted full lwip implementation.

I have no problem helping you out, I've done quite a bit more to this project that I just haven't had the time to release. Unfortunately I've never used lua though!

In terms of my driver, it does use an interrupt, however I dont think it needs to. I'm essentially running a 1ms callback that 'services' the enc and checks for data...seems to work fine. The interrupt isn't necessary imo. If you can't do every 1ms, the worst that can happen I think is your ENC runs out of buffer and you miss packets. I haven't tried it though.

You can easily poll the ENC for link-up using the PHSTAT2 register. So thats an easy integration.

Yes, the driver processes the full raw ethernet packet, and extracts what it needs and does its own stack for the enc packets. If you could see where lwip does that processing then that may remove the reliance on stack.c. Having a *quick* look into the nodemcu fw on github, my initial guess is you'll have to tap into the tcpip_thread() -> sys_timeouts_mbox_fetch() and have a good look down that rabbit hole! You need to also have a method of distinguishing between interfaces for each packet received, wifi/wired at the low level as well.

Send me a PM and I'll give you my email address to help out whenever.

- Mon Feb 13, 2017 3:15 pm #62518 Hello, Cicero,

Sorry for the late answer. Looks like my providers spam filter is eating the forum notifications

I have no problem helping you out, I've done quite a bit more to this project that I just haven't had the time to release.

That sounds great - thank you!

Unfortunately I've never used lua though!

I think this is not a big problem. 5 weeks ago, I haven't either.
Usually you don't do big things in lua. You just write small codelets to connect the C-functions, which are surfaced to "lua land" by tiny wrapper functions.

As you may see from my github, I'm right now trying to get a PR pulled with a interface to the espconn ping service. This is a good trainig for this kind of lua-C interfacing. I feel I had some breakthrough yesterday and am on a good way now.

Unfortunately, my time is not that ample, so sometimes things may take a bit.

I see that there are two ways to electrically connect the ENC28J60 - your resistor scheme
https://github.com/Cicero-MF/esp_enc28j ... wiring.png
and UPIP using Mosfets.
https://github.com/UIPEthernet/UIPEther ... wiring.PNG
I've ordered some of those BS170. Am I correct that both schematics are logically equivalent ? Which one is the more stable / reliable one?

I think I'll try to get your git firmware running first, so I can be sure that the hardware part is working.

Next step would be to surface your enc28j60.c to lua land and try to load / configure / blink / regdump and maybe even send/recieve raw packets.

Then I'd try to surface the netif driver interface to lua land and then connect both sides by a simple main loop followong the the lwip netif doku.

If you could see where lwip does that processing then that may remove the reliance on stack.c.

Maybe I underestimate the task. But when I glance into the lwip doku

• http://lwip.wikia.com/wiki/LwIP_with_or_without_an_operating_system
• http://lwip.wikia.com/wiki/Writing_a_device_driver
• http://lwip.wikia.com/wiki/Network_interfaces_management

this does not look that difficult.

I even could imagine to implement the main callbacks lwip <-> driver in lua, at least for testing, debugging and maybe API for special tasks (just think of packet filtering...).
But most of the use cases will rely on a reliable tested connection implemented in C.
Lua land can be used to configure SPI, driver, IP and stuff like that.

my initial guess is you'll have to tap into the tcpip_thread() -> sys_timeouts_mbox_fetch() and have a good look down that rabbit hole!

This is somewhat contrary to above mentioned docu.
Well, it may be some flats up or down the rabbit hole, of course.

You need to also have a method of distinguishing between interfaces for each packet received, wifi/wired at the low level as well.

I despereately expect lwip to take care of that.

At least I could alread get diffent interfaces listed for wifi and loopback (similiar to *nix ifconfig)

at the time when I looked into it, it wasn't open enough and still required some closed binary blobs which restricted full lwip implementation.

That would be really bad.
You think they don't have a full lwip on board?
And / or tweaked it in some inseperable way with their espconn stuff?

This might be a game killer, actually.