You're doing great, Andreas. I'm able to recommend your stuff to both experienced and beginners, and they all like it too. And no matter what, we all fall on some spectrum that's different depending on topic. For example, I had little clue how to get going with the ESP32, but you came along and made it super easy - "taking that hit for the team", for which, much thanks. Even for an "expert", it's nice to have someone go over the ground and find the pitfalls and tricks - which save even highly experienced (but in slightly different specialties) people lots and lots of time. The stuff in your mailbags saves me from having to buy all the same stuff and try it myself, for example - now I can go right to the answers. Please keep up the good work!

Kudos on the comments section here. There sure are a lot of really interesting people and points made. I think I'm learning almost as much here as in the video ;)

@Upcycle: I hope, here you learn more ;-)

I think I'm more impressed they put a python interpreter on a micro controller than actually being able to code python on a micro. I certainly wouldn't but the fact you can is pretty amazing. The efficiency would be terrible especially in battery operated devices!

Thank you to you Andreas. I am a non professional programmer, but my education was in programming. But thanks to maker and professional like you, I can have fun in the physical world. 20(?) years ago, I skipped the PIC programming (despite reading books about it and knowledge of assembly). 10(?) years ago I skipped the Arduino despite knowing C. 3 years I started with Pi, mostly in Python. Then thanks to Adafruit, I discovered Micro Python on the ESP8266 and that is where I started to see their move to making Circuit Python. Having the same language both on SBC and microprocessor is really great for me. Even if that language require space for indentation and n type declaration.

The argument is always: "yes but that way you support development of the Arduino" As if that still needs developing

Ed19601 Don’t get me wrong, I understand that they don’t work for free. And I gladly pay for good services. But a recent example: 64x64 p3 RGB led matrix. Raw chinese crap: 19 USD. Adafruit 75 USD. What can I say. Its the difference between a cool DIY project and No F****** way

@@atinotevuelveaimportar5905 oh I fully understand and ofcourse no one works for free but like you I know many examples of say established peripheral modules that require no development that are much much more expensive than at say a Chinese website and then I am not even counting the shipping cost. I'd happily buy a feather from them but not a UNO, or a neopixel ring or a DHTxx. If I had to buy everything at adafruit I wouldn't have this hobby

I occasionally buy stuff from adafruit to support their development. They've created libraries and tutorials that have really helped me out.

Adafruit releases board files which you can use to mass produce boards. And that will be even cheaper than the Chinese derivatives

hello! greetings from india, i write my comment only to appreciate your thoughts, on the metal making videos on bofors and many other things about my country ;-)

You are always welcome. Had to use Google translate for these highbrow words ,-)

Andreas Spiess - At least AvE wasn’t speaking in his native tongue. Google translate can’t help you with the lowbrow dialect. AvE is a lingual genius when he’s narrating his videos 👨‍🎓

I dunno AvE looking at the comparisons, when he said you cannot imput compands in arduino by pressing enter, yes you can just use the Parse instruction. Python doesn't jave curly brackets and loops. Well i think it's good to have a visual que oit there. The code is written directly on the microcontroller. Why would I want that?

As you said In one of your videos. Embrace the suck! Don't do something just because it's easyer. I mean, does it do the same thing? Maybe. Is it easyer? Well to someone completly oblivious of programing all of em are gonna be difficult. Why not go with something with more structure.

Ecosystem is also important.

True, I just included that factor in "the one you're most comfortable with" :)

I'm the same way with the RPi. I can't stand the entire framework to be honest, I don't want a little computer to try and act like a big one, and almost none of my projects require a display anything like a desktop monitor. I went the whole hog approach too, I have the Western Digital PiDrive, wireless and Bluetooth dongles, I just grew to loathe the whole concept.

@@dasworkshop4967 The Pi has its uses, it's when people confuse it with Arduino that the troubles begin :-) But I got disappointed with it too, when I saw how easily it can fail because of the SD card, and how non-trivial, non-standard it is to use a proper hard drive to boot (even with the most recent solutions)

You don't have to live in pain, you know?

You view it as file, does not make it file. This where abstraction starts :D

IDE's are your friend and not your enemy. Using print() isn't debugging. Having to type everything instead of auto-completion is a waste of productivity. Having a compiler warn you about dangerous mistakes before uploading/execution can prevent costly mistakes. A file structure is much easier than having a bunch of text files open. Maybe it looks like you are in control because you can see the files. In truth everything important is abstracted away from you and you don't have access to it or can see what is happening.

