undefined | Better HN

0 pointstacticalturtle5mo ago0 comments

I had a problem with the ESP32 implementation specifically. The micropython implementation itself runs as a task under ESP-IDF, rather than bare metal, which is the case on some other microcontrollers like rp2350. So it doesn’t have access to the full resources of the board - as a good chunk is reserved for IDF.

I had a project where I had would make repeated API calls, which returned small to moderate json payloads.

To avoid running out of heap, I had to constantly force python garbage collection. That took a long time, so I wasn’t able to call the APIs on the intervals I needed.

Eventually I gave up and moved to using ESP IDF directly, which IMO was super easy to do - Espressif has made a great integration with VS Code. If anyone’s on ESP32, i would skip micropython.

0 comments

yuye5mo ago

>If anyone’s on ESP32, i would skip micropython.

I've used MicroPython for prototyping. It's quite nice with its REPL.

However, for more than a simple proof of concept I wouldn't use MicroPython at all, on any platform.

My personal gatekeepey opinion is that if you want to learn embedded, you really should go for C. (C++ or Rust also exist, but C should be the first)

nomel5mo ago

I don't think that deserves to be categorized as a "reliability" problem. I don't think that's technically a reliability problem.

Sounds like it was reliable, with the problem being that it's much much slower than bare metal (a very well known thing), with the microcontroller not having the required processing power to service your task in that context.

Dropping into C for performance critical code is something you sometimes need to do with python, regardless of platform, because it's slowwwwww anywhere it runs. You'll always hit a ceiling, and much much sooner on a microcontroller.

j / k navigate · click thread line to collapse