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

MicroPython

micropython.org

Post reply on HN
Print view View original

131–140 of 152 posts

Re: MicroPython

#131

Post by Abishek_Muthian »

neilpanchal wrote: post #129
Abishek_Muthian wrote: post #120

Earlier quoted context omitted.

I understand what value MicroPython holds for Python community who want to get into embedded computing. But aren't these contradictory - >but it is time to ditch C/C++ for MicroPython. >Therefore, it is critical to put performance demanding code in C/C++ modules and compile a MicroPython bindings I understand that these are underlying issues of Python itself and I've been burned before because of it. Had a massive py…

Thanks for the insight, in your experience how has the performance been?

With Go? It's magnitude faster than python and it's concurrency might be paralleled maybe only by elixir although I wonder whether the later would match Go's utility based programming paradigm which results in faster roll-outs.

My subjective opinion is, the only place I wouldn't consider using Go is when it's garbage collection could hypothetically be harmful(literally) i.e. Say I'm coding a system for a ventilator, I will either go with traditional/proven language for that environment like C or a newer, safer alternative like Rust.

Re: MicroPython

#132

Post by jennasys »

dheera wrote: post #76
neilpanchal wrote: post #28

MicroPython is stellar. If you're building an embedded system for people to hack and customize, make the highest level abstraction of the embedded system in MicroPython so that users can easily modify/patch/contribute/hack your system with ease. This is what Arduino and Arduino IDE did for millions of hobbyist, but it is time to ditch C/C++ for MicroPython. In this [1] PyCon talk by Matt Trentini, a demo of QR code g…

The one big issue I've had with MicroPython is that it's a PITA to manage files on it. I use this hacky tool called "ampy" to do it, and wish that the device could just be mounted as a media device. CircuitPython, however, does accomplish this, with the microcontroller showing up just like a USB drive.

Some Python IDEs like Thonny and PyCharm can seamlessly do file transfers for you over serial. Thonny has actually been a great tool for that on ESP boards.

This was one of the reasons CircuitPython was forked from MicroPython. Adafruit wanted consistency across all the platforms they sold and one of the features they insisted on was the USB drive support to make it easier for the educational market they cater to.

Re: MicroPython

#133

Post by [deleted] »

askvictor wrote: post #118
matt_trentini wrote: post #111

Earlier quoted context omitted.

Yes, this is a complete game-changer; I love showing experienced embedded engineers how to connect to the REPL, and poke live, interactive I2C or SPI at a peripheral. :)

I only wish Micropython had a real debugger (pdb).

[deleted]

Re: MicroPython

#134

Post by mch82 »

Abishek_Muthian wrote: post #120
neilpanchal wrote: post #28

MicroPython is stellar. If you're building an embedded system for people to hack and customize, make the highest level abstraction of the embedded system in MicroPython so that users can easily modify/patch/contribute/hack your system with ease. This is what Arduino and Arduino IDE did for millions of hobbyist, but it is time to ditch C/C++ for MicroPython. In this [1] PyCon talk by Matt Trentini, a demo of QR code g…

I understand what value MicroPython holds for Python community who want to get into embedded computing. But aren't these contradictory - >but it is time to ditch C/C++ for MicroPython. >Therefore, it is critical to put performance demanding code in C/C++ modules and compile a MicroPython bindings I understand that these are underlying issues of Python itself and I've been burned before because of it. Had a massive py…

I wonder how many projects really need the performance?

Most projects are integrating parts into a whole. While expert programmers might be needed to create the parts & package them as libraries, how often is the same true of larger assemblies of parts that solve a domain problem?

Blueprints in Unreal Engine are an interesting case study. Programmers create components in C++ and expose APIs for them. Level designers use Blueprints to integrate & orchestrate those components into levels, without the same need for programming expertise.

Re: MicroPython

#135

Post by Abishek_Muthian »

mch82 wrote: post #134
Abishek_Muthian wrote: post #120

Earlier quoted context omitted.

I understand what value MicroPython holds for Python community who want to get into embedded computing. But aren't these contradictory - >but it is time to ditch C/C++ for MicroPython. >Therefore, it is critical to put performance demanding code in C/C++ modules and compile a MicroPython bindings I understand that these are underlying issues of Python itself and I've been burned before because of it. Had a massive py…

I wonder how many projects really need the performance? Most projects are integrating parts into a whole. While expert programmers might be needed to create the parts & package them as libraries, how often is the same true of larger assemblies of parts that solve a domain problem? Blueprints in Unreal Engine are an interesting case study. Programmers create components in C++ and expose APIs for them. Level designers…