I started with BASIC on a Z80. Which was not really beefy. And I was able to write database applications which were astonishing for people at this time. I think this was possible because we had some "high-level libraries" which were coded in assembler. For me, this was a perfect fit at this time. Maybe we will see a similar thing here: The logic in Python and some optimized libraries?

That's exactly where I started too! But you have to consider the hardware available at that time; beefy compared to what? Home Computers like the ZX81 (and clones) were the only thing available to mere computer mortals like myself at that time, so a Z80 processor (and similar) was the beefiest thing you had access to, since it was about the only thing you had access to. Now I can pick an ATTiny85, an ESP32, a RasPi, ODroid, and what-not, and still have money left to buy food the rest of the month :-) and these platforms represent a wide spectrum of beefiness. So to me, beefy vs not-beefy is for example RasPi vs ATTiny85.

I was referring to your comment, that interpreters need "beefy" platforms.

Sorry for going on and on about this topic, Andreas, but I'm really excited about this :-) Going back to the ZX81 example (since it had a Z80 processor), it had 1KB of RAM where you would have your program stored, and 8KB of ROM for the interpreter. See en.wikipedia.org/wiki/ZX81: "The ZX81 has a base configuration of 1 KB of on-board memory [...] and an 8 KB ROM providing a simple BASIC interpreter." So having 8 times the space for the interpreter, compared to space for your actual program in the standard configuration, suggests to me that interpreters *relatively speaking* require some sort of beefiness. Hence my comment about beefiness.

​@@MartinBgelund​ , its also true that the more memory you want the more you pay for it. back then it was a higher price per kb then now. Heck, its still you get what you pay for. a higher-level interpreted language needs more mem so to use it will cost more to run it. it might even weigh more. nanograms then but he talking about space crafts every darn sliver counts. after all the person who developed micro-python works in the space industry.

Thank you for your comment to give understanding

Thank you for accompanying your opinion with an explanation

Have to agree I'd never heard of MicroPython and assumed it was just "python". Still, don't think it's enough benefit, from what you've said, to switch from C. I like having an IDE, and uploading over a USB connection to the embedded system. All mine have USB since it's just too useful for debug vs JTAG or something simpler. I'll pay for the extra chip.

But it has the same terrible whitespace-based syntax which makes it unusable.

I could debate that it has "nothing to do with Python ...". I program in many languages and micro and circuitpython are very similar to Python 3.7 or above whether run in Docker, on a Mac, in the cloud... In fact I have some code that I lifted right out of code written for a different use case in real CPython 3.x. But I do understand your point that there is a big different in how the micropython approaches with its mpy files versus regular CPython's pyc files. To be clear to readers, CPython is the name of the programming language Python's default implementation written in C (thus the C in the name). It is not an abbreviation for circuitpython. Although I said I "could" debate, since I get what you are trying to say about the original writing of MicroPython from scratch for microcontrollers. Circuitpython is a branch of MicroPython which favors educational features over performance or efficiency. What a great time to be alive! So many cool ways to write code and make new products

Absolutely agree that Arduino is the solution for high speed Realtime. I have a nano controlling diesel injector firing.

Really? Really I don't have to go to Python with leaving C and Microcontroller ATMEGA 328P?

The more python applications I see in real time application, the more I noticed the unacceptable slowness and and even lag. For some applications, I see some are using hybrid techniques mixing interpretive python and embedded 'C' code for performance. It reminds me of the evolution of MS Windows. Arduino seems coded tight and efficient. While Python, instead of making efficient, is loose and depends on faster and faster processors, and more memory. Just like Windows.

I'm with you, at least for most of my apps. You compile once, and I agree the uploads can be lengthy especially with the 8266s but it's one time instead of interpreting every line every time. And, as near as I can tell, still no interrupts in Circuit Python. He's right about the strings. I do some communications with other processors using strings, and that could be better.

Fast is a relative term. We’re talking nano second differences

I agree, Learning C++ is harder than Python, and when we've mastered C++, moving to Python is less effort.

relearning what "basic concepts" exactly?

And the clones are very cheap

@@piotrku_ not only processing intensive stuff, but also hardware close stuff, where it comes to define clearly the type of variables.

Let’s be honest: Python is very popular because it’s easy.

Thank you for your feedback. That was my intention and the reason for the question mark at the end.

I know I'm 5 years late but what did you do for the final project?

