You might be interested in ulab for FFT and other numpy-ish things: https://micropython-ulab.readthedocs.io/en/latest/ulab.html#...
Re:MicroPython
by matt_trentini on Sunday August 16, 2020 @09:53PM
(#24183102)
> one uses a FFT and the other an interrupt running at 170 kHz
Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.
Yes, definitely. Any application that I can think of off the top of my head involves adding C code. This is not a hurdle, but would be for someone who is using Python to get into embedded programming at a beginner level. From the MicroPython documentation:
>>>Compiling the cmodule into MicroPython
>>>To build such a module, compile MicroPython (see getting started) with an extra make flag named USER_C_MODULES set to the directory containing all modules you want included (not to the module itself). For example: ...
This is not precisely for the faint of heart, but should not be prohibitive for a seasoned embedded developer. ;-)
My rationale for saying this is that in addition to programming in any language, you need to understand hardware, including safety. And I think that by the time a person reaches that level of knowledge, they have probably familiarized themselves with programming at a variety of levels from bare-metal C up to desktop software.
Now, I've only been playing with MicroPython (actually the CircuitPython fork) for a few months, and at this point haven't come up with a "scale" of project that needs more than bare metal C but less than a full blown operating system. But then again I haven't come up with any good product ideas in that time period.
As I mentioned to a friend of mine: "Hi, we're programmers, and we're here to burn your house down."
Between the two real projects that I'm nursing along right now, one uses a FFT and the other an interrupt running at 170 kHz, so neither of those can be pure Python projects yet.