Thanks for the review, @jimmo !

Makes sense, ill give it a shot in the next few days.

I'm not familiar with the term 'root pointer', and google isn't helpful. Is that a pointer declared outside any other scope in the file (e.g. at the top)?

Might need a bit of guidance later, but I think I'm clear on what's needed to implement this approach.

I'm not familiar with the term 'root pointer', and google isn't helpful. Is that a pointer declared outside any other scope in the file (e.g. at the top)?

Because MicroPython uses a mark & sweep garbage collector, it can only find things that are reachable from the "roots". When you assign the callback to a global C variable, the GC won't know about it, and therefore might collect the callback function.

See mpstate.h (and gc_collect_start in gc.c). In particular you will need to add it to the port-specific root pointers (see MICROPY_PORT_ROOT_POINTERS in esp32/mpconfigport.h).

got it, that's perfectly clear, thanks!

@jimmo My latest commits have a callback working, but I have some questions before finishing:

1. The callback you suggested included the sta_if in the signature.

def on_scan_complete(sta_if, results)

Currently I'm not doing that, as there isn't a direct way to pass sta_if (or self_in), since the initial scheduling is done from the event handler. Right now the callback takes just the results argument. I could add a struct to hold callback args set when scan is called, but wanted to double check as that adds some code that may not be necessary depending on your answer.

edit: Clearly the interface would be useful if I wanted to connect to a specific AP in the callback, but not necessarily the only way to do it. I think I can use the wlan_sta_obj instead of passing through self, but I'm little stuck with mp_sched_schedule only taking one arguement. I could pack the interface and results into a tuple and pass that? would still change the desired callback signature

2. This looks a bit goofy to me:

178                 mp_sched_schedule(MP_OBJ_FROM_PTR(&esp_wifi_scan_cb_obj), mp_const_none);

This was since mp_sched_schedule needs instances, and I decided to use a function rather than a class (e.g. like machine_pin_irq). And it's possible I'm missing something subtle about constructing a python function and calling it.

edit: I found instances similar to this in other ports, so it's not as strange as i first thought.

3. Do I need to add anything else to allow async compatibility?

Thanks!

example:

>>> import network
>>> sta = network.WLAN(network.STA_IF)
>>> sta.active(1)
True
>>> sta.scan()
# scan results
>>> 
>>> def cb(results):
...     print("Callback!")
...     for ap in results:
...         print(ap)
...         
...         
... 
>>> sta.scan(cb);print("not blocking!")
not blocking!
>>> Callback!
# scan results

To use 2 args with a user-supplied callback, I made use of mp_call_function_2_protected which is used similar to mp_call_function_1_protected in modsocket callback handling. Works OK (see below).

I'm unclear what to do with an async.Event to see if it will work with asyncio, i haven't used Events in a way that it's clear to me. With the syntax you showed, I would expect scan to return something awaitable.

I'm also a bit unclear on initializing the callback in esp_initialize. I took that pattern from pin_irq callbacks. I suppose I could initialize it to None? I'm not sure what's best.

        memset(&MP_STATE_PORT(esp_wifi_scan_cb_handler), 0, sizeof(MP_STATE_PORT(esp_wifi_scan_cb_handler)));

example:

>>> def cb(sta_if, results):
...     ssid = `testssid`
...     pword = 'testpword'
...     for ap in results:
...         if ap[0].decode('ascii') == ssid:
...             sta_if.connect(ssid, pword)
...             
...             
... 
>>> 
>>> sta.isconnected()
False
>>> sta.scan(cb);print("non-blocking")
non-blocking
>>> sta.isconnected()
True

This is cool @marcidy ! @jimmo is this on your short list? I sure hope so!

Just checking in on the question, and wow awesome updates! Can't wait to give this a try, especially with asyncio compatbility.

I realized that this PR is not merged, but it doesn't matter that much since we can still combine asyncio and call this wifi.scan() in _thread

I think about this PR periodically. Would love to see callback based non-blocking wifi scan for esp32. Any chance of brining this one back into the fold?

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.