8051 Assembly !

I too,... am old. And MGTOW. AND WHITE. IN CANADA. WESTERN CANADA. SOOOO.... useless.

My wife gives me my opinions too,, even so she still says that I am wrong. (lol)

I had a huge, HUGE problem with learning too many languages and dialects and started to mix them up when coding. I started with Algol, COBOL, Basic, DBase and then it got worse with APL and Assembler languages. If you think C++ is cryptic then APL is total hieroglyphic. I think I was using 25-30 program languages a a programmer/analyst.

@@NeoMorphUK you change jobs a lot or something?

jimmytea1 nope... I worked in Systems Support and they had 3 people who could know as many languages as were in use across all the company. So if someone had problems with their systems (I’m talking mainframe, mini and a few early IBM PCs... I’m talking PCXT’s here) well then they came to us and we fixed it for them. So yeah, 3 people and we had to know languages for a National sized company... in the late 70’s. Then I got sacked because I had to keep getting up and walk or the pain in my joints drove me nuts... didn’t realise until years later it was because of Joint Hypermobility Syndrome (also known as Ehlers/Danlos Syndrome Hypermobility Type)... so I got sacked for being disabled. Then I joined a small software house... learned some more languages there... then fell down some stairs (again caused by the disability). After a leg op and recuperation I told them I was ready to come back... only to be told they had given my job away... even though they brought over a whole Vax network while I was at home recovering from a major leg operation... and the reason I fell down was because the bannister rail had come away from the wall. That Vax network FILLED my living room while I configured it. So yeah... I was mega peed off when I lost that job. Then I got a job with a security firm. Added another couple of languages learned there. Learned C++ there as the security hardware was coded lower level compared to all my earlier languages... that was the first time I began to have problems with cross language syntax though. Drive me nuts. So yeah.. Three companies, many languages... now learning languages is a chore compared to the early 80’s when I could learn a new one overnight.

The "leading edge" argument is for sure true for Micropython. I used Visual Micro a long time ago. When I started with the ESP8266 they had no support. I still should have a license somewhere...

What a time to be alive...JavaScript on a microcontroller, Can't wait for the new PHP microcontroller!

Does this mean that you would put Pearl in the Wrong column?

@@TheDatabaseDude Pathologically Eclectic Rubbish Lister.

@@andycoombes Seems like 3 adjectives describing a noun - "Lister". What's a "Lister"?

Perl - The only language that looks the same before and after RSA encryption :)

Spoken like someone who has never used APL. When a language requires its own character set and allows characters to be combined into an overstruck new character; things can get ugly.....literally. (I admit I actually kind of like both Perl and APL in their domains so what do I know).

Fortunately, I was able to purchase these two boards locally. So I was glad to be able to support Adafruit once. Generally, you are absolutely right. Sparkfun uses a different shipping and their (shipping) prices were more reasonable recently. 17% of my viewers live in the US. They get it cheaper, I think...

Where in Europe do you live? Because Adafruit has a lot of local distributors. www.adafruit.com/distributors

I must admit that I haven't bought from Adafruit for year. Actually I think that my last order was is 2012, back then there were almost no local distributors. BTW I live in France. I'm going to take a look and see the options. But even with local shipping Adafruit stuff is still too expensive.

Here is a live example of what I have against Adafruit. I checked my nearest local distributor (I live near Bordeaux, France). I selected a random sensor, a BME280 humidity/pressure sensor, and searched for its analog on AliExpress. Here are the results: - Adafruit distributor: 24.5€, shipping not included (goo.gl/Z8uNSy) - AliExpress: 2.20€, shipping included (goo.gl/Q73CyJ) So yes, ten yeas later, the situation is still the same. I won't order anything from Adafruit unless I have absolutely no choice. And same goes for Sparkfun: goo.gl/h1tHcR . I didn't even bothered searching for it on AliExpress, but I think that for the same price, shipping included, you can have something like 100x more headers.

X99 the adafruit price is worth it in a commercial / research environment where the cost of wasting time on a reject / fake part, or not having good documentation, far outweighs the price difference. For hobby projects, the calculation is different.

Little question here. Can you debug code in realtime with this. I mean like ICD (In Circuit Debugger) where you set break points and step code. I started to use arduino for quick and dirty tests. I'm little angry that arduino didn't have ICD. I usually use C/C++ because I can debug it with ICD.

canadian digikey is their official distributor in canada, they have most of the adafruit stuff

I'm not a fan of Adafruit in general but to their credit they have slightly improved their website.

What about shipping to Norway ? Example: BME280 $US 20 + $ 15 shipping. For that price I can buy a weather station with rain gauge locally.

​@@mannhansen9337 You can program the standalone AVR chip that is on the arduino boards and it only costs $1 USD and you can program it in C and be super sexy...I hate arduino...

Haha, let's hope not!

I mean, it's fine if people want to use it, but I think C will remain dominant for just that reason. I thought the ESP32 had a ton of extra resources, at the start of my latest project. Now, even with C++, I'm glad it has all the RAM, flash, and MHz that it does. Gotta say I am tired that nothing I want to connect is 3V, so the board is now full of 5V I/O converters. Ugh.

Hit the bullseye with that, Stumpy. Python is ridiculous, slow bloat for a microcontroller - killing the whole point of a small, direct-to-hardware interface.

You are welcome! It should be possible to get Arduino running on a MAC. At least, a lot of people do that AFAIK.

I found the problem I was having with my Mac was a driver problem. After installing the correct driver, my problems went away and everything started working correctly again. I’m not sure, but I think it might have occurred during one of the OS updates that made it not work correctly.

Mindaugas Vaskevicius - Excellent points. Especially for someone heading onto a real electronics future. But how about some examples of what you see as a better path? That would help dilute the channels endless drive for sponsorship. Pumping the most expensive closed ecosystem is what this video is about. Are their better options? You can't go back to my early days and run 8080As. So what else do you see?

I actually have some fun with esp32 arduino and FreeRTOS tasks... Kind of best of two words?

@@boonedockjourneyman7979 Raspberry PI Zero v1.3 is $5, Pi Zero W is $10. Both run full python2, full python3, real C/C++ and have good examples and documentation. I was playing with the camera (python3) and am impressed by the library and the documentation they have created.

Quite right. All the arduino and python does is make life easy for people to play. Using arduino means using a hidden layer of code that add a lot of wasted processing time. I grew up writing code in assembler and even coding using hex and the opcode manual. Today's programmers are so far removed from the true processing that they never learn the nuances of interrupt timings, bugs due to shared variables and so many other tricky subjects. Real world products and professional hardware coders do not use toys like arduino.

I was taught microcontroller programming using pic 18f4520 in both microchip assembly and C For me python seems too high level for I bedded stuff especially if interpreted I'm also not keen on a language where whitespace matters so much!

Really well said. Python will be good for some projects and certainly for prototyping. The right tool for the right job.

In the hobbyist/hacker/learning space, abstraction = obfuscation. There are some of us who want to understand how something works under the hood, and the push for higher level languages obscures that. Limor Fried has a particular talent for making it hard to actually learn something. You buy one of her sensor breakout boards, it comes with it's own little library and a big block of example code for you to copy/paste. No API or reference or even a bulleted list of all the functions in that library. Heaven help you use the standard libraries in Python or Wiring to connect to a straightforward I2C or SPI device, no, we have to have a library for every little piece of hardware no matter how single purpose.

It's not as simple as "Are abstractions good or bad?" Abstractions can be the right tool for the job and they can be the wrong tool for the job. Necessary abstractions will make your project a success and unnecessary abstractions will make your project a failure. If you're approaching a project from the perspective of "I don't understand these details and I want someone to hide them from me" then you are, to be blunt, ignorant and unqualified to decide if those details are necessary or not. Good developers understand the low level details and choose the appropriate level of abstraction based on the project.

