ESP8266 Developer Zone

Re: Wifi event callback bug in SDK 1.4

2015-10-05T18:11:41+08:00

Ye ole problem of porting native windows software to unix and v.v., exactly the same problem

Statistics: Posted by eriksl — Mon Oct 05, 2015 6:11 pm

Re: Wifi event callback bug in SDK 1.4

2015-10-03T01:32:15+08:00

eriksl wrote:
tve wrote:provide an official way to register an idle handler that gets invoked whenever the system is idle.

That would be nice. On the other hand, I am never in this situation because when all work is done, I just return to the system, and that's, imho, how it's supposed to work.

Eriksl, I'm with you on the event driven nature, but we're trying to port a non-esp8266 run-time system to the esp and it does polling for certain things 'cause not everything is interrupt driven on every platform.

Statistics: Posted by tve — Sat Oct 03, 2015 1:32 am

Re: Wifi event callback bug in SDK 1.4

2015-10-02T20:26:05+08:00

@tve ... awesome discoveries. My poor brain is trying to understand what you mean by it though

I can imagine a WiFi event being detected by the internals of the SDK and it is now time to call the programmer registered callback. I had assumed that the registered callback was just "invoked" by the internals. Are you saying that the invocation of the WiFi event callback is itself scheduled as a task? I'll assume that to be the case for my next question.

My understanding of ESP8266 tasks is that there are three priorities ... 0, 1 and 2. If the internals of the ESP8266 are scheduling the WiFi event callback on a task and the understanding is that the priority of the task changed between 1.3 and 1.4 ... do we have the information on what the old priority was and what the new priority is now?

If our applications are now failing because our applications assumed control of a specific priority and that has now been usurped by the SDK ... do we have any remaining priorities un-used that our application could change to use?

Looking at the docs of the SDK, I was not able to find any caveat or warnings that any of the task priorities (0, 1 or 2) were used internally by the SDK. How confident are we that the SDK is actually using one of these user exposed priorities? (My thinking is that if the SDK is using one or more of these priorities for internal operation then that would prevent a user program from using the same one .... full stop ... and if that is the case, it should NOT be exposed for user consumption).

Statistics: Posted by kolban — Fri Oct 02, 2015 8:26 pm

Re: Wifi event callback bug in SDK 1.4

2015-10-02T17:40:46+08:00

tve wrote:
provide an official way to register an idle handler that gets invoked whenever the system is idle.

That would be nice. On the other hand, I am never in this situation because when all work is done, I just return to the system, and that's, imho, how it's supposed to work.

Statistics: Posted by eriksl — Fri Oct 02, 2015 5:40 pm

Wifi event callback bug in SDK 1.4

2015-10-02T02:25:56+08:00

The task priority used for the wifi event callback (invoked via wifi_set_event_handler_cb) changed between SDK 1.3 and SDK 1.4 causing "idle/polling loops" used in the javascript on esp8266 Espruino project and in the Arduino on esp8266 project not to work anymore. The idle/polling loop functions by running an iteration of the loop and then scheduling the next iteration by posting a message using system_os_post. This can be seen in the espruino project at https://github.com/espruino/Espruino/bl ... .c#L69-L71 and https://github.com/espruino/Espruino/bl ... #L156-L171 and in the esp8266/Arduino project at https://github.com/esp8266/Arduino/blob ... p#L82-L124

Basically the change makes it impossible to run an idle loop and receive wifi change events. I wrote a short test program which is available at https://github.com/tve/esp-test and the key code is at https://github.com/tve/esp-test/blob/ma ... .c#L57-L64 When compiled with SDK 1.3 (see https://github.com/tve/esp-test/blob/ma ... kefile#L22) it prints something like:

Code:

** esp-test ready
mode : sta(18:fe:34:a6:e8:8f)
add if0
f 0,   8853> wifi status=1 tick=0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
pm open phy_2,type:1 0 0
cnt

connected with tve-home, channel 1
*** WIFI EVENT 0
Wifi connected to ssid tve-home, ch 1
dhcp client start...
 10853> wifi status=1 tick=1
 12853> wifi status=1 tick=2
*** WIFI EVENT 3
Wifi got ip:192.168.0.114,mask:255.255.255.0,gw:192.168.0.1
ip:192.168.0.114,mask:255.255.255.0,gw:192.168.0.1
 14853> wifi status=5 tick=3
 16853> wifi status=5 tick=4

Notice the lines with "*** WIFI EVENT" coming from the callback handler at https://github.com/tve/esp-test/blob/ma ... tate.c#L32 (you have to scroll down in the forum code display box).

When compiled against SDK 1.4 the callback handler is not invoked:

Code:

** esp-test ready
mode : sta(18:fe:34:a6:e8:8f)
add if0
f r0,   8689> wifi status=1 tick=0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 4
cnt

connected with tve-home, channel 1
dhcp client start...
 10689> wifi status=1 tick=1
 12689> wifi status=1 tick=2
ip:192.168.0.114,mask:255.255.255.0,gw:192.168.0.1
 14689> wifi status=5 tick=3
 16689> wifi status=5 tick=4
Setting opmode to SOFTAP
state: 5 -> 0 (0)
rm 0
del if0
usl
mode : softAP(1a:fe:34:a6:e8:8f)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
 18689> wifi status=255 tick=5
 20689> wifi status=255 tick=6

NB: to compile use esp-open-sdk and

Code:

STA_SSID=your-ssid STA_PASS=your-password make

Please fix asap or perhaps better, provide an official way to register an idle handler that gets invoked whenever the system is idle.

Statistics: Posted by tve — Fri Oct 02, 2015 2:25 am