In theory, using MicroPython on the ESP32 is easy — just flash an image and connect using a serial port. But that leaves a lot of things you still have to do. You need to move files between the two platforms. You’ll want to manage network configurations. You might want better editing and assistance, too. So there are a number of IDEs made to help you and one we recently noticed was MPY-Jama.
The IDE provides source code editing, of course. But it also allows you to do things like pull information about the network using a dashboard or connect to a WiFi network easily. You can even create your own AP with a simple interface.
Although the front part of the README mentions it is for Windows or Mac, if you scroll down you’ll find instructions for installing under Linux. The IDE is extensible using “Jama Funcs” and can handle the flashing operation from inside the IDE.
Of course, there is an IDE from Arduino (but not the Arduino IDE) that handles MicroPython. You can also find a rundown of several similar alternatives online. If you need some inspiration for a MicroPython project, perhaps you’d like to play a game?
I’m sorry but Python is just wrong.
We have Circuit diagrams and layouts. They are related, but circuit diagrams prioritize, readability, understanding. While layout is about structure.
So too we have presentation and structure in software. Except, Python, with spaces as structure loses the plot.
Except we have C, with braces as structure losing the plot.
There are many reasons not to use Python on a microcontroller. Whitespace is not one of them.
If that’s your only argument against Python, then you really don’t know much about Python.
I find C and all C related languages ugly. Reading C is like reading sandpaper. It scratches my eyes and makes me want to go elsewhere.
Despite that, C is a more appropriate language for programming microcontrollers so that’s what I use on microcontrollers.
I like Python, but it is inappropriate for microcontrollers. I use it on PC programs where I have the resources it needs.
Well, you too didn’t present a good reason why Python is not for microcontrollers (besides “I like Python, but it is inappropriate for microcontrollers”).
Resources. Python is an interpreted language. As such, it makes poor use of the limited resources of a microcontroller.
Dynamic allocation. Python creates new objects at the drop of a hat, eating up memory.
Garbage collection. Python has to clean up objects that are no longer in use. That can take time out from the tasks your program is supposed to be carrying out.
Micropython claims to be a compiled language, so that takes care of the interpreted part.
Micropython says it can run on a microcontroller with 256k of code space and 16k of RAM. There’s lots of microcontrollers that don’t have that much code space or RAM that can do useful things when programmed in C but which you can’t use at all with Micropython.
C and Python both have their place. Deciding which to use because “whitespace” or “damned scratchy braces” is wrong. You decide based on what works best for what you are doing. Python mostly belongs on a larger machine.
Professionally engineered commercial products that are going to be mass produced benefit from shaving every penny off of every part. The smallest micro with efficient code is important.
Does a hobbyist really care if they are paying for a Pico which is overkill for the job or an 8-bit micro like an Arduino? Oh, wait, if they are buying the name brand boards, not the raw chips the Pico is cheaper anyway.
Learn Python and you can write desktop gui/cli apps, web backends, mobile apps and microcontroler stuff. For a person who wants to dabble in everything whose day job is something else that makes a LOT of sense.
Just wait for Javascript to take off in that market. All those things AND client side web app code too! A few years ago I would have disowned my own kid for chosing Javascript. (no not really but I didn’t like Javascript). But now… it does make sense.
MicroPython is not the Python on your PC. It makes poor use of some resources and very efficient use of others. There are 3 or 4 levels of optimization all the way to including assembly language in your Python. Besides, micro’s today are too darn fast!
I just don’t understand the hatred of white space indention when almost everyone uses white space indention anyway. Having to add curly braces to a block feels like a violation of DRY. Causes me to want to tear my hair out when I need to move a chunk of JavaScript and I don’t pay very close attention to where all the closing curlies are. Using VSCode.
You’ve mentioned important considerations that you need to be aware of when using MicroPython – but they’re all manageable. Just like memory management in C is dangerous but can be managed.
If you can use a micro with 32KB+ RAM – and these are becoming increasingly common and cheap – the development benefits are very compelling.
We use MicroPython in medical devices where the extra few cents for a bigger micro is inconsequential. But being able to save 30% in development effort and being able to respond much faster to our client’s requests cannot be ignored.
It depends! Context is king. C was always quite good for low level stuff, typical of embedded applications, but error-prone and cumbersome for handling complex “business logic” and high level stuff.
Times changed and now we have complex networked application stacks with messaging, encryption, HTTP and what not, all running in tiny “microcontrollers”. Python makes more sense in these scenarios the same way it makes more sense for building web applications than C does.
The examples you reffered to are all handled pretty well by libraries with clear, established APIs. What you will be maintaining is your code. Not the encryption, not the networking etc.
Meh. IMHOP C-related higher level languages aren’t ugly, they are about the most natural thing to read I’ve seen in code. Style matters. Opening paren on the same line is good, putting it down lower is just a waste of eye-scrolling. But that’s nothing compared to requiring left-right eye scrolling. That should always be avoided. Some people like their million-space indents. Yuck! To each their own but well.. exactly. To each their own. I wish people would switch to tabs. 1-tab character per level of indent, any other number and you obviously don’t get the concept. Then we can just each configure our own favorite code editor to display the number of spaces we like per tab character. See? To each their own. Beautiful!
Reading C itself… I don’t know. It’s usually just a bunch of struct definitions. The actual code that does stuff… Maybe it’s tucked away in a higher dimension somewhere or something. I mean, most of my college classes were C so I did used to write in it. But every open source program in C I have looked at.. all I see are structs, structs all the way down. What makes it actually do something? No idea.
Structs hold data. Functions operate on data. Simple, no layers of indirection, abstraction and bloat like other languages.
I thought I would HATE Python for it’s use of whitespace instead of parens. Then I tried it. It’s fine, like jumping in to a pool you expect to be really cold and it turns out to be comfortable. No big deal really.
Now Python’s lack of a switch statement? Ok, there’s match case now but why call it something different from EVERYONE else? And I don’t care what you say, no fallthrough sucks. There are times fallthrough is exactly what is needed and it is only hard to read if you don’t expect it because you insist on never using it.
And Python’s ternary operator? The condition comes in-between the possible outcomes! WTF?!?! It’s like there was a team where one person was writing the BNF and they really didn’t like the people working on the scanner/parser so they started messing with them. I imagine in the implementation every assignment operation must be wasting some cycles checking to see if there is an “if” following it. Yuck!!!
Ternary operators?
Nuke ’em from orbit. It’s the only way to be sure. Ugliest contruction ever in every language that has it.
Nuke the ternary? In Python maybe.
person = condition ? “Bob” : “Sue”;
vs
if (condition){
person = “Bob”;
} else {
person = “Sue”;
}
The first looks very readable to me.
The second is a whole lot of extra up/down eye travel, not bad but it’s crazy to prefer that over the first!
How about the compiler?
With the ternary it is obvious that the value of person is always set even before anything else is evaluated.
With the if statement the compiler has to evaluate all possibilities to see if there might be runtime situations where person is not set.
There was supposed to be indentation there but… html display..
The comment system seems to crash if I try to include html entities!
I think it was Linus that said it best. C, plain C, has the property that, If you look at the code, you could reasonable accurately predict the assembly.
It’sa a close approximation of a machine in dependant assembler.
Yes, you can reasonably accurately see what the program does. Not just as assembly, but what actually happens to the data.
I keep hearing that C is a close approximation of a machine – but that hasn’t really been true for decades:
https://queue.acm.org/detail.cfm?id=3212479
I’ve looked at plenty of machine code generated from C. It’s rarely a close mapping to what you expect, except in the most trivial of situations.
Well., this doesn’t reflect reality – the spaces/braces distinction isn’t as important as you make it out to be. In my experience, using spaces impacts code presentation and structure positively, so Python forcing you to do it is a win overall. Just an example off the top of my head – I can give a printout of Python code to a student, and things are crystal clear without having to point out non-spacing-obvious extra braces to them!
Stuff like ‘you can avoid braces in C for a block, but only for a single line’ is just atrocious, for instance – it creates lack of readability and a vector for mistakes where there ought to be none, by the way. Now that’s ‘just wrong’, verifiably.
Plus, you’ll see that other language devs end up using spaces to delineate blocks anyway, well, if they’re using anything above lowest-level languages ;-P Spaces have become an informal construct in code more-or-less everywhere appropriate, and you’ll find braces generally duplicating their function more than anything.
Circuit diagrams and layouts exist to fulfill different purposes. Circuit diagrams are functional representations that are easy read and comprehend, used for creating and validating a design. Circuit layouts are mapping of a diagram to physical constraints of a particular manufacturer but also the physical needs/constraints of the designer. EDA tools map between a physical layout and the virtual diagram.
With most software design you don’t have physical/manufacturing considerations. You have a compiler that, similar to an EDA tool, maps your code to assembly. High level languages are analogs to circuit diagrams, they are meant to aid the author and express a design in a legible way.
With circuit diagrams, there are rules you can adopt to make things consistent and more legible, the same is true in your selection of a high level language and conventions you or your team adopt.
Python’s use of white-space as a control structure is also dual propose because it forces convention upon. This addresses a failure of other languages that rely on braces and semicolons and allow you to write illegible code.
Python doesn’t lose the plot, if anything it keeps you from losing the plot. The purpose of a high level language is to make your design legible and easy to comprehend. With C type languages its incredibly easy to write very difficult to read code, and there has been tremendous effort in writing software to reformat and beautify illegible code.
Python is a design aid and, like any aid, you can opt not to use it. There’s nothing wrong with it and your inability to either acknowledge or comprehend why it exists only hinders yourself.
Sure. Next we’re going to hear there’s nothing wrong with not declaring variables.
If I were build a PCB I really need circuit diagram. Your not comparing Python using circuit diagram r u.
I’ve been programming professionally for >20y. I’ve never run across a code base that didn’t use whitespace for code structure, even if from the compiler’s perspective it wasn’t strictly necessary.
I had an Arduino and a couple of ESP8266s for a long time. Never really did anything with them. Something about the Arduino environment and C++ just wasn’t working for my brain. I could do it, but it was enough of a “I don’t want to” to keep me from starting a project.
And then I discovered that Micropython was a thing. Life changing. Playing with microcontrollers was fun again. Now I’ve got a bunch of ESP32s, and some ESP8266s, and several projects going. The workflow and the language just work for my brain.
It sounds like they don’t for you, and that’s fine, we’re all different. If the amount of info online for programming ESPs in C++ is any indication, it’s quite popular. Do what works best for you. Use whatever lowers the barrier to entry *for you* the most, so you can get to the fun bits. And most importantly, *do what you enjoy.* That’s what I’ll be doing :)
i agree that c cpp is better. but still python has one adwentage . as its interpreted language. its all system except main system code can be rewritten on the fly/flight ;) which is good for systems that needs dynamic code update or making it capable to use script downloaded from web or updating chosing code relative to env stored on say sdcard . as you cant reprogram c/cpp based program without pc. ie reprogramming rover on mars for new objectives ;) still its possible to write similar system from scratch but as python is allready there . its beneficial for some cases it seems.
Is there a debugger ?
No, not yet. That said, it’s getting close – sys.settrace has been in-place for some time and this is the heart of a pdb-like debugger.
See micropython-lib:499: https://github.com/micropython/micropython-lib/pull/499
(Though if you want to connect GDB and debug the underlying MicroPython code, then that’s been possible since day 1…)
Repl also exists for ESP8266:
https://github.com/lvidarte/esp8266/wiki/MicroPython:-REPL
Resources. An interpreted language is Python. As a result, it uses a microcontroller’s limited resources inefficiently.
dynamic distribution. Python constantly generates new objects, using up memory.
Garbage removal. Obsolete objects need to be cleaned up by Python. That can interfere with the work that your programme is intended to be doing.
Since Micropython asserts to be a compiled language, the issue of interpreted code is resolved.
According to Micropython, it can function on a microcontroller with 16k of RAM and 256k of code space. Numerous microcontrollers with little RAM or code space can do important tasks when programmed in C, but they are completely inoperable when used with Micropython.
MicroPython does not assert to be a compiled language; if you’ve seen that I’d like to correct it. MicroPython, like Python, is an interpreted language, compiled first to bytecode.
Managing memory use is a key consideration of MicroPython but it’s much more tractable than you might think.
And yet, the most common IDE, Thonny, wasn’t mentioned ….
Most common and, IMHO, most horrible IDE I e ever worked with. Honestly I’ll try anything but was very keen playing with the Pico hardware but the pain of micropython AND that IDE was a little too much. I’m grateful I found the ESP(8266|32) platform not long after.
I scrolled down to comment about Thonny! Before Thonny, I was just using vim and some manual scripts to program my boards over serial.
And then I found Thonny, which was fine — fine enough that I slowly started using it more and more. So fine, it’s where I now start projects. Which ultimately shows Thonny is quite good! Good enough to ease some pain points and get out of my way.
Also an article on CNX:
https://www.cnx-software.com/2023/02/07/esp32-mpy-jama-micropython-ide-for-esp32-boards/
microPython work very fine with … PlatformIO – tested with Raspberry PI Pico and GSM modules
BUT chip and module manufacturers don’t care about you at all…
https://twitter.com/TektonikaInfo/status/1584891518305046530
Love python on a big machine. Used it once on an MCU …. but never again :(
What gives? There were a bunch of comments discussing Python and C on microcontrollers here a little while ago and now they are all gone – except for the one completely dissing Python, which started it all.
“cleanup”
Let’s hope Al made a mistake and didn’t actually intend to do that…
I think you are thinking about the Python for loop post, not this one. We don’t typically police comments on our stories although we can, but we try to apply a light touch.
Well, mention a language and you get a long line of inane nonsensical bickering pointless comments.
Great.
This will go on until people stop pushing inefficient bloat-inducing garbage and return to real programming in C.
You mean assembly language? You said C you know, tisk tisk
(See, it’s not like it’s hard to bicker about languages, anybody can do it.)
i think using actual machine code compilers is better . but for now c/cpp is good way to talk to compiler . gcc is actually chatgpts grand parent … which is technically doing werynsimilar thing. by converting c code to machine language ;) effectively.
anyway it cant convert it back effectively as chat gpt does. ;)
The rubber hits the road when outputs needs to react to input states and the latency in that coded decision matters. If code adds delays in critical timing then for me it loses the battle of which tool is best. Different hammers.
Hello, there is the new version 1.2 which is much better and offers new possibilities!
–> https://github.com/jczic/ESP32-MPY-Jama/releases/tag/v1.2.0 😉
hi. after using arduino ide for arduino boards then esp32, finding it slow to compile (i did try all the tricks to speed it up.AV ect)
i startid to try the other ide’s,thonnys(esp32 python)fast to upload but slow program loop,(interpreter)? .any way to speed it up ?. mainly for LCD projectsILI9341 projects. thanks for all the useful comments to come.
I use micro Python (all at home for the moment but that could change) for one main reason – co pile time. I can load the code to the micro and it is ready to go. C it has to compile and then load. I shave 20-30 seconds off every go round when I use micro Python