​@@JohnDavidDunlap ​I do agree. I probably should have added more context: "Using C means I can get right in to the guts of the machine". "Why not run an interpreter on an Arduino?......because its waste of recources. Arduino is elegant." "I really doubt that high level language can take over C where you can manipulate single bits of the registers." It is a tool for a job idea. Of course in development team, you have the in depth knowledge of the underlying lower level of apis, meaning a choice of using a framework is more easily done as the team understands the behaviour, advantages and disadvantages of the framework. I mean in my day to day job, I do mainly Spring Boot and ReactJS. Would I switch back to plain Java and plain HTML/CSS/JS? No. Have I had issues while developing because the framework "abstracted" away a little more than I expected? Yes. Spring with JPA and JMS can be a good old fight till you read a lot and read a lot of the source code and spend the time understanding how the APIs work. Would I go back to manually declaring transactions and creating sessions and queues after reading over JPA and JMS? No. I now understand how they work lower down and being able to annotate @Transactional(isolation=READ_COMMITED) is a lot less hassle than the old way and I am less likely to make mistakes writing the one line than writing 30 lines of my own transaction impl. My tests are cleaner and I have to write a lot less tests! I don't need to test code that has already been tested (their APIs). You are right though, I did seem to say "just abstract everything". Sorry. You win an up vote as I do agree fully. So future considerations: 1. Libraries and frameworks can help to structure code and help avoid basic mistakes. 2. They can take time to learn, but once learnt, you end up writing less code that can do a lot more. 2. Pick the libraries and frameworks carefully. Some will be great for the job and have been well tested (code wise and the community) and some will not be tested as well or not at all. 3. Learning the underlying concepts is fun and help solidify your understanding of how 'it all fits together' with or without frameworks and high-level libraries. d = dht.DHT11(machine.Pin(4)) d.measure() t = d.temperature() h = d.humidity() Is a lot of abstraction and doesn't reveal a lot of how the MCU and the OneWire protocol work...so maybe look those up. You could even try write your own implementation of the OneWire protocol. Once happy and you think you get it, maybe just writing the above is more fun in future as it is cleaner looking and easier to manage.

No different than micropython

Interpreters don't compile. Ever. They spit out tokens, which are then interpreted and run.

You don't, the interpreter does.

@@candidmoe8741 Well, I'm no expert but there seem to be experts who agree with me. The Arduino runs compiled code, not interpreted. And so is fast.

@@featherbrain7147 Everyone agrees: compiled is faster. But MCU has cycles to spare and RAM to burn, so why suffer with a low level programming language? For non-time critical applications, development/debugging speed is more important than execution speed. Also, high level lang are easier to debug and maintain.

Agreed

Couldn't agree more

Seriously. The only fault with C is a complete lack of buffer overflow protection. Python is something I want to learn for scripting on OS-X, but no interest in using anything but C or C++ for embedded. There's just no need, a lot of cost, and _at best_ marginal benefit.

@@radellaf you can try java for buffer overflow protection and it is very similar to c/CPP syntax.

how about a bit of Rust?

Why?

I still enjoy using the Vanilla MicroChip PICS for projects. You can get much better performance, especially with power usage and ADC. Arduino and MuPython for quick prototyping is excellent

I asked myself the question because I saw similar things happen many years ago when CPUs got faster and Assembler was replaced by C and other compilers.

There are many benefits to using an interpreted language on an MCU - for example the first time you interact with a peripheral and you can read/write using SPI *live* you will be blown away. It's just so more efficient than trying the 'write/compile/deploy/didin't work, repeat' cycle! :) I have a solid C/C++ background and rarely miss it using MicroPython...in fact it becomes an advantage when you want to optimise performance by writing a C module to be used in MicroPython.

Amen brother.

Marko? is "assembler" still being used in Microcontrollers by professional developers? and why would one choose assembler over C++ ? Thanks

Glad it was helpful!

You are right. For me, it was the natural choice for a start because Adafruit does a lot for the Maker community and their implementation is more comfortable for a beginner. I for sure will test it on an ESP32

Complete open source and open hardware, code for circuit python sits on Github and you can etch your own boards from the eagle files, also on Github

$16.5 on ebay :)

Even more important, the tyoe system in many languages make mixing types much harder. Like hard typed languages like ML and OCaml. Python is hard typed, but it only, as you say, check that in run time. And interpreting languages do take more time executing and usually use more memory. Not for the program, but for data when executing. (Yes, you can write programs that uses much more memory if you choose a bad algorithm)

Don't most modern Python IDEs already detect many errors/bugs that people would normally make? Code completion, spell check, indentation, syntax highlighting, etc... should capture most stuff, especially for beginners. Also, and I haven't tried this, but if it is faster to push updates to the device, maybe it would still be faster to use Python in this case because you only have to send the script and not the entire thing like you would with Arduino?

@@toastrecon no, they don't catch type errors. And no, writing 1KiByte och 100KiByte doesn't make a huge difference.

Thank you for your feedback! I also mentioned that I the structure of the two look similar for me.

Jack Patteeuw 10 I read your text 20 I interpret the text in my brain 30 my brain translates it into useful meanings 40 cannot totally understand 50 goto 10

And then diving into the deep end for speed, by learning 6502 MLX !! That's why the Apple has bite/byte in it !!!

Thank you!

