Open emelianov opened 5 years ago
So it looks like that's enough to make run_scheduled_functions() called from yield()/delay() is that possible?
This is the purpose of the 1-2 months old patches in the core.
delay()
and yield()
both call esp_yield()
which calls run_scheduled_functions()
With your patch you call it more often (2*timeout_ms) times instead of once. This particular line you changed has changed on May 19 and I haven't been working on ethernet since then. https://github.com/esp8266/Arduino/commit/912c0db0910752d029d329ad20cbff8316a1db08#diff-3f3ed90c696a8411853b28574edb12d8 So it appears this change has broken ethernet.
Can you check the old fashion, with esp_yield()
instead of delay()
without your loop ?
Thanks for debugging this !
Sorry I was not talking about the same delay() but they are very similar (in the same file, the other delay()
recently updated).
You don't have to try anything (except trying to not call run_scheduled_functions()
) and thanks again for debugging this issue.
Your fix is good and I think also is worth being applied to the other function.
To make it not a test, just add a test on _connect_pending
:
for (decltype(_timeout_ms) i = 0; _connect_pending && i < _timeout_ms; i++) {
// let a chance to recurrent scheduled functions (ethernet)
delay(1);
}
Similarly on the other delay()
with the same comment (the one I'm talking about above) should become:
for (decltype(_timeout_ms) i = 0; _send_waiting && i < _timeout_ms; i++) {
// let a chance to recurrent scheduled functions (ethernet)
delay(1);
}
It those changes work for you, would you propose a PR on the arduino core with them and a link to this issue ?
I've looked dipper to Arduino core code and it looks like it's better to refactor delay(). Main idea is to call esp_yield() periodically during delay not only once. I'll try to create PR after comprehensive testing. In combination with #7 it should make your library working with no WiFi* classes modification.
Nevertheless above mentioned
for (decltype(_timeout_ms) i = 0; _connect_pending && i < _timeout_ms; i++) {
// let a chance to recurrent scheduled functions (ethernet)
delay(1);
}
modifications are also required. I'll create separate PR for them too.
Just built rather complex project (client/server both) with ethernet (WiFi off) -- it's working. No issue except connect delay and wdt reset on first start (coldstart?). Thanks for your great work on ethernet implementation!
except connect delay and wdt reset on first start (coldstart?).
This wdreset should be identified.
Thanks for your great work on ethernet implementation!
As you probably saw it, it's rather simple and only connecting lwIP with a new link layer. The main issue is the need for proper transparent polling, which you are also currently addressing.
What's left is
And afterward
except connect delay and wdt reset on first start (coldstart?).
This wdreset should be identified.
Steps to reproduce WDT reset:
Hope to have some spare time to play with W5500 interrupt usage next days. But i'm not sure it can be really helpful.
David, By the way is the any particular reason to not implement handlePacket() using os_timer API (os_timer_arm) ?
I will try to reproduce ASAP (currently finishing to update recurrent scheduled functions in the arduno core).
By the way is the any particular reason to not implement handlePacket() using os_timer API (os_timer_arm) ?
Yes because minimum timing resolution is 1ms and I don't know whether performances need lower value yet.
Yes because I try to stay out from SYS stack (Ticker can use os_timer_arm and use scheduled functions. But in that case every timer create a new scheduled function, and they re executed only on loop()
).
Yes because I know that current lwIP configuration is not protected against concurrency.
#define SYS_ARCH_DECL_PROTECT(x)
#define SYS_ARCH_PROTECT(x)
#define SYS_ARCH_UNPROTECT(x)
Once it works reliably in CONT stack (= not in ISR) we can try to make it work from interrupts (timer or external int) without recurrent/scheduled functions (= in ISR).
Probably i missing something but was able to get code below running only by patching esp8266\libraries\ESP8266WiFi\src\include\ClientContext.h (i know, delay doesn't implement early exit but it's just test)
That case connect() is success. Don't perform more detailed checks.
So it looks like that's enough to make run_scheduled_functions() called from yield()/delay() is that possible?