Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MicroPython – Python for Microcontrollers

micropython.org

Post reply on HN
Print view View original

71–80 of 106 posts

Re: MicroPython – Python for Microcontrollers

#71

Post by MarcScott »

If you have kids and you want to give them some experience with physical computing and MicroPython, can I suggest our resources at https://projects.raspberrypi.org/en/pathways/pico-intro

They're pretty simple and very creative, and the Raspberry Pi Pico is about the only Raspberry Pi device you can get hold of at the moment.

We've created an abstracted package called picozero, that makes turning on LEDs and reading sensors pretty simple in MicroPython. It's very easy to install and use, if you're using the Thonny editor - https://github.com/RaspberryPiFoundation/picozero

Re: MicroPython – Python for Microcontrollers

#72

Post by IshKebab »

matt_trentini wrote: post #45
SOLAR_FIELDS wrote: post #2

I did a lot of product development using Micropython over the past year or so. There are certain things it is very good at - one is rapid prototyping. For instance it’s a lot easier and faster and less verbose to quickly get some http server communication going on the ESP32 in Micropython rather than the C equivalent. The downsides are somewhat dramatic though - it’s, of course, a lot slower and hungrier for memory t…

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...

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

Re: MicroPython – Python for Microcontrollers

#73

Post by nimmer »

amelius wrote: post #48
j-james wrote: post #16

A possible alternative to MicroPython is Nim - it's a strongly typed language with Python-like syntax that compiles down to C. Since it compiles to C, it can use existing C libraries without much fuss (just wrap signatures as needed), plus there's no need for a "micro" version of the language. Several members of the community have been working on improving the embedded ecosystem: although I haven't played around with…

Nim, Zig, Julia, Rust, so many languages lately ... anyone else with language-choice anxiety?

Nim is a very good choice because it generates tiny binaries while having a very expressive syntax.

It's the closest language to a static typed Python.

Also it uses GCC, which supports most microcontrollers.

Re: MicroPython – Python for Microcontrollers

#74

Post by matt_trentini »

IshKebab wrote: post #72
matt_trentini wrote: post #45

Earlier quoted context omitted.

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...

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

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...

Re: MicroPython – Python for Microcontrollers

#75

Post by cozzyd »

matt_trentini wrote: post #45
SOLAR_FIELDS wrote: post #2

I did a lot of product development using Micropython over the past year or so. There are certain things it is very good at - one is rapid prototyping. For instance it’s a lot easier and faster and less verbose to quickly get some http server communication going on the ESP32 in Micropython rather than the C equivalent. The downsides are somewhat dramatic though - it’s, of course, a lot slower and hungrier for memory t…

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...

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...)

Re: MicroPython – Python for Microcontrollers

#76

Post by gjkood »

For those new to MicroPython or to the ESP8266 line of microprocessors here is a talk that I gave at a PyCaribbean conference in 2017. [1]

Its a bit long winded but I tried to touch upon everything that a new entrant to the space would want to know to start playing with the board immediately.

I am not a natural public speaker so please excuse my verbal (or other) tics.

I have also linked the presentation PDF. [2] You can scan the entire PDF in less than 10 minutes to get the gist of the 45 minute+ YouTube video.

[1] https://www.youtube.com/watch?v=6ctB8VMm6RA

[2] https://github.com/spicecoaster/pycaribbean2017

Re: MicroPython – Python for Microcontrollers

#77

Post by RobertDeNiro »

matt_trentini wrote: post #45
SOLAR_FIELDS wrote: post #2

I did a lot of product development using Micropython over the past year or so. There are certain things it is very good at - one is rapid prototyping. For instance it’s a lot easier and faster and less verbose to quickly get some http server communication going on the ESP32 in Micropython rather than the C equivalent. The downsides are somewhat dramatic though - it’s, of course, a lot slower and hungrier for memory t…

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...

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

Re: MicroPython – Python for Microcontrollers

#78

Post by matt_trentini »

cozzyd wrote: post #75
matt_trentini wrote: post #45

Earlier quoted context omitted.

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...

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...)

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.

Re: MicroPython – Python for Microcontrollers

#79

Post by matt_trentini »

RobertDeNiro wrote: post #77
matt_trentini wrote: post #45

Earlier quoted context omitted.

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...

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

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

Re: MicroPython – Python for Microcontrollers

#80

Post by IshKebab »

matt_trentini wrote: post #74
IshKebab wrote: post #72

Earlier quoted context omitted.

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

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…

> 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!

Post reply on HN