@@AndreasSpiess - I also love your intro ! When I hear it is the "guy with the Swiss accent" I know I will be watching something educational and entertaining !

I saw forth the first time on one of those videos and thought, this is a thing of the past ;-) Never heard before. But it is mentioned a few times in the comments.

FORTH is a nice language. It was also used in the BIOS for Sun computers. Less known fact. :-) And yes, it was created to control space cameras with smal machines with very limited memory. Where you could easily change some names (funktions) to use machine code if needed. Not much of a file system in them though. And today you could use µOCaml to get functional programming in an efficient and type secure way that none of the mentioned languages here could.

MicroPython's asm_thumb support is quite fun... You get to mix Python and a subset of ARM assembly in one place. :) In a completely inefficient manner (assembled on the fly in ram when the code is loaded) but 32-bit microcontrollers these days have plenty of resources for that.

Java would not be that bad of an idea. It is faster then python, simpler then C++ (not to mention C) and safer then both. You could even write in Kotlin for better readability without the variable nonsense.

It's Zerynth in py for ESPs. In uPy, threads work on esp32. On esp8266, there's only asyncio.

There are quite a few in your situation which wrote they started with my videos. So enjoy your new (old) hobby. I am sure you will love the new possibilities!

:-)

C could be more suited for this. It actually has been designed as a systems programming language. C++ adds a lot of high level stuff, which in the end costs performance and increases mem usage and code size. OTOH in the AUTOSAR context I've seen hundreds of lines of C++ code for a class boil down to: mov eax, ecx ret ;)

I'm a heavy user of languages with a lot of abstractions like Python or Java. They are great if development speed is the important factor, not resource efficiency. Also, they are easier to maintain since developers aren't as hard to find as for other languages. C++ always seems like a good tradeoff between high efficiency and decent standard API. Sure, its not as fast as C, but its also not as awful of on experience to program

C++ is an outdated 40 year old collection of ignorance. Even for desktop development it's crap and Rust is superior

I prefer shovels. We're spoiling construction workers these days by letting them use backhoes.

"C++, it's like getting right into the guts of the machine" The first few years of my career was in assembler. I don't know, you kids..

No problem with PropBasic on the Propeller. I am decoding and counting 2M quad counts/sec on a 80MHz Prop, using only one of the 8 processors ;)

@Richard: My point was: We have now very powerful chips at nearly no cost. Does this change anything on how we deal with them? But, of course, I do not have the answer. Just food for thought ;-)

@Carla Radames Well there's nothing wrong with my reading, nor my math. 40,000 I/O updates @ 8MHz would translate to 400,000 @ 80MHz. My number is 2,000,000 @ 80MHz but also involves quadrature decode logic. Sorry to spoil your condescending post.

@Carla Radames As I originally stated...using ONE of the 8 cores. These are 8 independent CPUs, they don't share processes unless you code them to do so. It's a shame that all you know about this amazing MCU is what you only just Googled. If you prefer working with interrupt nonsense then stick with conventional MCUs.

@@AdaptivePhenix Propeller P8X32A-M44 Mini for $24.99, not bad. STM32F103 Bluepill $1.80

I think you will like it.

You are welcome!

Please take a look again; there are *many* more libraries now. Further, it's *much* easier to write libraries in Python so the number is increasingly rapidly. Alternatively you can wrap a C library in MicroPython...

Thank you Matt. I intend to look into it again. I was very interested then and moreso now.

If you can't find a library you need in MicroPython please let me know and I'll see if I can help get the ball rolling to implement one. The MicroPython forum is also a good place to check: forum.micropython.org/

COBOL was my 4th language, after BASIC, Assembly, Pascal

I am sure Python is slower in some cases as it is an interpreted language. However, the question is: Does it matter for my project. I also do not want to fuel the discussions too much ;-) Concerning Python: I also have to learn it for RPI. Machine learning and vision often use Python as an interface...

