Oddly, the article didn't mention it - but the watch does have wifi.
186 karma · joined August 15, 2010
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
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.
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.
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.
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.
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/
https://docs.micropython.org/en/latest/library/re.html
so alternatives to provide additional features have been discussed... Either extending the existing module or swapping to a more feature-rich library. Possibly even doing so for larger micros that can afford the additional flash/memory, though that makes support more challenging.
The challenge is that MicroPython has many fewer standard libraries:
https://github.com/micropython/micropython/wiki/Standard-Lib...
And so many Python libraries targeting CPython won't work out-of-the box and you'll need to modify them or use alternatives that do work on the MicroPython subset.
The results from LLMs are still too slow, vary too much in quality and still frequently hallucinate.
My typical use-case is that when I'm looking for an answer I make a search query, sometimes a few. Then scan through the list of results and open tabs for the most promising of them - often recognising trusted, or at least familiar, sites. I then scan through those tabs for the best results. It turns out I can scan rapidly - that whole process only takes a few seconds, maybe a minute for the more complex queries.
I've found LLMs are good when you have open-ended questions, when you're not really sure what you're looking for. They can help narrow the search space.
It was somewhat amusing that MicroPython isn't in MicroPythonia but Arduinoria...and CircuitPython is in PicoPythonia. :)
Prefix a query with '%' to search only within open tabs.
COVIDSafe was the last technical undertaking and it was expensive and a completely inept implementation. The MyGov website is another failed attempt at keeping personal data secure.
Further, it seems likely that social media companies are likely to come out of this with even more information about us.
Government and tech do not mix well (at least in Australia).
But to answer your questions directly, yes, I do use the REPL quite a lot to experiment and figure out how the system works.
I'm surprised that you had OOM errors, especially on an ESP32 where there's usually plenty of headroom. I haven't seen an OOM error - except when I've made a mistake - in years.
https://survey.stackoverflow.co/2023/#section-admired-and-de...
So a convenient workflow is to deploy at runtime (ie not in flash) until you stabilise your code base or approach production; at which point you can freeze your code into your firmware.
For an even more convenient model, there is the proposal to support 'mapfs' so that some flash will be allocated to store code. You can then compile your Python to bytecode (with `mpy_cross`) and upload it to - and run from - this area at runtime.
Although this feature has been demonstrated as a proof-of-concept, there are some subtleties to sort out before it hits mainline. If you're interested in the feature, please read or comment on the PR: