4 ms·

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 (

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.
- markhahn 3y ago
  it's funny that when "discipline and rigor" is advocated for, the underlying premise is basically "pain builds character".
  - bborud 3y ago
    Quite the opposite. You can essentially choose what kind of pain you want. On one hand you can have the pain of having to work with a compiler and toolchain that aims to eliminate problems early by requiring you to be more consistent and more correct. On the other hand you can choose to deal with the pain later - as your errors and inconsistencies come back to haunt you later. Or if you are a professional: have to invent your own consistency and error checks through extensive testing. Not that I would expect rigorous test from someone who chooses to avoid compilers that can help them write higher quality code. It is a lot more painful to have to deal with errors later, than it is to deal with them as you write the code. Not least in terms of financial pain and risk. For a lot of embedded systems "just updating the software" isn't always easy, it usually carries significant risk, and it isn't always even possible depending on how something is deployed. Or to express the above with fewer words: you can choose between pain now and pain later. As for tooling: using an interpreted language like Python means that it will only work for as long as the runtime environment is in a particular state. That all the right libraries are available in the right versions, and even the language runtime itself. Thousands upon thousands of files splattered across your filesystem. Every update of any part of the environment risking you suddenly have to spend days figuring out how to get things to work again. Brittle toolchains are a pain. Don't waste time on things that lead to brittle toolchains. I see a lot of hobbyists downplaying this online. I don't see a lot of people who work on this full time downplaying it. Be it people I know at MCU manufacturers who have to support customers or companies that manufacture devices and have large teams of embedded developers who regularly have to waste time because every new release means weeks of getting builds to behave somewhat predictably and reproducibly. Having more modern compilers and tooling that can be relied upon isn't about more pain. It is about considerably less pain. If dealing with a compiler that is strict is too much pain for you, then embedded programming probably isn't for you. Because having lax compilers (or no compiler) means you'll learn about your mistakes when it is quite possibly too late to do anything about them. C/C++ are not very nice languages if you want to ensure quality. Python gives you a sense of productivity over C/C++, but it provides no added benefit in terms of quality and de-risking. Rather the opposite because even the meager discipline a C/C++ compiler gives you is more than what Python gives you.

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.

markhahn 3y ago
it's funny that when "discipline and rigor" is advocated for, the underlying premise is basically "pain builds character".
- bborud 3y ago
  Quite the opposite. You can essentially choose what kind of pain you want. On one hand you can have the pain of having to work with a compiler and toolchain that aims to eliminate problems early by requiring you to be more consistent and more correct. On the other hand you can choose to deal with the pain later - as your errors and inconsistencies come back to haunt you later. Or if you are a professional: have to invent your own consistency and error checks through extensive testing. Not that I would expect rigorous test from someone who chooses to avoid compilers that can help them write higher quality code. It is a lot more painful to have to deal with errors later, than it is to deal with them as you write the code. Not least in terms of financial pain and risk. For a lot of embedded systems "just updating the software" isn't always easy, it usually carries significant risk, and it isn't always even possible depending on how something is deployed. Or to express the above with fewer words: you can choose between pain now and pain later. As for tooling: using an interpreted language like Python means that it will only work for as long as the runtime environment is in a particular state. That all the right libraries are available in the right versions, and even the language runtime itself. Thousands upon thousands of files splattered across your filesystem. Every update of any part of the environment risking you suddenly have to spend days figuring out how to get things to work again. Brittle toolchains are a pain. Don't waste time on things that lead to brittle toolchains. I see a lot of hobbyists downplaying this online. I don't see a lot of people who work on this full time downplaying it. Be it people I know at MCU manufacturers who have to support customers or companies that manufacture devices and have large teams of embedded developers who regularly have to waste time because every new release means weeks of getting builds to behave somewhat predictably and reproducibly. Having more modern compilers and tooling that can be relied upon isn't about more pain. It is about considerably less pain. If dealing with a compiler that is strict is too much pain for you, then embedded programming probably isn't for you. Because having lax compilers (or no compiler) means you'll learn about your mistakes when it is quite possibly too late to do anything about them. C/C++ are not very nice languages if you want to ensure quality. Python gives you a sense of productivity over C/C++, but it provides no added benefit in terms of quality and de-risking. Rather the opposite because even the meager discipline a C/C++ compiler gives you is more than what Python gives you.