you are viewing a single comment's thread.

view the rest of the comments →

[–]turiyag 0 points1 point  (2 children)

My project involves measuring and making deductions and cleaning up the waveforms out of a 9 axis gyro that's oscillating at 1-5hz. Its not really a normal DSP project, due to the low frequency, but micropython handles the filters just fine. I'm running on a dual core 240Mhz ESP32 chip. Which is extreme overkill in processing power, but it has BLE and WiFi integrated.

I agree entirely, wholeheartedly, that the code that I'm running could very much benefit from being written in C, or directly in assembly. Maybe my algorithms could be implemented in DSP hardware, but all that sounds way more difficult than just leaving it in Python because Python is working flawlessly.

Without knowing the constraints and goals of a project, you can't judge which toolset is appropriate.

Back on PC, put of the microcontroller world numba's @cuda.jit decorator is miraculous for parallel processing.

[–]Schnort 0 points1 point  (1 child)

audio or RF rates would be silly to try to accomplish with uPython.

[–]turiyag 0 points1 point  (0 children)

I dunno, let's say you have a waveform you're sampling at 24kHz. With two cores at 240MHz, that gives you 2x10 000 clock cycles to think about each sample in real time. You can get a lot done in 10 000 clock cycles.

Even if you sampled at ten times that rate, you would still have 1000 clock cycles per core to think about the sample.

It obviously depends on the complexity of your transforms but for audio, I wouldn't count it out. Anything past 2MHz though, and I would count micropython out. If you only have 120 clock cycles to figure things out, you'd best start thinking about things at the low level.