I work on the micros that aren’t plugged I to a grid. So solar and batteries and the like. In that world, power consumption is everything. Interrupts and aggressive sleeping of your processor are you biggest tool.
Does anyone have any experience with current draw of typical pieces of “firmware” using this? I see that it’s on the larger side of what feels like micro, BUT tomorrows micro has been growing heaps over yesterdays micros for a long time, so I can ignore that.
Compared to other microcontrollers: ESP32 is very power hungry. Shiny displays are very power hungry, Wi-Fi is power hungry. So expect to draw about 5 watts/hour continuously while in operation with all bells and whistles.
With this said (I'm also using them for off-grid) you will need to put them to sleep and only use the display when absolutely needed for most scenarios. I've recently started using devices with e-paper display which at least solve that nuisance of the display power draw: https://www.waveshare.com/wiki/ESP32-S3-ePaper-1.54
The last thing to keep in mind is heating. They will warm quite a bit and you should consider a way to either keep them cooled or make them sleep enough to cooldown, otherwise they will reboot or stop working until they are cooled again.
> If someone is interested in draw over a period, e.g. over one hour, you'd say it used 5Wh in that period.
Wh per hr? Let's just cut through the confusion and say it draws (J/s)Hr / Hr. :P
More seriously, if you are interested in energy the "correct" SI unit is J although in electrical applications [k/Mega/Giga]Whr is common. If you are interested in energy draw over a period, aka power, the "correct" and common unit is W. While 5 Wh per hour might seem simpler, it is equivalent to say this thing draws as much energy per hour as a device that that draws 5W would draw over one hour - needlessly redundant.
In the offgrid world we look constantly at batteries and they often express themselves in Wh. So it is a habit to measure anything else that way to avoid confusions.
I have a charger "controller" that I developed in MicroPython for an SAMD51 board. It can do sleep just fine, as long as you set up interrupts properly.
But I just need to do a bunch of ADC readings and some simple if/else conditions, so it doesn't require any real non-trivial computations.
Serious recommendation: I would not have R. Kelly anywhere on your project page.
If you’re trying to give a 30 second elevator pitch about what your project does, you should not have a name be a guy spending 30+ years in prison for child sexual abuse.
Where do you draw the boundary? Can I no longer enjoy watching space jam because it contains songs by R Kelley? A WiFi SSID which is a pun from a popular song seems pretty far removed from promoting or celebrating R Kelley.
You can enjoy whatever you want! Your parent comment provided PR advice, not a moral judgement on anyone who enjoys any piece of art made by unsavory people.
And to be honest, I think you too understand this, deep down
I had a problem with the ESP32 implementation specifically. The micropython implementation itself runs as a task under ESP-IDF, rather than bare metal, which is the case on some other microcontrollers like rp2350. So it doesn’t have access to the full resources of the board - as a good chunk is reserved for IDF.
I had a project where I had would make repeated API calls, which returned small to moderate json payloads.
To avoid running out of heap, I had to constantly force python garbage collection. That took a long time, so I wasn’t able to call the APIs on the intervals I needed.
Eventually I gave up and moved to using ESP IDF directly, which IMO was super easy to do - Espressif has made a great integration with VS Code. If anyone’s on ESP32, i would skip micropython.
I don't think that deserves to be categorized as a "reliability" problem. I don't think that's technically a reliability problem.
Sounds like it was reliable, with the problem being that it's much much slower than bare metal (a very well known thing), with the microcontroller not having the required processing power to service your task in that context.
Dropping into C for performance critical code is something you sometimes need to do with python, regardless of platform, because it's slowwwwww anywhere it runs. You'll always hit a ceiling, and much much sooner on a microcontroller.
It seems less like a full OS and more like a great dashboard/toolkit built on MicroPython. Perfect for getting an attractive GUI up quickly on powerful MCUs like the ESP32-S3.
This has nothing to do with GDPR, but nice try. By default you need to provide your details for domain registration, to hide these details is optional.
Nothing wrong with that, but coupled with hiding yourself on open source project as well and coupled with host which proudly advertises:
In a way, MicroPython already is an OS, in that it provides a bunch of services (filesystem, network, scheduling). It's up to you whether you want to access those through a script or a command line (repl)
We aren't in the 1980's any longer, most of these systems are way more powerful than a typical 16 bit home computer, and incrediblly as it sounds, those 16 bit home computers still had better tooling than most MCUs have nowadays.
Anything that brings MCU tooling into the 21st century is very much welcomed.
I haven't yet shook the feeling I got when I first realised my thermostat has more processing power than the computer I had as a child.
But also the devices this OS is aimed at will often be doing more than those computers were ever capable of, such as driving a full-colour display with touch interface while running a web server and wireless networking stack.
Agreed. It is really nice to have an OS like this. It will get a lot more people involved in the development. I would even think of scaling this up to more powerful processors and perhaps have it even on smartphones.
The advantage of micropython is that you don't have to deal with all the poorly maintained toolchains and UART and flashing and whatnot; for a novice working on their own, that stuff is a nearly insurmountable barrier. That the syntax is Python doesn't make a whole lot of difference.
I agree though, probably shouldn't be the first choice for a professional application.
It's actually a great first choice for a professional application, in that you can get a prototype up and running much faster than a native SDK, iterate quickly, and try things out on a repl. In fact, it's used in industrial settings, including in medical devices and energy distribution.
MicroPython's a bytecode interpreter so, other than the existing Python ecosystem being a huge boon (popularity being a form of strength), you could get many of the same benefits and more from wasm
You can actually opt-in to native compilation on a function level so it's not just a bytecode interpreter. You can also compile it yourself with additional functionality written in C/C++ and just use Python for the glue that isn't performance sensitive.
Look, I'm with you on those critics and my opinion about python in general is just "duh" but this project looks good, it is easy to write/deploy and looks well documented (need to test it out).
For apps that are simple, might be OK. I've done a similar operating system which would run C-like scripts (using Wrench) instead of python and came with a command line if you wanted to shell directly into the device but nobody cared: https://github.com/radio3-network/B3OS
At least they've done a far better job in presenting a capable operating system and bringing people to move it further.
I work on the micros that aren’t plugged I to a grid. So solar and batteries and the like. In that world, power consumption is everything. Interrupts and aggressive sleeping of your processor are you biggest tool.
Does anyone have any experience with current draw of typical pieces of “firmware” using this? I see that it’s on the larger side of what feels like micro, BUT tomorrows micro has been growing heaps over yesterdays micros for a long time, so I can ignore that.
Compared to other microcontrollers: ESP32 is very power hungry. Shiny displays are very power hungry, Wi-Fi is power hungry. So expect to draw about 5 watts/hour continuously while in operation with all bells and whistles.
With this said (I'm also using them for off-grid) you will need to put them to sleep and only use the display when absolutely needed for most scenarios. I've recently started using devices with e-paper display which at least solve that nuisance of the display power draw: https://www.waveshare.com/wiki/ESP32-S3-ePaper-1.54
The last thing to keep in mind is heating. They will warm quite a bit and you should consider a way to either keep them cooled or make them sleep enough to cooldown, otherwise they will reboot or stop working until they are cooled again.
Depends... do you need wifi, screen and others always on? can you wake some on a timer? on user interaction? on interrupts?
https://lastminuteengineers.com/esp32-sleep-modes-power-cons...
You can use those sleep modes in micropython as well
https://randomnerdtutorials.com/micropython-esp32-deep-sleep...
> 5 watts/hour
Typo I'm guessing, but I found this unit of "energy acceleration" amusing.
"Gotta go fast" :-)
In my language we say it colloquially that way, turned out wrong in English. Should have been 5 Wh.
Rather you would say it draws 5 watts. If someone is interested in draw over a period, e.g. over one hour, you'd say it used 5Wh in that period.
> If someone is interested in draw over a period, e.g. over one hour, you'd say it used 5Wh in that period.
Wh per hr? Let's just cut through the confusion and say it draws (J/s)Hr / Hr. :P
More seriously, if you are interested in energy the "correct" SI unit is J although in electrical applications [k/Mega/Giga]Whr is common. If you are interested in energy draw over a period, aka power, the "correct" and common unit is W. While 5 Wh per hour might seem simpler, it is equivalent to say this thing draws as much energy per hour as a device that that draws 5W would draw over one hour - needlessly redundant.
In the offgrid world we look constantly at batteries and they often express themselves in Wh. So it is a habit to measure anything else that way to avoid confusions.
I haven't used MicropythonOS per se, but Micropython is pretty efficient, and can utilise interrupts and sleep modes
I have a charger "controller" that I developed in MicroPython for an SAMD51 board. It can do sleep just fine, as long as you set up interrupts properly.
But I just need to do a bunch of ADC readings and some simple if/else conditions, so it doesn't require any real non-trivial computations.
Serious recommendation: I would not have R. Kelly anywhere on your project page.
If you’re trying to give a 30 second elevator pitch about what your project does, you should not have a name be a guy spending 30+ years in prison for child sexual abuse.
Ooooops, I didn't notice it on a first quick look. Yeah, I'm with you.
Agree. There are other puns possible for wifi:
“PrettyFlyForAWiFi”
all work and no play makes jack a dull boy. having a little fun spurs good work and vice versa.
Your definition of fun is scary
andor you are a coward. then again it's a scary time to be alive
Hey! Take it easy with me!
Where do you draw the boundary? Can I no longer enjoy watching space jam because it contains songs by R Kelley? A WiFi SSID which is a pun from a popular song seems pretty far removed from promoting or celebrating R Kelley.
I knew this comment was coming on HN.
The answer, as the other commenter suggested, is that I’m providing feedback for technical communication.
If your documentation or marketing materials are making me focus on unreadable font choices or poor color schemes, it’s not doing it’s job.
Similarly, if your marketing materials are making me think about a convicted sex offender instead of your project, they’re not doing their job.
[dead]
You can enjoy whatever you want! Your parent comment provided PR advice, not a moral judgement on anyone who enjoys any piece of art made by unsavory people.
And to be honest, I think you too understand this, deep down
As an alternative: MicroHydra [0]
Also, if you hate the REPL app, bug me to fix it.
[0] https://github.com/echo-lalia/MicroHydra
Given my experience with micropython's reliability... no thanks.
(in general actively using a heap in a constrained environment is just asking for trouble... fragmentation _will_ get you!)
I've never had a problem, but I use it for microcontroller type things. Do you have any GitHub issues related to this?
I had a problem with the ESP32 implementation specifically. The micropython implementation itself runs as a task under ESP-IDF, rather than bare metal, which is the case on some other microcontrollers like rp2350. So it doesn’t have access to the full resources of the board - as a good chunk is reserved for IDF.
I had a project where I had would make repeated API calls, which returned small to moderate json payloads.
To avoid running out of heap, I had to constantly force python garbage collection. That took a long time, so I wasn’t able to call the APIs on the intervals I needed.
Eventually I gave up and moved to using ESP IDF directly, which IMO was super easy to do - Espressif has made a great integration with VS Code. If anyone’s on ESP32, i would skip micropython.
I don't think that deserves to be categorized as a "reliability" problem. I don't think that's technically a reliability problem.
Sounds like it was reliable, with the problem being that it's much much slower than bare metal (a very well known thing), with the microcontroller not having the required processing power to service your task in that context.
Dropping into C for performance critical code is something you sometimes need to do with python, regardless of platform, because it's slowwwwww anywhere it runs. You'll always hit a ceiling, and much much sooner on a microcontroller.
…for very large definitions of microcontroller
Right? If it needs >1MB flash lol no.
This device no have a power. Your system can run solar panel and battery?
MicroPythonOS looks like a fascinating concept.
It seems less like a full OS and more like a great dashboard/toolkit built on MicroPython. Perfect for getting an attractive GUI up quickly on powerful MCUs like the ESP32-S3.
It could be a great prototyping environment
Does it run on M5Stack Tab5 or the CARDPUTER? Did anyone try?
nice gui
please make it in SDL3
Hidden project members, masked domain info and offshore hosting designed to avoid dcma. No thanks.
In countries other than the USA there are strict controls on personal information.
The UK/European countries have GPDR for example.
This has nothing to do with GDPR, but nice try. By default you need to provide your details for domain registration, to hide these details is optional.
Nothing wrong with that, but coupled with hiding yourself on open source project as well and coupled with host which proudly advertises:
Dedicated Servers & VPS with DMCA Ignored Hosting
No, thanks. Probably Russkis but still.
Having the support chat on Telegram is really sketchy. No thanks.
Actually the entire whois database is "privacy protected" because of GPDR (if my memory is correct)
Thankfully, because I used to get postal scams for the hundred or so domains I used to host.
You good for tinfoil bro?
I am not your bro, and no you are not correct.
But how do you know it's offshore to them?
In this scenario offshore means out of western jurisdiction. This is something hosting provider advertises.
To most of the world the United States is offshore. Recent developments have also made the US unreliable as a hosting provider.
I wish someone would make a wasm version of this. Should be doable and support many more languages.
A great playground for learning embedded systems, even if not ideal for every production use case.
The R Kelly references show a total lack of social/societal awareness. remove asap
[dead]
The name makes it seem like it's related to the MicroPython project, rather than just written in it, which feels slightly misleading to me.
In a way, MicroPython already is an OS, in that it provides a bunch of services (filesystem, network, scheduling). It's up to you whether you want to access those through a script or a command line (repl)
It looks really nice, but agreeing on the naming - it's not really an actual OS, more like a dashboard toolkit, or a set of widgets.
[dead]
Those tech bros should just...stop.
SBC is already cheap enough that you can throwaway without caring anything. Stop bloating MCU with....useless stuff.
If anyone suggest me "Python in mcu" professionally, i would never be able to trust them again.
We aren't in the 1980's any longer, most of these systems are way more powerful than a typical 16 bit home computer, and incrediblly as it sounds, those 16 bit home computers still had better tooling than most MCUs have nowadays.
Anything that brings MCU tooling into the 21st century is very much welcomed.
I haven't yet shook the feeling I got when I first realised my thermostat has more processing power than the computer I had as a child.
But also the devices this OS is aimed at will often be doing more than those computers were ever capable of, such as driving a full-colour display with touch interface while running a web server and wireless networking stack.
Agreed. It is really nice to have an OS like this. It will get a lot more people involved in the development. I would even think of scaling this up to more powerful processors and perhaps have it even on smartphones.
The advantage of micropython is that you don't have to deal with all the poorly maintained toolchains and UART and flashing and whatnot; for a novice working on their own, that stuff is a nearly insurmountable barrier. That the syntax is Python doesn't make a whole lot of difference.
I agree though, probably shouldn't be the first choice for a professional application.
It's actually a great first choice for a professional application, in that you can get a prototype up and running much faster than a native SDK, iterate quickly, and try things out on a repl. In fact, it's used in industrial settings, including in medical devices and energy distribution.
MicroPython's a bytecode interpreter so, other than the existing Python ecosystem being a huge boon (popularity being a form of strength), you could get many of the same benefits and more from wasm
If we forget about the pain that most WASM toolchains happen to be.
MicroPython, like most BASIC interpreters in 8 bit days, also allows for inline Assembly.
As for running bytecode on MCU that is as old as MCU themselves, wasm doesn't bring anything to table.
https://en.wikipedia.org/wiki/BASIC_Stamp
You can actually opt-in to native compilation on a function level so it's not just a bytecode interpreter. You can also compile it yourself with additional functionality written in C/C++ and just use Python for the glue that isn't performance sensitive.
Look, I'm with you on those critics and my opinion about python in general is just "duh" but this project looks good, it is easy to write/deploy and looks well documented (need to test it out).
For apps that are simple, might be OK. I've done a similar operating system which would run C-like scripts (using Wrench) instead of python and came with a command line if you wanted to shell directly into the device but nobody cared: https://github.com/radio3-network/B3OS
At least they've done a far better job in presenting a capable operating system and bringing people to move it further.
This software stack targets a $17 ESP-S3 board that comes with an integrated touch screen, 8 MB of PSRAM and 16 MB of flash.
https://www.waveshare.com/esp32-s3-touch-lcd-2.htm
"Android-like" term is pejorative these days. What do you mean? Closed app store with throwing out old software because so?
If only you'd bothered to quote the rest of the sentence:
"Android-like touch screen UI with gestures"
Could have used also "IPad-like..." or "IPhone-like..." and it would have meant basically the same. Maybe author is more familiar with Android?
PS: What's with all the outrage manufacturing?