matt_trentini

I'm an Aussie, have travelled pretty widely, am aware of Australia's flaws but, despite them, still think it's one of the best countries to live in.

There are a few; the wESP32 [1] is the nicest I've used but the Olimex ESP32-POE [2] is widely used too.

The maker of the wESP32 also recently released a neat RP2040 based PoE solution you may be interested in: the RP2040-Shim [3] to match the already-existing PoE-FeatherWing [4]. Together, they're a small, neat solution.

(Not involved with those products, just found them well-designed/interesting.)

[1] https://wesp32.com/ [2] https://www.olimex.com/Products/IoT/ESP32/ESP32-POE/open-sou... [3] https://silicognition.com/Products/rp2040-shim/ [4] https://silicognition.com/Products/poe-featherwing/

I'm afraid you are imagining it.

Dart pre-dates Flutter by a few years and had failed (a couple of times) as a web development language before Flutter chose to employ it. Would Dart be around today, outside of Google if not for Flutter? Seems unlikely.

Flutter indeed did decide to pick a niche language, albeit one that was used internally at Google. Tim Sneath discusses it on Software Engineering Radio:

https://www.se-radio.net/2020/12/episode-437-tim-sneath-on-a...

As well as the BLE/WiFi issue, there was another defect that prevented some devices from connecting to the Pico W over BLE reliably. Both have been resolved with this release.

What are you using to transfer the files? I'd be very keen to know if there are issues with the (officially supported) mpremote...

Very cool visualisation!

Though I noticed a couple of odd groupings - like that MicroPython was clustered in Arduinoria rather than the adjacent MicroPythonia... :P

After >10 months, >1000 mainline commits from >100 contributors, we have a new version of MicroPython: Say hello to v1.20.0!

Looks great! Thanks for your work on this.

I had the same minor install issue, specifically needed to do the following:

  >chmod +x git-log-format.sh generate-db.sh
  >python -m venv .venv
  >source .venv/bin/activate
  >pip install flask

I'm not sure the colouring is working as expected; I tried submitting with many email addresses I know are in the repo it ran over (with/out the wildcard) and the highlighting behaviour was difficult to predict.

Thonny is a wonderful, gentle introduction to using MicroPython on devices. It's well-designed and careful thought has been invested in the UI.

However, experienced developers may appreciate the extra features of using their favourite IDE combined with mpremote running in a terminal:

https://docs.micropython.org/en/latest/reference/mpremote.ht...

It's pretty magical to mount your PC filesystem on an embedded device - and extremely productive!

In case you're not aware, there's some promising work on DMA for the rp2 in PR 7641:

https://github.com/micropython/micropython/pull/7641

The company I work for uses MicroPython for medical devices up to Class B. So, yes, it can definitely be used for serious work!

If do you have real-timeish needs, MP makes it pretty easy to write modules in C.

I'm genuinely curious how you've determined that "most activity" is on CircuitPython? I'm close to both projects and they are both highly active. MicroPython tends to be lower-level and a little more under-the-radar, especially since Adafruit provides such a focal point to CircuitPython (and do a great job with it!).

As for libraries; there's a whole lot of MicroPython libs listed on awesome-micropython.com and, if you need to use a CP library in MP, it's often trivial to port.

I was a little surprised to see MicroPython mentioned at all here since there's not really much that Ubuntu is doing to provide that support. I guess it was to refer to the popular RPi Pico, which has official support with MicroPython. CircuitPython support is becoming very close to parity on the Pico though.

(I'm not sure what you mean wrt UF2 on ESP32-S2; it has always worked fine for me? I just tried it again and there were no issues. Note that - unlike the Pico - the UF2 bootloader is not in ROM so you have to install it first.)

We use MicroPython commercially so my perspective is different. :) I do agree with your intent though; just because you're using a high-level language it doesn't excuse you from learning how the hardware works.

However, if you do know the hardware, if you are familiar with what's going on under the hood, then MicroPython allows you to write the majority of your system significantly faster.

Actually, the MicroPython build for the Raspberry Pi Pico W has already been integrated into the CI pipeline:

https://micropython.org/download/rp2-pico-w/

MicroPython provides a way to stop the GC (and an exception will be raised if memory is attempted to be allocated). This provides us with most of the control we require...

They're slower if you spend cpu-intensive time in the interpreter. If you're calling wrappers for C functions then there's little difference. For example, sending SPI or I2C data are effectively identical. Same too if you want to render a QR code using a C library for example [1].

So if you ever find that you need more performance you can drop into C, write a user module, and get the benefit of easier Python syntax and C performance.

The only reason some hardware features aren't supported is a lack of effort to expose those features. Come help us fill in the gaps! :P

[1] https://www.youtube.com/watch?v=437CZBnK8vI (Not my best presentation, I'm sorry; I was running on very little sleep and a high degree of stress!)

RShell is a nice tool but the 'official' way to interact with a MicroPython device is with mpremote [1].

One of the key features of mpremote is that it allows folders to be mounted on your device from your PC.

For me, this allows a workflow that's even more efficient than using USB since no copying is required at all. Work on your PC (often using the unix port in a container [2] to test), then mount the folder and execute on the device. Brilliant. :)

I should probably write up how I use this workflow..!

It would be good to also allow USB volume mounting on more MicroPython ports (stm32 only) as - I agree - it's more intuitive for beginners. But LittleFS [3] is a much more robust filesystem than FAT, which is required for USB mounting. LittleFS is preferred by the core team and has had more focus recently.

[1] https://docs.micropython.org/en/latest/reference/mpremote.ht... [2] https://hub.docker.com/u/micropython [3] https://github.com/littlefs-project/littlefs

I don't personally use the Zephyr port, though it has plenty of potential. But it's worth sharing that the Renode folks have put together a MicroPython on Zephyr dashboard to show that at least 90 of their simulated boards appear to reach the REPL:

https://zephyr-dashboard.renode.io/dashboard-micropython.htm...

Any of those that are passing would be a good board to choose to start with.

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.

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

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.

What are your edge cases?

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

Manufacturing at scale. Though these are medical - not consumer - devices so we're not talking hundreds of thousands of units. Think high-quality, injection molded, moderately sophisticated devices. Typically hundreds and up to several thousands of units, depending on the project.

We use all manner of sensors; temperature, pressure, cap touch, photodiode detection, cameras.

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

Not in my experience; 32 bit MCUs are cheap and powerful these days and reducing the development time by a significant margin - our projects have seen 15-30% reductions compared to our equivalent C estimates - is well worth considering. I'd be more worried about senior engineers that didn't take that seriously.

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

"...only ok on an esp32 with psram"??

I use it on many devices (rp2040, nRF52, ESP32 and, professionally, on STM32). It's an effective platform on all of them.

My company uses it for medical device development, ama if it will help!

It allows typing as you'd expect.

Edit: More specifically, the parser correctly ignores type hints.