It really depends on your needs. Overkill microcontrollers aren't that expensive anymore. It's probably faster to prototype something with micropython than C. And I say that as a very proficient C developer.
On the other hand, C isn't hard to learn, since the language is so small. What's harder is to learn its pitfalls and the parts that are actually implementation-specific, and not specified.
I'd argue that learning some assembly (enough for a few toy projects) is more useful to understand the system. C is required if you want to make the most out of the hardware, at least for now.
> Overkill microcontrollers aren't that expensive anymore
I knew that this would be mentioned but I didn't want to write an extensive comment.
In many embedded markets, cents make the difference. Also, space constraints, power consumption, availability, etc., makes you reconsider overkillability/price relationship.
Someone will put a 16KB MSP430 in the BOM and there you go.
What I wouldn't buy is something like "hey, chips are cheaper, let use a prototyped javascript-system over a VM over an RTOS, just because".
> What's harder is to learn its pitfalls and the parts that are actually implementation-specific
Yes. There are tradeoffs, like in everything in embedded.
> It's probably faster to prototype something with micropython than C.
Personally I wouldn't know where to start with micropython.
> I knew that this would be mentioned but I didn't want to write an extensive comment.
Oh, me neither, and I wasn't really talking of big production runs. If you have tight margins, you better take anything you can, and C is probably one of the first tools at your disposal.
> What I wouldn't buy is something like "hey, chips are cheaper, let use a prototyped javascript-system over a VM over an RTOS, just because".
You'd be surprised. The Harmony remotes comes to mind as an (old) example. In environments such as startups, time to market sometimes trumps even common sense. And people (including you and me) just prefer the tools they know most.
> Personally I wouldn't know where to start with micropython.
Funnily, I have never used it (except for a bit on a numworks calculator), but I can't imagine it being difficult once it's up and running on your microcontroller of choice. You probably flash and run as usual, except it's python code and has a repl.
I found micropython to be quite valuable in board bring-up stage. It is nice to be able to interactively test peripherals in repl, and these interactive sessions can be solidified in C code. This article about prototyping esp32 in micropython is great example: https://nick.zoic.org/art/lilygo-ttgo-t-watch-2020/
Yeah gdb is amazing tool. The micropython is few extra steps as you have to build the firmware for your target, and occasionally switch between proper FW and micropython FW. It still makes sense as you can do many things impossible in gdb.
You can define structs, loops and functions on the fly and execute them. You can build a complete driver in interactive session, first by poking around in registers and seeing that the HW reacts per spec, and then assembling correct operations into initialization function and updating function. All of this is throwaway code but it can save large amount of time.
Maybe non-critical systems could be left with the micropython implementation, but so far I haven't learned how to profile and optimize it to satisfaction.
Not on many microcontrollers, where you have no room for the debugging uart ports. I never had the luxury of gdb on my baremetal firmwares, only via selfwritten simulators or emulators. not qemu, qemu supports nothing. renode or unicorn are pretty good.
I'm not talking about running GDB ON the microcontroller (that's unlikely to be possible in most cases), but instead using OpenOCD (or JLinkGDBServer, or equivalent) to debug the running image via JTAG/SWD using GDB.
One could say that because you don't want to look at micropython now everybody else has to learn C.
You earlier made an appeal to authority that people should just learn C/low-level language, and then admitted you have no clue how you'd get started with micropython. What makes your appeal to authority... authoritative, then?
Not saying your conclusion is wrong, but here's some unsolicited advice, if you may take it: maybe you could explore the approaches you dismiss before professing that they shall be dismissed.
The above was a joke. And where did I say “I don’t want to look at micropython”?
I do know that if I want to learn it, it isn’t something out of my reach. But there are things you can do with C you can’t do with micropython, so other than from academic standpoint, what’s the point? I am already proeficient with C.
That said, I don’t care what other people do. I had good intentions with my advice, talking from 20 years of experience in the field.
My first computer was a Timex 2068, and I learned C long time ago, enough to be dangerous and knowing only to touch it when there is no other modern option available.
Most of the stuff people do in the Makers community is more than doable with Micro/CircuitPython + a bit of Assembly.
On the other hand, C isn't hard to learn, since the language is so small. What's harder is to learn its pitfalls and the parts that are actually implementation-specific, and not specified.
I'd argue that learning some assembly (enough for a few toy projects) is more useful to understand the system. C is required if you want to make the most out of the hardware, at least for now.