Thanks Glenn! I'll do some testing when I get a chance!

Has this been addressed?

I see a threading issue with the callbacks, from the esp32 docs:

The sending callback function runs from a high-priority WiFi task. So, do not do lengthy operations in the callback function. Instead, post necessary data to a queue and handle it from a lower priority task.
The receiving callback function also runs from WiFi task.

To me "high priority Wifi task" has the smell of Pro CPU and mp_sched_schedule is not protected against that. Of course it would be nice if the Espressif docs were a bit more explicit, perhaps the esp-idf source sheds some light...

Has this been addressed?

Thanks for bringing this up again - it fell off my radar.

I see a threading issue with the callbacks, from the esp32 docs:

The sending callback function runs from a high-priority WiFi task. So, do not do lengthy operations in the callback function. Instead, post necessary data to a queue and handle it from a lower priority task.
The receiving callback function also runs from WiFi task.

To me "high priority Wifi task" has the smell of Pro CPU and mp_sched_schedule is not protected against that. Of course it would be nice if the Espressif docs were a bit more explicit, perhaps the esp-idf source sheds some light...

I confess I've had no more success than any others in divining the mysteries behind the espressif docs. I think I am doing just what the docs recommend - handing data off to a queue (ring buffer) from the callback functions (I think of them as ISRs).

The ring buffer is thread safe so long as only one producer is pushing new data onto the head of the buffer (recv_cb() and send_cb() - which execute in the "high-priority Wifi Task") and only one consumer (callback_wrapper()) is pulling data off the tail of the ring buffer.

So, I don't believe it matters which CPU they are being executed on - so long as recv_cb() is never pre-empted by another recv_cb() (on the same or another CPU) and callback_wrapper() is never pre-empted by another callback_wrapper().

I am interested to understand better the concerns around the mp_sched_schedule vulnerability to Pro CPU invocations. If there is some further protection required I'd welcome any guidance. I'm keen to make this as robust as possible.

EDIT: I've done some small sustained transfer tests and haven't seen any buffer corruption yet - but that's no guarantee.

Tried to use espnow, using the documentation docs/library/espnow.rst. I can't init espnow, what argument is it expecting? see code below.

from esp import espnow
espnow.ESPNow.init()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes 1 positional arguments but 0 were given

Hi Feiko,

Thanks for testing. ESPNow is a Class, you need to invoke a class instance first before calling the init() method. The errors is less than useful - I admit.

Typical usage (I'll put a short code snippet at the start of the docs in the next commit).

from esp import ESPNow
e = espnow.ESPNow()
e.init()
....

Furthermore, you need to initialise a WLAN interface before calling init() or your ESP32 may reset (on the todo list): eg.

import network
w0=network.WLAN(network.STA_IF)   # Can be STA_IF or AP_IF

Additionally, you need to invoke w0.active(True) before you can send or receive any data.

Thanks Glenn20,

Of course! That did the trick. My Python is a bit rusty. A short code snippet would be very welcome.

@tve: I've done a little empirical testing, but I'm not sure if they are valid in micropython.

Using xPortGetCoreID() I tested the coreid for

• the espnow callbacks (recv_cb() and send_cb()),
• the callback_wrapper() scheduled by mp_sched_schedule() and
• the main thread running espnow_send().
  In all cases the code reported back coreid=0. I ran the tests for about two hours.

I was a little surprised because I thought the micropython thread ran on coreid=1 (but I'm not sure why I had acquired that assumption). Is it possible that xPortGetCoreID() does not report correctly (eg. not initialised under micropython)?

Let me know if there are any specific effects I should be protecting against.

Ok - I've just checked and discovered that arising from #5489 micropython recently switched to pin everything to core 0, so the results of my test were not as unexpected as I thought.

Let me know if there are any specific effects I should be protecting against.

Code looks good to me!

@glenn20

Is possible to do a like wlan.scan() to get all APs MAC and their signal?
Actually, I'm working (ESP32) with wlan.scan() to get location-based on fixed APs. How is possible to do that with ESPNOW?

Thank you.

As flagged, a substantial rewrite with breaking changes. Apologies for the delay - shoulder injury slowed me down for a while and I spent some time faffing about with various approaches to supporting more reliable IO, allocation-free reads and asyncio support. Learnt a lot more about micropython internals.

I know that a substantial change of direction in a pull request is less than ideal, but I do believe the new approach warrants the change. I'm happy to take on board feedback. I will say that I get more reliable and faster data transfers with the new approach.

Breaking Changes

• Remove on_send() and on_recv(): The mp_sched_schedule() stack is easily overflow-ed and can cause unfortunate reliability interactions when used along with other devices, such as bluetooth or other machine IO.
• Add recv([timeout_ms]): Wait for and return a tuple: (peer_mac, message). Default timeout can be set with config(timeout=ms). New tuple and bytestring storage is alloced on each call.
• Add irecv([timeout]): As for recv() but supports alloc-free reads. Returns a callee-owned tuple. ie. the tuple and bytestring storage is alloc-ed once on first call and re-used across subsequent calls.
• Change send(peer_mac, message[, sync=True]): Add sync flag (default=True) to support syncronised writes to the peer. If sync=True: send() the message and wait for response (or not) of peer(s). If sync=False: send message to peer and return immediately. Responses from peers will be discarded. If sync=True: return False if any peer fails to respond. Note that a 'broadcast' will send to all registered peers. Synchronised mode is much more reliable, while sync=False is much faster.
• Add clear(True): Clear any pending data in the recv buffer. Use this in case you get a "Buffer error" (should not happen). Will discard all data in the buffer.
• Add support for stream IO interface: read(size), write(), readinto(), readinto1(), read1(). I'll provide further docs and python code support for the data format used by these functions. Also supports poll.poll() which enables support for asyncio through the StreamReader() class.
• Add support for iterating over the ESPNow() interface (via irecv()), eg: for i in espnow.ESPNow(): print i

Also a substantial internal rewrite to better consolidate the buffer and data packet logic.

Ok - I've squashed the commits to just two: original import from PR#4115 and my current HEAD.

I believe this is ready for review. It is working well for me but happy to hear from others.

Kudos for the uasyncio support 👍

For those interested, I now have a heavily pared down version of the esp32 espnow support working on esp8266 available at: https://github.com/glenn20/micropython/tree/espnow-g20-8266. I am planning to make a separate PR for the esp8266 support after a little more testing, but I welcome any testers or users in the meantime.

Does not support:

• stream IO and asyncio
• get_peer(), mod_peer() and get_peers()
• config()
• ESPNow broadcast in send()

However, it does support:

• init([recv_bufsize]): Override the default recv_buffer size in init() (no config() method)
• deinit()
• irecv([timeout]): No recv() method.
• send(peer, message, [sync]): Sync, and non-sync send()s are supported.
• add_peer(peer[, lmk[, channel]])
• del_peer(peer)

With this build my compile builds to exactly the max .text size (32768 bytes) for the esp8266.
Note: A number of defensive arg and consistency checks are also removed from the esp8266 espnow code.

Is there any indication when this will be merged and available for download as part of the main micropython binaries?

Sorry for the slow response (been away on holiday for a few weeks). I don't really know how to get an eye on the process for getting PRs reviewed and merged. I'm just hoping it will be soon-ish. Any suggestions for prodding the decision makers are welcome :-).

I have added some updates:

• Merged in the esp8266 support (is only compiled in for GENERIC_1M and GENERIC build targets).
• Some code simplifications and optimisations for the ESP32 (inspired by code reductions required for esp8266).
• Updates to the docs.

ESP32 and ESP8266 users can get their code from this one branch now.