matt_trentini

As an Australian tech worker, that list certainly doesn't seem that privileged. Excluding the Aeron, none of those would be surprising for any of my colleagues - and a few do have Aerons (all have decent chairs).

We spend a lot of time at our desk and so spending a few thousand dollars to create a comfortable workspace is far from exorbitant.

Just beware that FATFS is very easy to corrupt in the event of power outages - unless it's read-only.

Personally I would be reluctant to use FATFS as a writable filesystem on a commercial embedded device.

It's one of the filesystem options in MicroPython and we've used it extensively for a number of (medical device) products. It's been bullet-proof for us.

Some, you know, _actual benchmarks_ might be nice too. The claims are certainly possible, but somewhat hollow without evidence...

It's an excellent educational device to introduce people to embedded development.

I'd like to work on tailoring a mainline MicroPython build to their boards - to support their peripherals - but it has, so far, been low on my priority list.

I run a MicroPython meetup and many of the members use the ESP32. Due to it's rich feature set and low price it's basically the gateway drug to MicroPython...

It's not (nearly!) the same but if you're interested in audio applications it's worth noting that I2S support was added to MicroPython recently - and will work on the TinyPICO.

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

Just be aware that PyCom chose to fork the MIT-licensed MicroPython and re-licensed it with GPL.

As a MicroPython contributor I can't/won't use PyCom's fork because any code I develop for it cannot be accepted upstream.

I do like their hardware, it's a shame they chose to make their software licensing incompatible.

The ESP32 is vastly more powerful than the ESP8266. Dual core, each core is more powerful, it has BLE, more RAM, flash, GPIO - as well as a handful of other useful peripherals (RMT, PWM etc).

Now, the TinyPICO is more expensive than some ESP32 boards but that's because it's been engineered well and is manufactured in Australia by a maker that goes out of his way to support his products.

Slightly different. And also covered on Ian's Shoelace Site: https://www.fieggen.com/shoelace/berluti-knot.htm

Take a look at flynt, a tool that can convert older string formatting code to the newer fstring style. I've found it very helpful!

https://github.com/ikamensh/flynt

...or not and realise that professional development is not only possible in MicroPython but can significantly reduce development time - and costs - to your client.

(I work for a company that makes medical devices that use MicroPython.)

The difference in real-world use isn't nearly so pronounced in my experience. MicroPython is written in C, so whenever you're using modules implemented natively then you're only paying for a small boundary crossing.

For example, all of the machine API is typically very fast. I'd be surprised if you'd notice a significant improvement sending SPI buffers directly from C. But it's way more convenient from MicroPython - especially considering you can do it live at a REPL.

If you're spending a lot of time processing in MicroPython then yes, you'll notice a perf hit. But, if that's the case, carve out the perf-sensitive code and create a C module in MicroPython; it's straightforward.

It's akin to the way that CPython is considered slow but by using libraries like numpy or pandas the real-world performance is decent.

> But there are plenty of differences between MicroPython and CPython

Are there any differences there that you'd consider significant? They are generally quite minor and usually have workarounds. Typically a difference is only introduced when additional memory (either adding complexity to the parser or in runtime use) is the consequence of absolute compatibility. They all seem like a reasonable trade-off.

> Not to mention that the baseline for those lists is CPython 3.4 - MicroPython is also missing most of the new features of CPython 3.5 - 3.9.

The baseline was 3.4 during development but more modern features have continued to be added, particularly if they can be shown to be implemented with low memory use. For example there is solid asyncio support (based on 3.8 [0]), the assignment operator has been implemented and, care has been taken to ignore type annotations correctly. fstring support is _almost_ there too (it ought to make it in to the next release).

The development team listens to requests for new language features so please raise a ticket (or comment on an existing one [1], [2]) to help prioritise upcoming features.

[0] https://github.com/peterhinch/micropython-async/blob/master/...

[1] Python 3.5 support: https://github.com/micropython/micropython/issues/1329

[2] Python 3.6 support: https://github.com/micropython/micropython/issues/2415

That's roughly true: 32KB RAM and 256KB Flash will provide a decent MicroPython environment. I'm afraid if you have fewer resources than that you should probably look at other alternatives.

#5026 was merged last year; it provides the sys.settrace primitive which paves the way for debugging support.

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

Still quite a lot of work left for pdb-like features but I'm optimistic it'll get there!

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

Resource usage is carefully considered when introducing new features; but there are cases where it has becomes smaller. The recent addition of LittleFS meant that a couple of KB more RAM was available at boot for example.

> one uses a FFT and the other an interrupt running at 170 kHz

Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.

No, an effective MicroPython environment requires 32KB RAM and a couple of hundred KB of flash (it's possible to use less but the compromises are not worth it IMO).

So yes, it's not possible to use very small devices. Still, this means that MicroPython can run on reasonably small, reasonably cheap devices - and your development effort can be significantly reduced.

Although much smaller in scope than NumPy, MicroPython (and CircuitPython) now have the ulab library which provides similar fast array manipulations:

https://github.com/v923z/micropython-ulab

Yes, and this has recently attracted some focus. Take a look at the example for embedding MicroPython:

https://github.com/micropython/micropython/tree/master/examp...

Generally the tactic is to write everything in MicroPython and, only if performance requires it, drop into C to write small sections.

It's still significantly faster than developing wholly in C - or Rust for that matter. And that's if writing in a low level language is required at all.

Already available on some devices. Notably the ESP32 and ESP8266.

The language is surprisingly complete; bigger differences are found in library support, even standard library support. Libraries that are memory efficient are easy to port but many Python libraries assume vast amounts of memory so it can require significant effort to modify them to use few resources.

Python 3.4 is actually the baseline for MicroPython these days. Many other more modern features have crept in; such as f-string support that was recently added. And the asyncio support is a modern implementation too...

Generally MicroPython can absorb modern Python features where the implementation can be shown to be efficient, particularly with low RAM costs.

Everyone is open to their opinion; in the meantime the company I work for uses it for mass market devices in the medical domain. ;)

The ESP32 port still has a few rough edges, particularly around peripheral control. But it's a popular device and the port is improving all the time.

It does; in fact with my Maix Cube it came shipped with it pre-loaded.