Closed wolfgangr closed 4 years ago
There's still another issue opened about this driver for it working flawlessly (#3). I will address this after esp8266 arduino core 2.5.0 is out (next month I guess).
W5100 can work but I need to find a piece of hardware to play with it (Only cheap W5500 are available).
Testing, you can do it now, see example in issue #3.
About the new Paul's driver, it is not related. This driver is only an interface between the chip (only the ethernet part, not the integrated TCP facility) and lwIP, so any service/library available in the arduino core will be available with it. There will not be any limitation on the number of simultaneous opened tcp connections, web client, servers, dns, dhcp and all that will work.
Paul's one is using chip's TCP facility, not compatible with WiFiClient
and software TCP (lwIP) on which all the esp8266/arduino core is based. It is generic aimed to arduino chips without any native TCP support.
W5100 can work but I need to find a piece of hardware to play with it (Only cheap W5500 are available).
I can' t follow you on that. There are W5100 modules from CN at ~ 4€ in the bay: https://www.ebay.de/itm/New-Mini-W5100-LAN-Ethernet-Shield-Network-Module-board-Fur-Arduino/162708716617 At European sources, they start at ~8€. Never mind, I have 3 of them in my parts pile. If it helps, I'll send you one :)
Tried testing on W5100
First step: test Hardware connectivity. Used Arduino lib for that. Reported already on failure on DHCP , which was clarified by Paul Stoffregen. OK so far - this problem is not on our main track towards lwip.
Changed my sketch to static IP (using standard 2.4.2 arduino ethernet library). Can print my local IP and can ping from outside - even over routed network. Fine thus far. Thought everything was fine up to here, but that may have bee premature, since if Ping is handled on the W5100 (as I suppose), there may not be any reading of data have been required yet.
Now I'm trying the W5500MacRaw / sendeth setup. W5500MacRaw builds and loads, does its setup and enters its main loop (added serial prints to check).
Compiled sendeth , but it seems to send one packet only , not getting any response / result. Hooked up wireshark on the linux box - confirmed the finding: only one packet sent (can even see it in the LED's of the module), but no response.
Changed MAC (uint8_t our_mac
in sendeth.c
) to my card's imprinted one, no change.
Tried to ifconfig down my eth1, but then I get sendto: Network is down
.
Wireshark stops recording.
output on arduino console (last line is a debug print added by me at the end of setup):
[W5500MacRaw]
52:ff:ee:1b:44:55
End of setup
output of sendeth on the linux box:
....$ ./sendeth
i=0 counter=0
Wireshark text representation of sent package:
1 0.000000000 1e:65:55:3c:84:c3 52:ff:ee:1b:44:55 0x88b5 100 Local Experimental Ethertype 1
complete package in hex
0000 52 ff ee 1b 44 55 1e 65 55 3c 84 c3 88 b5 00 00
0010 c4 28 e8 c5 fe 7f 00 00 80 2b e8 c5 fe 7f 00 00
0020 92 2d b1 bc 57 7f 00 00 74 93 d5 bc 57 7f 00 00
0030 c8 28 e8 c5 fe 7f 00 00 eb 01 00 00 00 00 00 00
0040 c0 14 f7 bc 57 7f 00 00 90 3d 9b bc 57 7f 00 00
0050 38 10 9c bc 57 7f 00 00 b3 9b d5 bc 57 7f 00 00
0060 eb 01 00 00
$ ifconfig eth1
eth1: flags=4354<BROADCAST,PROMISC,MULTICAST> mtu 1500
inet 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255
ether c4:6e:1f:03:e0:0e txqueuelen 1000 (Ethernet)
RX packets 8 bytes 560 (560.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 112 bytes 17112 (16.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ip link ....
2: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether c4:6e:1f:03:e0:0e brd ff:ff:ff:ff:ff:ff
ip addr
2: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether c4:6e:1f:03:e0:0e brd ff:ff:ff:ff:ff:ff
inet 192.168.10.10/24 brd 192.168.10.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::c66e:1fff:fe03:e00e/64 scope link
valid_lft forever preferred_lft forever
stuck for the moment. Thnik I will go back to arduino's examples, choose one with both read and write, wireshark and report.
Tried arduino WebServer example. Works like a charm, +- out of the box. Can watch bits on their way with wireshark - both ping and http request/response. So, my hardware and network setting is OK, I think.
Even if I did connect CS to GPIO 15. May share my findings on that if you like. But if this were a problem, it would not work with arduino libs either, would it?
I can' t follow you on that. There are W5100 modules from CN at ~ 4€ in the bay:
I usually use aliexpress, and last time I checked, there was none - only W5500. Now rechecking, there are :]. I ordered one yesterday.
But if this were a problem, it would not work with arduino libs either, would it?
Of course. It does not work because of the hadware library made for W5500. Probably a small thing to change in registers, or a different driver would be needed if the chips are too different. This can be fixed once I have the hardware and reading both datasheets. But first fix would be to integrate this into the arduino core to solve #3.
is the W5500MacRaw test proved to run at all - after your changes, and in the ESP8266 ecosystem ? Or is it just a leftover from the lib you pulled in? Maybe I have to call lwip in the loop? I thought that arduino framework would take care of that - but we aren't yet in lwip, right? And on ESP8266 much of this is broken, I have learned... so if just add some delay(0)= or yield() ?
Was looking for a simle but proven test exercise for lwip adding interfaces. Can you give me a pointer?
W5500MacRaw is not a leftover, it's the spi driver and ethernet abstraction.
Maybe I have to call lwip in the loop?
Absolutely. This is #3 issue, where a library does not return immediately. The .loop()
has then to be called from within the internal core function (maybe yield()
) and that's what I'm about to try.
I thought that arduino framework would take care of that
Yes but only for wifi.
And on ESP8266 much of this is broken, I have learned...
No, we fix every single issue :]
so if just add some delay(0)= or yield() ?
No, no magic delay()
is ever needed. ethernet.loop()
must be regularly called.
void loop() {
eth.loop();
...
First: please let my know if my semiprefossional testing endeavour is of any help of you. I dont dare to distract you from your agenda.
At the moment I feel like talking past each other. For precise refernce, here the tree of the unpacked W5500MacRaw git:
...:~/test/ESP8266/W5500MacRaw$ tree
`-- W5500MacRaw
|-- LICENSE.txt
|-- README.md
|-- W5500MacRaw.ino
|-- sendeth
| |-- Makefile
| |-- sendeth
| `-- sendeth.c
|-- w5500.cpp
`-- w5500.h
2 directories, 8 files
...:~/test/ESP8266/W5500MacRaw$ grep -nri loop .
./W5500MacRaw/W5500MacRaw.ino:63:void loop() {
./W5500MacRaw/W5500MacRaw.ino:98: eth.loop()
W5500MacRaw is not a leftover, it's the spi driver and ethernet abstraction.
I see that the files W5500.h
and W5500.cpp
in the directory W5500MacRaw
comprise the driver - OK?
But I do not see any .loop()
function or method there, as grep
exposes.
is the W5500MacRaw test proved to run at all - after your changes, and in the ESP8266 ecosystem ? Or is it just a leftover from the lib you pulled in?
correctly, I should have referred to W5500MacRaw.ino
( .ino ! ) file, together with the accompaning sendeth.c
tool for linux. I tried to add eth.loop()
there (which my grep finds) but since there is none yet, I get a 'eth' was not declared in this scope
.
So I suspected that while you are using W5500.h
and W5500.cpp
as your low level driver, the test suite delivered with it - i.e. the W5500MacRaw.ino
and the sendeth.c
for the linux at the other end of the cable - might not have received its attention from you.
So if this test were broken, there is no point in testing my W5100 setup using this tools, and the failure of doing so is of no meaning at all. However, it is still supposed to work with your changes applied, my failed test might reveal that your driver does not yet cover W5100 correctly.
W5500MacRaw.ino
calls uint16_t len = w5500.readFrame(buffer, sizeof(buffer));
in its main loop.
Is it what any eth.loop()
is supposed to do?
Or is there anything else to do/check before, to read incoming packets?
At first glance, I concluded the https://github.com/d-a-v/W5500lwIP/issues/3 issue refers to using the lwip driver - which is one step beyond the bare low level driver I still try to test. But I'll give it a deeper look this night.
No, no magic delay() is ever needed. ethernet.loop() must be regularly called.
At what intervals? Does it only read one packet at a time, or all network tasks it can do without wait?
I just debugged a tasmota app and found that it's loop lastet longer than 100 ms. So if there were only ten eth packages read per second, this were slow netting...
I think it would be preferrable to place those eth.loop() calls into the arduino-ESP8266 core (maybe by conditional #define) wherever an esp-wifi-call is generated - in't it?
(from you in tasmota referenced thread)
But I'm sure, there are gotchas on the way. Just think of Espressif-SDK-timing....
@wolfgangr you seem concerned with espressif closed source. Currently lwIP in arduino core is not the espressif version, it's this (builder/) which is submoduled. It gives freedom on lwIP, and we also have now IPv6, SACK (thanks to lwIP team).
About timings, this is pretty well handled. We have good performances. We just need some yields. Ethernet with lwIP will work at some point. There's no technical reason we couln'd have PPP which is a software driver like this repo. PPP is fed by Serial, so no overall issue.
At what intervals?
I don't know. We have several options. I don't use the interrupt pin right now, on purpose but that could be later changed. So the interval should be the smallest because it is polling.
I think it would be preferrable to place those eth.loop() calls into the arduino-ESP8266 core (maybe by conditional #define) wherever an esp-wifi-call is generated - in't it?
I plan to do it at every yield()
, so that should occur fast enough.
There's also another possibility, which is hijacking WiFi/firmware call to lwIP's sys_check_timeout()
: That function could also call some external function (after checking its rate and its context).
I just debugged a tasmota app and found that it's loop lastet longer than 100 ms.
Does this loop yield()
s in its inner loops ?
Does it only read one packet at a time, or all network tasks it can do without wait?
It can read all available packets at once if needed (I think currently it reads one only).
I see that the files W5500.h and W5500.cpp in the directory W5500MacRaw comprise the driver - OK? But I do not see any .loop() function or method there, as grep exposes.
About your W5100, no doubt it is itself working. Not with this repo because the current driver used is designed for W5500. If you find or transform a W5100 library to offer roughly the same interface as W500MacRaw, then it will work with it.
I see that the files W5500.h and W5500.cpp in the directory W5500MacRaw comprise the driver - OK? But I do not see any .loop() function or method there, as grep exposes.
class Wiznet5500lwIP: public Wiznet5500 {
(it will be a template for any ethernet class offerring a similar interface)
This driver uses W5500MacRaw which is an Ethernet-only SPI interface with W5500. The incompatibility with W5100 is inside this driver. My repo is not intended for W5500 only, it's also for enc28j60, also PPP, and why not W5100 (which ethernet part could be picked from any W5100 arduino library).
About W5x00 I did not want to use a random library and extract the ethernet part only (by removing all tcp-related code) because I wanted to test the feasability first. So I took this ready-to-use W5500MacRaw ethernet only library and that was a good starting point to me.
OK, thank your for this comprehensive information, which help me to sort my priorities. I just ordered a W5500 (and some more from CN) to get quick access to a working implementation with yor driver. Then I can focus on on integration in tasmota - which ist top prio for me right now.
I wil hope that Enc28J60 and W5100 will be adressed by the community anyway, but to me that is secondary. Looks like the W5500 becomes readily avaiable in the low price channels now, anyway.
I just want to comment that I just received 2 w5500 modules today to test this driver with, so that If I get the time, I can try porting to the ENC28J60 module, which I have a lot of. I never knew the Wiznet parts could be operated in raw mode. I really like the idea of reusing the lwip stack for these modules. I'm wondering if it will be possible to overlay the HSPI -> SPI lines except for CS to save from having to use all our free pins to drive the hardware, or will it interfere with the flash data transfers? Regardless, this will be fun to play with.
I've use the ENC28J60 with a Maple board a few years back, using Pascal Stangs code as a base, and the module worked quite well.
@wolfgangr did you make any progress with your Tasmota Ethernet integration using David's driver once the W5500 board arrived?
Dion,
sorry to say, no, postponed the idea and followed another path
Wolfgang
On Thu, 18 Apr 2019 07:33:40 -0700 Dion Weston notifications@github.com wrote:
@wolfgangr did you make any progress with your Tasmota Ethernet integration using David's driver once the W5500 board arrived?
@wolfgangr What is the other path? ;)
W5100 support done and issue closed by 6824c13f0ada135f526299a793ded4821a9383dc
@Eszartek Would love to get enc28j60 support too.
Given the quality of @njh's code (both w5100 and w5500 drivers), I plan to have a look to https://github.com/njh/EtherCard for enc28j60.
Dear David,
@andrethomas pointed to me that you are working on an lwip driver for ES8266 https://github.com/arendst/Sonoff-Tasmota/issues/4936#issuecomment-454404478 (I'd like to find ethernet support in tasmota.) Will your driver support the commonly available W5100 chipset as well? Any hints regarding your timescale? Can I help, e.g. with testing?
There is a new arduino ethernet driver, developped by teensy developer Paul Stoffregen: https://www.pjrc.com/arduino-ethernet-library-2-0-0/ How does your work relate to PJRC's?