matt_trentini
Joined 16 years ago
Karma
186
Submissions
110
Member since
Aug 15
Recent submissions
Comment · 6 months ago
Oddly, the article didn't mention it - but the watch does have wifi.
Comment · 7 months ago
Waiting for my ManT1S:
Comment · 9 months ago
Where are you getting 20MHz from? The OG ESP32 is a dual-core 240MHz micro...
Comment · 9 months ago
Always double-check an LLM, particularly when it's just a quick(er) search away:
https://docs.micropython.org/en/latest/genrst/index.html
Specifically: JSON is built-in, logging is available. There's no multiprocessing (it is designed for a micro, after-all - and note that thread is available on some ports), no built-in XML lib.
Be sure to check micropython-lib, the MicroPython Awesome List and mim for others.
https://github.com/micropython/micropython-lib
Comment · 10 months ago
It's a good _start_; much more code needs to be written to allow control of the hardware of those devices (GPIO, I2C etc).
Comment · 11 months ago
Support for more micros, a whole swag of new features and bugfixes - and further improvements to automated testing.
Comment · 1 year ago
I can't reveal specific implementation details but I work for Planet Innovation:
Some of our products use MicroPython though we also use a whole host of other technologies. Some of our devices are proof-of-concept (often designed to progress a theory) but we also deliver up to Class B solutions.
Comment · 1 year ago
> Then why do they have 1300 issues open? There are 420 pull requests not merged...
Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs.
> They need to test the whole ecosystem...and for every bug fixed there should be a unit test...
Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area.
> I had this conversation with them but they take every opportunity to justify/ask for more funding.
Ah, I presume you're referring to this discussion?
https://github.com/orgs/micropython/discussions/13436
No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free.
BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help!
> They are also prioritizing adding support for new chips...
That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant.
> ...get eaten alive by chaos, regressions and platform fragmentation
I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV.
As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.
Comment · 1 year ago
Unit test coverage is exceptionally high for the interpreter, and always has been:
https://micropython.org/resources/code-coverage/
('py' folder: 99.2% line, 88.7% branch coverage)
Testing the port-specific code has been a much more challenging problem.
Which is why in the past year or two there's been a lot of energy put in to HIL testing. There are now a few dozen boards that are automatically tested with an increasingly rich suite of hardware tests. Both the number of boards and tests are increasing rapidly.
It's not perfect but it's getting pretty darn good. If you want to help out please do reach out.
Comment · 1 year ago
Carefully, at least for devices with higher classifications. Using pre/early allocation helps but, more importantly, we monitor memory use over time in realistic scenarios. We've built tooling, like a memory-profiler [1] that allows us to observe memory consumption and quantify performance over time.
However, it turns out that MicroPython has a simple and efficient GC - and once you eliminate code that gratuitously fragments memory it behaves quite predictably. We've tested devices running realistic scenarios for months without failure.
Comment · 1 year ago
Those are generous resources for MicroPython. And it'll be faster and less quirky to develop in than either Berry or Lua.
Comment · 1 year ago
Yes, we use MicroPython for medical device development up to class B.
Comment · 1 year ago
Speed: maybe, sometimes. Of course, MicroPython makes it very easy to create modules written in C, accessible from MicroPython. So if you need extra perf you can always write a smattering of C.
Reliability: I don't see why Toit would be any better? FWIW we make medical devices using MicroPython and have tests that have run for many months with no failures. MicroPython, the language, is extremely reliable and thoroughly tested [1], though admittedly the port-specific code can be less so.
We've evaluated Toit and it has some nice features (the containerization is novel and powerful!)...but it's a quirky language with sparse peripheral support. Ultimately it's trivial for Python-familiar developers to switch across to MicroPython - a big benefit. Being constrained to the ESP32 is a limitation that many of our customers would not allow.
[1] See the py folder: https://micropython.org/resources/code-coverage/
Comment · 1 year ago
It's obviously not directly comparable - each port will be different - but startup time is <50ms on an RP2040 (Cortex M0 @133MHz):