8 ms·

MicroPython offers a great alternative to memory-safe ESP32 programming. It is a battle tested option with a great REPL and many optimization, including the nat

MicroPython offers a great alternative to memory-safe ESP32 programming. It is a battle tested option with a great REPL and many optimization, including the native and Viper code emitters that are quite fast. It has so many available primitives and access to the hardware that if you wish you can write even the drivers for your peripherals directly in Python.

Kuinox 3y ago
MicroPython isn't a great choice for these chips, you often want the minimal power consumption since you often run on battery, and MicroPython is extremely slow. https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6 https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6.
- asyx 3y ago
  The ESP chips are barely power efficient enough to run on battery with C. Like, honestly, I'd not put anything but compiled languages without some sort of runtime on those chips except if I have something like "update an eink display twice a day" use cases.
  - Kuinox 3y ago
    I'm trying to make a natural gas usage live monitoring, I reused a single use e-cig battery (that is rechargeable). From calculation it should last at least a year in deep sleep.
  - jLaForest 3y ago
    >The ESP chips are barely power efficient enough to run on battery with C. Incorrect, Esp32-s3 uses 8 micro amps in deep sleep.
    - doug_life 3y ago
      8uA is still large compared to some other options. I work on medical implants that average 15uA while actively sensing biological signals 24hr/day. This includes the analog front end hardware to condition the signals as well. 8uA of deep sleep current would be a non starter.
      - markhahn 3y ago
        and your devices probably don't cost $3 on aliexpress, right?
      - antoniuschan99 3y ago
        Wow that’s amazing what components are some of those?
  - fulafel 3y ago
    How much does power usage of computation tend to matter in microcontroller applications? Vs "sleep" state power usage and being smart about waking up.
  - brianhorakh 3y ago
    You do realise that there are two architecture xtensa & RISC v. RISC v isn't as power efficient. The xtensa super low power mode can deep sleep, wake on timer or external interrupt, and (based on duty cycle) probably run for year or more on a 9v battery. Micropython is similar in performance to Arduino on esp32. Poor Async, around 10x slower than rust and much harder to do Async, etc. Possibly better for beginners, but even that won't be true in another year thanks to projects like embassy-rs Rust and C have similar compiled performance. The difference is rust Dev on esp32 is easier to target with other architectures, also rust will probably be a bit easier to detect & debug any crashes during design making it a lower cost to develop than C equivalent (because C is more permissive, it's easier to make accident mistakes)
- antirez 3y ago
  I respectfully disagree, after performing many months of tests with the same application I wrote both in C and in MicroPython, both in battery-powered devices (you can find it on Github: FreakWAN). Moreover, when battery usage is really important, the main factor is the standby power usage. Anyway the device will only wake-up briefly to do a few things and shut it down again. It is unlikely you do heavy computations inside the device for the moments it is awake, you mostly do things like I/O with sensors and communication. So MicroPython is absolutely viable.
  - bborud 3y ago
    Without numbers and sensible tests that allow us to compare this in a systematic manner, neither of your manage to make a strong case for your position. That being said, my professional opinion is that Python on MCUs is a dead end. The only attraction I can see is that people who aren't comfortable with C have an easier time programming microcontrollers. And to be very direct: I really, really would not hire someone who is uncomfortable with C to program MCUs. I think Rust is the right direction to move in for MCUs. Low power devices are getting faster and now have more RAM, Flash and onboard goodies. That means they are going to do more stuff and more sophisticated stuff. They'll get more "responsibility". Which means that more will be asked of programmers in an industry that isn't exactly known for good software design. Rust is a step towards better helping programmers write better software. It is a step towards helping developers write software with much larger footprints and deal with project scale. It has a compiler that can help you and there are more and more tools that help you verify code for correctness. This is important when you a) write code for a constrained environment and b) write code that may interact directly with the physical world. This is the _opposite_ of going in the direction of Python. We don't need less rigor and discipline. We need a lot more rigor and discipline. We also need better tooling. C/C++ compilers are stuck in the past and make for brittle and messy build systems. The fact that Python is often used to automate embedded SDKs and RTOS doesn't exactly make things better. A lot of time is wasted every year on trying to deal with the fact that Python isn't a compiled language and thus keeps breaking whenever some configuration changes. Python isn't even suitable for writing stable tooling. Rust has much better tooling. I don't doubt that there are people who are happy with micropython. Good. Go be happy. But it is not what the industry needs (or even uses) for embedded development.
deleted 3y ago
[deleted]

Kuinox 3y ago

MicroPython isn't a great choice for these chips, you often want the minimal power consumption since you often run on battery, and MicroPython is extremely slow. https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6 https://youtu.be/u9UfKTOcYNs?si=ZiDxe_jsXfauOzR6.

asyx 3y ago
The ESP chips are barely power efficient enough to run on battery with C. Like, honestly, I'd not put anything but compiled languages without some sort of runtime on those chips except if I have something like "update an eink display twice a day" use cases.
- Kuinox 3y ago
  I'm trying to make a natural gas usage live monitoring, I reused a single use e-cig battery (that is rechargeable). From calculation it should last at least a year in deep sleep.
- jLaForest 3y ago
  >The ESP chips are barely power efficient enough to run on battery with C. Incorrect, Esp32-s3 uses 8 micro amps in deep sleep.
  - doug_life 3y ago
    8uA is still large compared to some other options. I work on medical implants that average 15uA while actively sensing biological signals 24hr/day. This includes the analog front end hardware to condition the signals as well. 8uA of deep sleep current would be a non starter.
    - markhahn 3y ago
      and your devices probably don't cost $3 on aliexpress, right?
    - antoniuschan99 3y ago
      Wow that’s amazing what components are some of those?
- fulafel 3y ago
  How much does power usage of computation tend to matter in microcontroller applications? Vs "sleep" state power usage and being smart about waking up.
- brianhorakh 3y ago
  You do realise that there are two architecture xtensa & RISC v. RISC v isn't as power efficient. The xtensa super low power mode can deep sleep, wake on timer or external interrupt, and (based on duty cycle) probably run for year or more on a 9v battery. Micropython is similar in performance to Arduino on esp32. Poor Async, around 10x slower than rust and much harder to do Async, etc. Possibly better for beginners, but even that won't be true in another year thanks to projects like embassy-rs Rust and C have similar compiled performance. The difference is rust Dev on esp32 is easier to target with other architectures, also rust will probably be a bit easier to detect & debug any crashes during design making it a lower cost to develop than C equivalent (because C is more permissive, it's easier to make accident mistakes)
antirez 3y ago
I respectfully disagree, after performing many months of tests with the same application I wrote both in C and in MicroPython, both in battery-powered devices (you can find it on Github: FreakWAN). Moreover, when battery usage is really important, the main factor is the standby power usage. Anyway the device will only wake-up briefly to do a few things and shut it down again. It is unlikely you do heavy computations inside the device for the moments it is awake, you mostly do things like I/O with sensors and communication. So MicroPython is absolutely viable.
- bborud 3y ago
  Without numbers and sensible tests that allow us to compare this in a systematic manner, neither of your manage to make a strong case for your position. That being said, my professional opinion is that Python on MCUs is a dead end. The only attraction I can see is that people who aren't comfortable with C have an easier time programming microcontrollers. And to be very direct: I really, really would not hire someone who is uncomfortable with C to program MCUs. I think Rust is the right direction to move in for MCUs. Low power devices are getting faster and now have more RAM, Flash and onboard goodies. That means they are going to do more stuff and more sophisticated stuff. They'll get more "responsibility". Which means that more will be asked of programmers in an industry that isn't exactly known for good software design. Rust is a step towards better helping programmers write better software. It is a step towards helping developers write software with much larger footprints and deal with project scale. It has a compiler that can help you and there are more and more tools that help you verify code for correctness. This is important when you a) write code for a constrained environment and b) write code that may interact directly with the physical world. This is the _opposite_ of going in the direction of Python. We don't need less rigor and discipline. We need a lot more rigor and discipline. We also need better tooling. C/C++ compilers are stuck in the past and make for brittle and messy build systems. The fact that Python is often used to automate embedded SDKs and RTOS doesn't exactly make things better. A lot of time is wasted every year on trying to deal with the fact that Python isn't a compiled language and thus keeps breaking whenever some configuration changes. Python isn't even suitable for writing stable tooling. Rust has much better tooling. I don't doubt that there are people who are happy with micropython. Good. Go be happy. But it is not what the industry needs (or even uses) for embedded development.

deleted 3y ago

[deleted]