I will explain in very broad terms so that anyone can understand. The problem with the speed is that it is "compiled" on the MCU and hence is subject to the speed of the MCU which is definitely going to be slower than your Windows/Apple PC. With C on the other hand it works extremely closely with the actual hardware, on a register level. Think of it like this: You asked that question 2 days back (as I can read it). I am replying today, you may read it 2 days later. Total there were 4 days spent for this task. Now compare that to if I was sitting next to you, this conversation wouldn't have taken more than 30 seconds. That's how the difference in speed comes to play. High level languages work from a distance from the hardware, C is very close. You could also imagine another scenario. You are Japanese and only understand Japanese. I am German and only understand German. Now for me to tell you what to do I'd need a German to Japanese translator to talk to me and understand my need. That translator will then talk to you in Japanese. This could have happened much quicker if we both spoke a common language. Hardware doesn't speak Python, it speaks binary and C language is a close bridge between binary and a language that humans can understand. Another scenario to imagine: I am a boss and I walk in to a room of employees and say someone make a presentation about our profits this year. Now who makes that presentation?? It could be the intern, the janitor, the CEO, the programmer, the medic, the guard, the MBA guy??? As a boss I didn't say who was supposed to make it. Well as it turns out the Janitor made the presentation who was hired 2 days back. Will he do the job well and in lesser time? When working in C language, you have to explicitly assign the job to a particular person that you know is best suited for that task. That is also a reason for the higher speed.

Use Visual Studio Code for embedded C/C++ or the official Atmel IDE or MPLABX IDE

Thank you!

Well it's really very good at fast prototyping a design and you can still redo the code in C++ after you've tried out all manner of ideas. They cycle time between changes in code is so much faster... It's exactly the same as what happened on PC's years ago, everybody said we should stick to using assembler and DOS or BIOS calls because of the speed advantage. They also said we don't need GUI's at all...

stewartrv i think comparing PC and uC is not the best approach. In micro controllers there aren’t so many ways to address a solution: tasks and time slicing, perhaps the main ones. I will better implement an OS and stick to C, than use python for direct hardware management.

I'm saying it's history repeating itself. :) We can of course install a realtime OS. But the uC of today have more power than the desktop systems I started using and they used a realtime multitasking microkernel OS. We can of course use RTOS but its way harder to get started with that and still the turn around between iterations of code, upload, test, debug and repeat are much longer. If you want to test an idea and pitch it to a customer python makes it quick, when you have a working prototype you can go back and make it bomb proof in C or whatever. It's not good for everything, but for some applications it works fine. Of course C and Assembler aren't good for everything either - then we have FPGA's and ASIC's etc.

@@stewartrv i completely see your point, and agree on most of it. My slightly different angle is that the history is been forced due to market interest, rather than user/product/developer advantages.

@@aguante0 That is true but it was market interest in the past too. Like Henry Ford said: "If I asked people what they really wanted they would have said faster horses" :D

Lol

You are welcome!

Totally agree! I'm using CLion with PIO - works great.

@Daniele: Comparing two different tools for the same job is ok for me... BTW: I think, I did not mention the IDE. I meant the Hardware and the software as a whole. My question is: Do we keep doing the same thing with hardware which is 10-100x more potent or will also the development environment change (as was the case from Assembler to C 20-30 years ago) I recently used platformIO again (for Tasmota) and I agree it is a good solution for such projects.

Agreed! Arduino was okay for me learning to get an atmega up and running, blink and LED, etc. In my first serious project I had to deal with registers, which arduino doesn't document very well for learners. It's all hidden away in 20 page forum replies. In the end it was about 20kb of code, but it ends up really hard to read not being able to hide or minimize sections easily. I've found mbed, while imperfect, much more friendly. I've been looking at platformIO because it's supposed to be compatible. I'll probably use it for my next project.

@@MikeMitterer Same. I use CLion for the Arduino, when i work on serious projects.

I think intentionally not separating raw embedded c/c++ from Arduino C++ is a mistake. Arduino C++ development is vastly different than developing in a traditional IDE.

You are right. But most of my hobby projects are not "serious" ;-)

Just so you know the inventor of Micro-Python works in the space industry and they are now putting it in Satellites because as you have shown in your video code is executed immediately and this means they can change code on a satellite in space via a radio link. So it seems that the space industry doesn't hit limitation but rather sees it as the next generational step forward

@@outofthebots3122 you can do updates to C code also. I work as a professional embedded engineer and let me tell you, C and assembly are still dominating the microcontroller industry.

@@damny0utoobe yes Mico-Python will never replace C or assembler but it complement it. I often describe uPython is to C what C is to assembler. It is a higher level language that has all the advantages and disadvantages that comes with a higher level language.

Micro-Python does also have viper mode (compiled mode) and also allows inline assembler too. Here a talk given by the inventor of Micro-Python at Py-Con about these modes and writing fast Micro-Python code ukposts.info/have/v-deo/oHiWl2qog2Zh2WQ.html