>I wonder how many projects really need the performance?

Anything scalable can make use of performance improvements, so that means production applications with hundreds and thousands of concurrent users is a right example in my experience. Apart from better usability, performance enhancements results directly in greater capital-efficiency(server costs).

Re: MicroPython

#136

Post by ac29 »

analog31 wrote: post #79
ak_25 wrote: post #2

I think this is good for someone getting started with microcontrollers(similar to the Arduino) However, one should not be disillusioned — I doubt this can be used to deploy a mass market product. However, I can see micro-python’s value in rapid-prototyping to some extent for someone who is not into embedded/firmware as much.

In my view, nothing can be used to deploy a product, without further consideration. My rationale for saying this is that in addition to programming in any language, you need to understand hardware, including safety. And I think that by the time a person reaches that level of knowledge, they have probably familiarized themselves with programming at a variety of levels from bare-metal C up to desktop software. Now, I'v…

You might be interested in ulab for FFT and other numpy-ish things: https://micropython-ulab.readthedocs.io/en/latest/ulab.html#...

Re: MicroPython

#137

Post by stinos »

IgorPartola wrote: post #83
neilpanchal wrote: post #28

MicroPython is stellar. If you're building an embedded system for people to hack and customize, make the highest level abstraction of the embedded system in MicroPython so that users can easily modify/patch/contribute/hack your system with ease. This is what Arduino and Arduino IDE did for millions of hobbyist, but it is time to ditch C/C++ for MicroPython. In this [1] PyCon talk by Matt Trentini, a demo of QR code g…

I haven’t looked at the latest advancements with MicroPython, but last I checked it was both slow and unsafe in ways I wasn’t used to, such as certain language features not being allowed in interrupt handlers, certain operations being interruptible, etc. I totally hear what you are saying about building stuff for less technical people to hack on, but as someone comfortable with C ( gasp! shock! ), I prefer the predic…

Not really following the logic wrt predictability. I mean, you run it on a microcontroller so yes things can be interrupted. Just like in C. And while allocation not being allowed in an interrupt handler can be annoying, it's also predictable once you know it. And no matter what language you use, you don't go wild in an interrupt handler on a microcontroller anyway.

Re: MicroPython

#138

Post by mkesper »

mlyle wrote: post #81
zackees wrote: post #30

Earlier quoted context omitted.

Great so now in order to create a performant embedded app i need to write everything in two languages. We should make Rust compile to Arduino and other embedded devices and be done with it.

There's a real advantage to having an interpreter. Write your low-level/high performance code in whatever. Then write top-level logic-- and let your users script in-- micropython. I'm teaching a middle school class this year with micropython on embedded. I can't fit Rust in with everything else I'm teaching in one trimester. I've even written an IDE which runs in the browser (on chromebook, etc) so there's no externa…

Which boards are you using and how did you chose them?

Re: MicroPython

#139

Post by stinos »

pansa2 wrote: post #14

MicroPython seems to be heavily focused on embedded systems . Is there any support for embedding it within an application , i.e. as a replacement for Lua? Or is there another lightweight Python implementation (or Python-like language) that supports this?

We've been running it like that for multiple desktop applications for years. So it's supported in the sense that it works but depending on what you do with it exactly it needs some boilerplate code which mostly means copy-pasting some parts from one of the main.c files for the different ports, no big deal. Creating bindings is another point which requires boilerplate code but that's no diferent from other scripting embeddings.

Re: MicroPython

#140

Post by keyme »

noobermin wrote: post #32

Does anyone have any experience beyond short programs/sketches with micropython? The most I've used it for is playing around with a microbit. How does it hold up?

Had it manage an Ethernet Phy IC via an MDIO interface, and an FPGA over SPI. The MDIO was bit-banged from micropython, and SPI is a built in feature. This was running on an ESP32 creating a WiFi to Gigabit Fiber bridge (obviously not at gigabit speeds).

I never thought it would be that easy, but it converted the task of writing something that does MDIO, SPI, and WiFi (with a webserver) in C, to basically a day of work.

Also the "feel" of running an interactive python shell on a tiny 1x3cm board as part of the initial bring-up process after manufacturing is just awesome. Controlling every IO "manually" via the interactive shell is so much better than seeing your prepared C code crash and burn, and only then start debugging it.

Post reply on HN