Qn: Use of mp_sched_schedule for io streams (eg. ubluetooth).

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
Posts: 36
Joined: Mon Jun 04, 2018 10:09 am

Qn: Use of mp_sched_schedule for io streams (eg. ubluetooth).

Post by glenn20 » Tue May 11, 2021 1:15 am

I want to clarify what might be a misunderstanding on my part about using mp_sched_schedule for IO streams. This arises from my experiences developing the ESPNow support (ESP32/8266) and inspection of other code (esp. modbluetooth.c).

TL,DR: Why does ubluetooth use user callbacks (running in a "sched" context via BLE.irq) for event handling rather than pushing incoming event data onto a queue/buffer as an io stream which can then be read by user code without the limitations of the "sched" context?

I found that relying on the scheduler stack was quite fragile for sustained IO in the early versions of the espnow developent. It was very easy to overflow the scheduler stack at quite moderate packet rates for receiving data. This was easy to overcome (mostly) by ensuring each scheduled function processed all available data. However, if I had other sources of scheduled functions (eg, timer, GPIO pins, bluetooth) the interaction between them made each other unreliable: ie. a burst of GPIO interrupts or bluetooth events could crowd out espnow callbacks and vice-versa.

I see the value in the use of scheduled "irq" callbacks when an interrupt needs to be serviced by user code with the least possible latency (eg. to assert hardware responses which require user design). However, that is not the case for an IO stream like espnow. So, I changed to a traditional ringbuffer-based IO queue which is read by user "recv()/read()" calls (rather than callbacks).

However, I see that this seems not to be the usual design choice in micropython - and I am wondering if I am missing something important - especially if my choices are holding back my ESPNow PR from being merged ;-).

Cheers & Thanks for any responses.

Post Reply