Just had an argument with someone who thinks (micro)python is the way to go for embedded projects. Cause a lot of engineers are terrible at using C/C++. And their argumets for optimisation and granular controll over what the processor does is not necessary.
Its utterly wrong to push technologies into areas for which they werent originally designed for. We've seen it alot with websites lately and I dont like that embedded is heading the same way!

Comfort always trumps all the rest in the end. What matters is not 'best' but 'good enough'.
other examples:
- full multi purpose theme Wordpress installs for single placeholder static page that could be done in half an hour with megabytes of disk space, data and loading time saved,
-I love good coffee yet drink Senseo at home cuz it's just so fast and cheap

I mean it could be interesting but we would need a ton of drivers and wrappers just to make it work in Python, which ironically would be made in C, C++ and maybe Rust, then compile it back to fit in a MCU limited flash space. Obviously we cannot have the full interpreter in there lol.

Maybe one day we will have optimised and compiled python for embedded and a debugger than can reinterpret it back in python. Still, you would need knowledge of C, C++ and assembly to debug.

Personally for now I prefer to keep Python for mini-PCs with configurable hardware, like RPi.

Seems like uPython could be a good tool in the future though if it ends up being good.

I bet these people don't even have any idea on what e.g. dynamic memory allocation will lead to on small controllers without MMU.

That's on top of needing a larger controller than necessary, which is a no-go both in terms of cost and often also in terms of energy consumption.

I'm getting tilted by reading this...

@webketje
There is no excuse for bad coffee.
Get a cheap iron Moka pot and a cheap (preferably inductive) "hot" plate and you can have fast and good coffee made at exactly the right temperature.

He’s cancer.
Stick him with some chemo, stat!

C makes it hard to build modular and easy to maintain code. For products which have those requirements over runtime efficiency, MicroPython could be a viable option (especially when it's compiled, not interpreted).

@Scade C doesn't make that hard. You can even have object oriented idioms in C if you want that. It's just that it isn't as convenient because you have to manage stuff manually, which is exactly what you want on microcontrollers.

@Fast-Nop I don't want to work around the limitations of C and it's preprocessor and I don't want to manually manage architecture and high-level code. I want convenience to work efficiently. That doesn't mean not to low-level control the hardware when it's beneficial.
But I think that can be achieved with a version of Python adapted for MCUs. There have always been good solutions like inline assembly in C or calling C libraries from Python. I don't think it's ready yet, but we shouldn't stop looking for improvements because of tradition.

@Scade OOP-C isn't working around C. Function pointers have always been a part of C. Actually, that was how "C with classes" was implemented initially.

Also, common controllers don't have much program space to begin with, like some 64k, or sometimes even 1MB. You don't need high level code if your programs can't grow large anyway.

On the other hand, not being fine with manual memory management isn't a reason to waste money on using larger controllers in products, which would not only cost more, but also use more energy.

@Scade You sound like you’ve only ever used high level languages.

C is “traditional” because C is the right tool for the job, not because people haven’t seen the light of Python yet.

“Limitations of C” 🙄
Limitations of your understanding, more like.

@Root I basically only program in C. I quite like the language and I also think it's the best choise for microcontrollers yet. There are also important aspects that cannot be tackled with Pythons and alike yet. But this doesn't mean that C is the end of the line and there won't be anything more suitable ever. As I said, standard Python it is not.
In the product we make, low level stuff is important but only makes a fraction of the whole application. The high-level stuff would be easier to manage with features of high-level languages. Maybe C++ would be sufficient. But that's not going to happen for us, I guess.

@Fast-Nop Why should I have any problem with function pointers or manual memory management?
Like I said, there is no suitable alternative yet.

And 2MB of Flash is pretty common, just like external RAM.
It really depends on the application what is suitable.
Our customers won't mind a few bucks more on the product because we use a bigger flash, but they would mind waiting for a feature or product/protoype.
And for us it is cheaper to use a bigger flash than to manage customer-specific firmware variants.

@Scade C++ would be a better choice than Python. No messy automatic garbage collection, for one. Over allocation is still easier than straight C, so you would need to be cautious. I get your point about higher level languages being more convenient/maintainable for handling higher level logic, though, but on a microcontroller? That seems paradoxical anyway.

@Root We're on the edge between full Cortex-A with Linux and a Cortex-M. For our application, cost is still lower with a "big" MCU than a Cortex-A with a small MCU as a helper.
So yes, we're in a special (one could say paradoxical) position. On one hand we have a one hardware fits all mentality, because units per customer is low, on the other the way the device is used differs significantly per customer. Time to market is important for the customer, but managing different firmware for each customer is not feasible (there are to many customers and many of them are short-lived).
And there a more high-level approach could be helpful. Like I said, for me it's about modularity and maintainability, not runtime efficiency (we have enough hardware ressources).
I'm pretty sure things will change in the future based on our experiences and the evolving market (Linux? C++?). Time is the limiting factor.

@Scade You can actually have both - use a big dev board for rapid prototyping, or a PC mockup.

It doesn't even have to be the same language because prototypes are meant to be discarded anyway. As added bonus, you'll have a solid defence against the inevitable PM demand to just put the prototype code into production ("protoduction").

I once had a project where I developed the algo part in Matlab on a PC, and only when I had that right, I even started to port it to DSP assembly on the target platform.

@Fast-Nop That would be a great and we make use of it as often as possible.
Our 'base' products have a lifetime for about 7-10 years and the market is changing. So a lot gets changed during the products lifetime and in-field.
For our custom products, unfortunately we can't send devkits to customers for evaluation.
I use your method often to make 'simulations' of the final hardware/firmware for our back-end team.