pythoncoder wrote: ↑Sat Mar 30, 2019 8:26 am
It's worth noting that uasyncio is not well suited to low power operation. On the Pyboard this can be mitigated by replacing the uasyncio timebase with one derived from the RTC, and I have written a solution documented here. This needs testing with the Pyboard D, but it's no help for ESPx boards. I also think that most MQTT applications will want to subscribe (with a timely response) as well as publish.
Interesting. I had assumed that uasyncio designs would never be possible when a device is placed into an ultra low power sleep mode (like ESP deepsleep). I'll check out your link.
pythoncoder wrote: ↑Sat Mar 30, 2019 8:26 am
I have started work on the asynchronous MQTT library to improve ESP32 support and to provide Pyboard D support.
Sweet. I'll stay tuned in for that work
pythoncoder wrote: ↑Sat Mar 30, 2019 8:26 am
what sample rate are you using?
Here is what is possible...
1.
20kHz sampling for reading an I2S microphone, with continuous, gapless, writing of 16bit audio samples to SD card:
- limiting factors are variations in SDCard sector write times. Sometimes an SD Card may write a sector in say 3ms, other times I've seen back-to-back sector writes in excess of 50ms. Maybe I need to find a better SD Card?
- garbage collection is also a bit of a wildcard. Here, an adequate DMA buffering of samples is your friend. In a worst case, a secondary FIFO RAM buffer can be implemented to further extend the DMA buffering - the psRAM version of the ESP32 is needed for this.
- assumes resolution reducing (X bits -> 16bits) routine is a uPy module written in C.
- using 128kB of DMA memory. This provides a buffer sample window of 371ms which is enough to "absorb" blocking interruptions such as garbage collection and slow SD sector writes.
- uses uasyncio with fast_io implementation.
- I2S loop only yields to the scheduler when read requests to the DMA buffer come back empty. This point is key.
2.
44.1kHz sampling for reading of an I2S mic and doing C or ASM based processing of the samples.
- for example, it takes 5.8ms to accumulate 256 audio samples from a typical I2S microphone at 44.1kHz sample rate
- the accumulation of samples happens entirely in the background using DMA. Processing of samples happens in the foreground. The ESP32 does this well.
- in practice, the application loop has about 4ms of processing time out of the 5.8ms (on average). uPy will be too slow for most, if not all stream processing demands. But, it should easily possible to process the samples using a C-based uPy module implementation. e.g C-based FFT module.
Above is based on the ESP I2S module I submitted as a PR. C-based, using the ESP-IDF.
https://github.com/miketeachman/micropy ... hine_i2s.c
https://github.com/miketeachman/micropy ... c292e622f2
https://github.com/miketeachman/micropy ... s-examples
note: When my pyboard d arrives I'll work an I2S PR for it.
alright... likely more than you wanted for this post...