5 ms·

The company I work for uses MicroPython commercially to build medical devices. It hasn't fallen apart for us. Indeed, it's helped deliver high-quality solution

The company I work for uses MicroPython commercially to build medical devices. It hasn't fallen apart for us. Indeed, it's helped deliver high-quality solutions quickly...

turbinerneiter 4y ago
You have to have the right people. They have to like Python and want to use it, but not because they think "C is too hard". They have to be happy writing Python code and confident enough to write modules in C and work on MicroPython itself. There is some steps necessary to go from "prototyping MicroPython" to "production MicroPython" and many people either forget about them, are not skilled enough to do them (which is fine, MicroPython is about onboarding people to embedded as well) or they feel like these steps make using MicroPython pointless.
- matt_trentini 4y ago
  > You have to have the right people. Yes, true! I presented a lightning talk to colleagues on "Ingredients for Commercial MicroPython Success". One of the key points is "People are critical". Maybe folks here might find it useful: https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvEqUeuzj1rIY5XyZrW8P_sSggKmZ9vs-TVZNFy_9vdB9rYrVMIcmcg98dfBUoNPIMEKHM/pub https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvE...
IshKebab 4y ago
That's worrying. I can't think of a less appropriate application for something as fragile as Python.
- matt_trentini 4y ago
  The MicroPython interpreter is very robust and well tested. We test our devices extensively. You need to pay attention to gc performance, memory use and fragmentation but this isn't our first rodeo! Systems are typically fragile because of poor system design not language choice. I've worked on many C and C++ systems and there's nothing inherently more robust about them. Some would argue that the various ways you can trip over UB makes them more fragile...
  - IshKebab 4y ago
    > Some would argue that the various ways you can trip over UB makes them more fragile That is definitely a factor! But I probably wouldn't pick C++ for a medical device now anyway - I would go with Ada or Rust. > Systems are typically fragile because of poor system design not language choice. Poor system design and language choice are both factors. You can work around language choice with a shit load of testing, but it's still much better to use a language that gives you stronger guarantees. Also the choice of language affects system design, so it's not like you can just ignore it. For example even ignoring anything memory related, Rust's borrowing system pushes you towards code that has fewer bugs. Python... well, not so much!
    - ok_dad 4y ago
      Bashing Python, or language-bashing in general, makes you sound like an immature and unprofessional programmer. Python is perfectly fine when used in the proper way by a knowledgeable professional, and Rust can be a dangerous tool when used by a beginner. It takes the knowledge of a tool to use it properly and safely; just because someone hit themselves on the head with a hammer doesn't mean hammers are inferior to nail guns and unsafe, they still have their uses in several areas where nail guns aren't the best choice.
      - IshKebab 4y ago
        Sure, Python has its place. But that place is not where you need the software to work extremely reliably. If pointing out relevant and real differences between languages counts as "bashing" then I'm not sure how you are meant to discuss it. Language choice does have an effect on program robustness. That's just a fact. And it's also pretty indisputable that Python lacks many features that help to write robust code. Pretending that isn't true is immature and unprofessional. It has some pros of course - having a REPL is good for experimentation, and it has a great library ecosystem for example. But neither of those are particularly important for commercial medical devices.
        ok_dad 4y ago
- Mascobot 4y ago
  I agree. Using MicroPython in medical applications is with all due respect worrisome. It's not meant to be for crucial tasks and definitely not optimal at all for MCUs. It's really meant to be for simple, hobby applications. It's too high-level (synonym of inefficient) for MCUs. C and Assembly are the way to go for these critical applications (that's why NASA & SpaceX use C and assembly in embedded electronics). Reliability, repeatability and fast performance is key.
  - matt_trentini 4y ago
    Thanks for telling us what MicroPython is for. :P (BTW, I can't vouch for NASA or SpaceX, but it's no secret that the European Space Agency has been working with MicroPython for many years.) I don't disagree that reliability, repeatability and fast performance are (often) key; but our experience suggests that these can be (usually, if not always) achieved with MicroPython.
cozzyd 4y ago
Can you guarantee you never run out of ram? Or do you just restart regularly? (I typically am to scared to even use malloc on a microcontroller...)
- matt_trentini 4y ago
  Managing memory use is one of the key concerns, particularly if you require long uptimes. Memory fragmentation can be a serious issue if you ignore it. But MicroPython's gc is fairly simple and easy to reason with. We've gotten a lot of value out of two useful tools/techniques: 1) Rendering memory use over long periods of time (micropython.mem_info(1) will output a text representation of how memory is used). It's pretty obvious when memory use starts expanding. 2) Turning the gc off in key unit tests so we can be sure critical sections do not allocate (an exception will be raised if memory is requested from the gc). But, of course, memory use in any embedded application is critical.
- deleted 4y ago
  [deleted]
RobertDeNiro 4y ago
Isn't it considered SOUP ? https://en.wikipedia.org/wiki/Software_of_unknown_pedigree https://en.wikipedia.org/wiki/Software_of_unknown_pedigree
- matt_trentini 4y ago
  Yes, but that doesn't give you a free pass. :) My colleague gave a good talk on how we use MicroPython, as SOUP, in our devices: https://www.youtube.com/watch?v=YovngSLXoxw https://www.youtube.com/watch?v=YovngSLXoxw

