MicroPythonOS – An Android-like OS for microcontrollers(micropythonos.com) |
MicroPythonOS – An Android-like OS for microcontrollers(micropythonos.com) |
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.
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.
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...
Typo I'm guessing, but I found this unit of "energy acceleration" amusing.
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.
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.
Name: GoGoGadgetInternet
Password: InspectorThe 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.
And to be honest, I think you too understand this, deep down
Also, if you hate the REPL app, bug me to fix it.
(in general actively using a heap in a constrained environment is just asking for trouble... fragmentation _will_ get you!)
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.
The UK/European countries have GPDR for example.
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.
You might want to look at upyOS all it needs is micropython running. https://github.com/rbenrax/upyOS
I've added this to my "try someday list"
please make it in SDL3
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.
"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?
Anything that brings MCU tooling into the 21st century is very much welcomed.
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.
I agree though, probably shouldn't be the first choice for a professional application.
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.
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.
I've used MicroPython for prototyping. It's quite nice with its REPL.
However, for more than a simple proof of concept I wouldn't use MicroPython at all, on any platform.
My personal gatekeepey opinion is that if you want to learn embedded, you really should go for C. (C++ or Rust also exist, but C should be the first)
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.
Thankfully, because I used to get postal scams for the hundred or so domains I used to host.
You good for tinfoil bro?
In my language we say it colloquially that way, turned out wrong in English. Should have been 5 Wh.
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.