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: InspectorAnd to be honest, I think you too understand this, deep down
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.
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.
I agree though, probably shouldn't be the first choice for a professional application.
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.
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.
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.
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.
Typo I'm guessing, but I found this unit of "energy acceleration" amusing.
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.
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...
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.
Also, if you hate the REPL app, bug me to fix it.
"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?
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.
Thankfully, because I used to get postal scams for the hundred or so domains I used to host.
You good for tinfoil bro?
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"
(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.
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.
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)
please make it in SDL3
kej•3mo ago
lodovic•3mo ago
askvictor•3mo ago