The company I work for uses MicroPython commercially to build medical devices. It hasn't fallen apart for us. Indeed, it's helped deliver high-quality solutions quickly...

turbinerneiter 4y ago

You have to have the right people. They have to like Python and want to use it, but not because they think "C is too hard". They have to be happy writing Python code and confident enough to write modules in C and work on MicroPython itself. There is some steps necessary to go from "prototyping MicroPython" to "production MicroPython" and many people either forget about them, are not skilled enough to do them (which is fine, MicroPython is about onboarding people to embedded as well) or they feel like these steps make using MicroPython pointless.

matt_trentini 4y ago
> You have to have the right people. Yes, true! I presented a lightning talk to colleagues on "Ingredients for Commercial MicroPython Success". One of the key points is "People are critical". Maybe folks here might find it useful: https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvEqUeuzj1rIY5XyZrW8P_sSggKmZ9vs-TVZNFy_9vdB9rYrVMIcmcg98dfBUoNPIMEKHM/pub https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvE...

IshKebab 4y ago

That's worrying. I can't think of a less appropriate application for something as fragile as Python.

matt_trentini 4y ago
The MicroPython interpreter is very robust and well tested. We test our devices extensively. You need to pay attention to gc performance, memory use and fragmentation but this isn't our first rodeo! Systems are typically fragile because of poor system design not language choice. I've worked on many C and C++ systems and there's nothing inherently more robust about them. Some would argue that the various ways you can trip over UB makes them more fragile...
- IshKebab 4y ago
  > Some would argue that the various ways you can trip over UB makes them more fragile That is definitely a factor! But I probably wouldn't pick C++ for a medical device now anyway - I would go with Ada or Rust. > Systems are typically fragile because of poor system design not language choice. Poor system design and language choice are both factors. You can work around language choice with a shit load of testing, but it's still much better to use a language that gives you stronger guarantees. Also the choice of language affects system design, so it's not like you can just ignore it. For example even ignoring anything memory related, Rust's borrowing system pushes you towards code that has fewer bugs. Python... well, not so much!
  - ok_dad 4y ago
    Bashing Python, or language-bashing in general, makes you sound like an immature and unprofessional programmer. Python is perfectly fine when used in the proper way by a knowledgeable professional, and Rust can be a dangerous tool when used by a beginner. It takes the knowledge of a tool to use it properly and safely; just because someone hit themselves on the head with a hammer doesn't mean hammers are inferior to nail guns and unsafe, they still have their uses in several areas where nail guns aren't the best choice.
    - IshKebab 4y ago
      Sure, Python has its place. But that place is not where you need the software to work extremely reliably. If pointing out relevant and real differences between languages counts as "bashing" then I'm not sure how you are meant to discuss it. Language choice does have an effect on program robustness. That's just a fact. And it's also pretty indisputable that Python lacks many features that help to write robust code. Pretending that isn't true is immature and unprofessional. It has some pros of course - having a REPL is good for experimentation, and it has a great library ecosystem for example. But neither of those are particularly important for commercial medical devices.
      - ok_dad 4y ago
Mascobot 4y ago
I agree. Using MicroPython in medical applications is with all due respect worrisome. It's not meant to be for crucial tasks and definitely not optimal at all for MCUs. It's really meant to be for simple, hobby applications. It's too high-level (synonym of inefficient) for MCUs. C and Assembly are the way to go for these critical applications (that's why NASA & SpaceX use C and assembly in embedded electronics). Reliability, repeatability and fast performance is key.
- matt_trentini 4y ago
  Thanks for telling us what MicroPython is for. :P (BTW, I can't vouch for NASA or SpaceX, but it's no secret that the European Space Agency has been working with MicroPython for many years.) I don't disagree that reliability, repeatability and fast performance are (often) key; but our experience suggests that these can be (usually, if not always) achieved with MicroPython.

cozzyd 4y ago

Can you guarantee you never run out of ram? Or do you just restart regularly? (I typically am to scared to even use malloc on a microcontroller...)

matt_trentini 4y ago
Managing memory use is one of the key concerns, particularly if you require long uptimes. Memory fragmentation can be a serious issue if you ignore it. But MicroPython's gc is fairly simple and easy to reason with. We've gotten a lot of value out of two useful tools/techniques: 1) Rendering memory use over long periods of time (micropython.mem_info(1) will output a text representation of how memory is used). It's pretty obvious when memory use starts expanding. 2) Turning the gc off in key unit tests so we can be sure critical sections do not allocate (an exception will be raised if memory is requested from the gc). But, of course, memory use in any embedded application is critical.
deleted 4y ago
[deleted]

RobertDeNiro 4y ago

Isn't it considered SOUP ? https://en.wikipedia.org/wiki/Software_of_unknown_pedigree https://en.wikipedia.org/wiki/Software_of_unknown_pedigree

matt_trentini 4y ago
Yes, but that doesn't give you a free pass. :) My colleague gave a good talk on how we use MicroPython, as SOUP, in our devices: https://www.youtube.com/watch?v=YovngSLXoxw https://www.youtube.com/watch?v=YovngSLXoxw