I am overwhelmed by the number of comments! Thank you very much. I am extremely proud of how many professional programmers are watching this channel and the quality of the discussions. I will not be able to answer all comments, but I read all of them because it is a very good input for the future of this channel. I think I learned more about your thinking in this video than anytime before. This video was triggered by my decision to learn Python on the Raspberry because it is widely used. Then, I thought, let's check if this is also usable on my MCUs. And then I thought I share my findings...
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 ;)
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.
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
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 ;-)
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.
compiled codes works much more fast than interpereted codes. So Arduino much better than Micropython for realtime projects. and dont forget; you will write code 1 time but microcontroller will run it million times !
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.
For me it's not a question of either/or. Both have their rights and advantages in specific situations. Generally I would use Interpreted languages on beefy platforms like RasPi and for rapid prototyping, and compiled languages on low power and small form factors.
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.
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.
What most commenters here don't seem to get: MicroPython has nothing to do with the Python interpreter on your PC. It is a new implementation optimised for running on microprocessors. In the same way you could argue the Arduino framework is slowing things down and you would be better off programming the microprocessors directly in assembler. Also MicroPython is not slow at all and it brings means to even further optimise your programs by precompiling parts in different ways. And MicroPython already contains all means to develop programs. No need for any IDE, programmer or whatever. Connect it to your PC, a new drive will pop up and your code is in one or more text files on that drive. You can edit them with any text editor and once you save them and disconnect the board, your changed code is active. There's even a live REPL console to play with your modules and code. So much easier to work with.
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.
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
I'll say that if you're a beginer maker, go for Arduino. It will allow you to have a better understanding of how code works on the inside. Also, moving from C++ to Python is super easy. The other way around takes a lot of time and re-learning of basic concepts.
Something that may interest hard core C programmers is that you can have best of both worlds. If you need a function to be fast you can write it in C then compile it into the firmware to be called by python. All the experienced Micro-Python users are C programmers that like the quick development cycle of python and the fact it require very little lines of code to achieve the same as C.
When several tools can do a job, it's obviously wise to pick the one you're most comfortable with. Still, whenever I touch python on a microcontroller I cannot help but feel dirty, it's like keeping an entire PC only for checking the time on the little clock at the corner of the monitor :)
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)
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.
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.
I love your stuff. It's like choosing a whole art gallery first, and then finding the painting - Not like other videos that take you through a look at each painting first, and then finding out you're in the wrong art gallery.
I see contrasting comments here and from my personal experience I am not a python fan. But thank you very much for a very informative video and I have learnt several things about developing with it today. Like python or not your video was excellent.
And so starts the decline of the microcontroller real-time aspects as a Windows style bloat of resources takes over. We'll soon need full blown Cortex M7s to just run a background process and handle a digital IO in real time.
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 got me at the file system and REPL. My goodness, I had forgotten unix philosophy "everything is a file" on embedded. This is great! It lowers the bar considerably if people can use whatever editor they like, without any compilers and such. This is going to be the new thing
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.
Arduino low level programing IDE? Flashing LED with 20MHz CPU clock and sending data via uart at low speeds Arduino may do the job. But try running multiple processes in parallel with out "do nothing"(delay) getting in your way when your design reaches real word applications. Try squeezing your design into something like attiny series mcu, where you do not have 20k byte ram or 64-256k flash. Microcontrollers are not microprocessors and they should not be treated as such. My skills as an electronics design engineer ware development in parallel with all of the Arduino hype, but thank God I was shown the difference between a proper design and Arduino shield - include project stuff. Arduino is good for getting attention and getting comfortable with handling electronics, but in my opinion a hobbyist, a maker should know how to use interrupts, how to run multiple processes in parallel, how to design a basic schematic. P.S. delay beyond 20 NOP commands should be frowned upon.
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?
@@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!
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).
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.
I've been using Espruino recently and while I know there's a lot of strong feelings about Javascript it actually works really well for IO-bound applications. Most of my own embedded projects rely more on IO than on raw processor speed and they usually interface with things over standard protocols like I2C/SPI/UART (which the interpreter has implemented really efficiently) so there's not much benefit to writing everything in C. But there is a lot of benefit in having an interpreter that's designed around an event loop which makes asynchronous IO easier to implement.
Coming from java and python side and new to working with C++.. I was amazed at how difficult working with strings in C is.. There’s also a lot more freedom in python when dealing with high level data structures.. hopefully micro python support will continue to grow
With RAM and speed being the largest issues, I won't be switching. I need RAM for passing and receiving strings from peripherals, and speed for interrupt handling and "real time" response
Your videos are always very informative and entertaining. But this video really helped me understand Python and it's variants. Great work! I'll be very interested in seeing additional videos on the topic. Thanks!!
I've never bought from Adafruit because of their outrageous shipping charges to Canada. They don't even want to be bothered sending stuff through USPS international.
@@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...
I really like Adafruit and its products. Always a pleasure to use them. But there is a huge drawback that always kept me from buying them: their prices. Adafruit’s stuff is way, way too expensive. And shipping cost to Europe is completely nuts, knowing that sometimes UPS and such will sneak into you package to make you pay 2, 3 times the taxes. All in all, with 1 Adafruit board I often can buy ten from AliExpress. That’s the sad truth.
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...
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.
i am very excited to have found this! i recently got an Arduino, but was unhappy with having to learn C++ when all my other projects are python oriented. i will definitely be buying Adafruit!
Thank you Andreas for making this video and exploring a new frontier in MCU programming. I've been enjoying MicroPython for over a year now and definitely prefer using the language for fun and serious projects alike. Mainly because I can UNDERSTAND what the code is doing and because an interactive environment is perfect for learning, testing and trying new things. This does not invalidate the need and usefulness of the Arduino platform. It's just a different way to get things done that will appeal to many people. There will be room for both choices for a long time.
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.
I agree with you totally on strings, I study computer engineering at uni and I'm in my first years, the string functions are really tricky compared to other functions. Especially in C when you have to define your own string type
I'll just say that I prefer C++, it's like getting right into the guts of the machine. Python just seems like too much abstraction, we're spoiling future generations ;)
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
So great! I'm excited to learn more about this. My guess on the pronunciation of "Mu" would be that they're looking to have it be like the greek letter "μ", for "micro". Maybe then you'd just pronounce it however that worked in whatever language you spoke. I've heard it pronounced "mew" (rhymes with "you"). Thanks again for making these.
As everything in life, there are advantages and disadvantages. As a software engineer I do agree that Python offers good advantage for beginners, being able to provide faster feedback. However interpreted language cannot be a better option for microcontroller. Once a person gets a solid understanding of the environment it will certainly be able to get more out of C/C++ than any interpreted language when developing for MCU. That being said, Python is great for beginners, education and many similar purposes.
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.
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
I expect Adafruit to continue strong development for circuit python. It is in their best interest and appeals to entry level makers and STEM students alike. And I think it is excellent for hobby projects and Halloween costumes etc. But when execution time is an issue or pointer usage is evident, the power that C++ gives is unparalleled me thinks. But this is also relative to the hardware that is being used. As that improves I expect the technology will plateau as normal, and a newer generation will emerge. We are extremely close to all-in-one single board units that lack nothing - speed, capacity, and scalability in all sectors of specification integration (all transport layers).
Hi Andreas, Thanks a lot for this info, always good to have a summary of the state of new development environments and options! For me (have implemented ~a dozen projects successfully on ESP32 ) it's still way to early to switch to something different. For a project I plan to really use in my house automation, I do not buy one instance but at least 5 to be sure I have spare's for development defect's or longer term use, so at the end price of a single device sums up as a important factor. I really love the ESP32, it's dirty cheap and packed full of functions. Need a board with a color OLED or battery included ?... just pay a few $ more and it's yours... Beside that I do not really like the idea of additional 'complexity' on such boards and probably decreased speed, I would have to solve further things like OTA and UDP debugging which I use a lot and work perfect for me today. I agree that the language may be a little easier for beginners, but missing libraries will be a much bigger problems at the end. Regarding my environment I personally have replaced the Arduino IDE with Visual Micro (since I'm a hardcore developer and like the Visual Studio editor very much), use OTA for all of my projects and use BUILD workflows to automatically compile, check into a source control system and OTA a new version of my code, very handy! And even if ESP32 might be supported at some day, for a real project you typically do not want to be in the front line of discovering their new bugs ;-) ~waltsteinchen
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...
Very informative , I was electronics engineer from the past when digital electronics was just new and then moved away from it and joined Media and Broadcast, I just retired from media broadcasting after 40 years , now I wanted to get back into the new microelectronics but was not sure where to start, I tried Arduino Uno and the Arduino IDE and that pointed me on thinking that I needed to learn a Language and I was thinking of C++ but watching your video has given me food for thought. Thank you Sir you have been inspirational.
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!
I prefer the Arduino IDE. If i need to call functions over the serial port, i have a block of code that reads serial and executes the corresponding function. Most of my projects revolve around Neopixels and large flash usage, so i also need fast number crunching and minimal size. Plus with the Arduino Pro Mini at 2$ each, i can slap them in whatever embedded project i need.
Once you have your fully-developed Arduino C program, you compile it for the last time and then keep using it. You don't have to compile every time you run the program.
@@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.
Great video and in right time for me because now I want to learn coding in python. Thanks again and keep up with your channel because is great and very useful and informative.
As per usual, thanks for showing the full story ( pro's and con's) and providing another great illustration. For the new comer to either electronics or embedded computing, Python ( either circuit or micro ) is a great place to start. Its syntax is close enough to feel comfortable later with c/c++ as per the IDE.
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 can get Arduino boards off of Aliexpress for a couple of bucks. Why would I pay 10 to 20 times as much for Adafruit running interpreted code. Yes, it may take a little longer for pushing changes during the development cycle, but I will take it any day for better performance on the finished product.
Andreas It does not have to be one or the other. Clearly it would make little sense to use a pi for a node that only reports simple data like temperature. A pi makes more sense if you are developing complex code, especially if you are writing object oriented code. The line between the two will vary based on budget and the programmers familiarity with each system. c++ is a kludged extension of c and as an OO language it is clumsy, python is the better choice for serious OO programming. Given that most hobby types make little use of OO in programming this is not an issue. Other than that both are procedural languages and have much in common. You can find several c++ to python translators online.
Yah, nope. No Python for me on MCs. The tasks that need doing all to often need most CPU resources. Recent example ... ESP8266 as a fan controller ... With pwm feedback to interrupt driven line there is limit to how fast it can respond .... at arround 20khz by my measure. Try to get that with Python ... not a chance. Yah going to put hardware dividers in there to slow it down? ... now Python looks more like hassle very quickly.
@@TheChrisey Finally someone who thinks the same as I do. They're more like "problem solvers", and even that with a grain of salt. I started programming just now, at 13 years of age, my first language is Java, and I'm now coding in C++. Programmers should be able to code in C/C++, Assembler and Java. Then they are real programmers, not just doing what would you do with 40 lines of code in C++ and doing it in JavaScript with 1 line.
What there should have been half a decade ago is an on-board FORTH for arduino, popularly promoted and mass-maintained so that it would become THE definitive way of using an arduino for most beginners. FORTH on the actual controller would have been ideal for most people to do most things, most of the time.
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.
I still find it odd that people have an aversion to abstraction. About 38 years ago, the BBC Micro computer (£300 -> About £700/$900 in today money) was made. It had: 2MHz CPU (single thread) and 128KB RAM. No internal flash/ROM. Now...you can get an ESP32 @ 240MHz (120x clock speed) with 512KB RAM (4x as much) internal flash/sketch space and also Wifi, BLE, SPI, I2C I2S and 3x UART built in....all for £5 (1/60th ish of the price) and fits on a 50p piece. I mean why would you want to sit and write an entire RESTful webservice pushing files to an SD card while using a GPS locator and a mobile App for BLE for an IoT device in assembly or eve C...taking months...when micropython could have it done in a few days? It will not be "as quick" or "using the hardware to it's full potential"...but my God, sometimes the abstraction means you can achieve a lot more in a shorter space of time. One day (I am a Java dev work wise) a language will come along that compiles down to C byte code (like Kotlin for Java) that may make the process quicker and easier...but for now, if you want to build something quickly and easily and still relatively cheap batch wise...assembly and C is not the way to go. Now of course, maybe once you have a working project in uPython, maybe try move it over to C/++/# to get the "speed gains" and a smaller cheaper MCU...but in the fast paced world...maybe just getting there first or proving "it works" is more important for the sake of "native assembly/C".
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.
I do research and development for lighting installations, and your approach and perspective is exactly what I would hope in a breakdown. Thank you very much for your time
"has the time come to leave Arduino IDE?" long time ago... I mean, just because it lacks code completion features (or it was when I last time used it) in my opinion the original Arduino IDE is good only for testing components where you use it for 5 minutes max. If you are trying to do something more advanced than blink then I would recommend to look for alternatives - for example "Visual Micro". I didn't used Micropython but I guess it is just normal Python with some special libraries. About Python, which I'm learning, I must say it is not that easy once you started programming with other languages and just now moving to it. The indentation instead curly brackets was at the beginning a pet peeve for me but I'm getting used to it. One other thing to note is that in every other language that I used lambda functions, they could be just like normal functions meanwhile in Python it can be only one statement (one line) :/ You and others in comments mentioned that Python is slower than C++, perhaps you could make a video about it by measuring differences? Is the difference (delay) noticeable ? When should we be aware of it and in which cases we can just ignore it?
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.
Useful AND interesting. I'm more a C++ (Assembly) kinda guy but I can see the merrits of using micropython if speed (or complexity) is not a concern or I just want to play around. Very useful ... thank you.
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.
I am sorry Andreas on this I don't agree. Python is a great scripting language and should be just another way to program anything. To entitle your episode with such a strong, "click bait" title just fuels the fires of "religious wars" between programming languages. Ask yourself, learning any language, be it Python, C/C++, Assembly, Lua, or whatever promotes logical thinking, solves the problem at hand and develops a desire to do more. Running an interpreted language versus a compiled version ultimately doesn't matter. However you solve the problem at hand is the most important thing for any beginner. C is a foundation language and there is nothing to loose by learning its limitations and strengths. I don't disagree that learning a modern language like Python/micropython is valuable also but to say "goodbye to Arduino" (which is like saying goodbye to C/C++) is not constructive either. My advice to beginners is to be open minded, learn from past examples/ mistakes and add tools to your arsenal to be flexible and knowledgable about how things were done in the past and how they are done now. I would like to say that Micropython was created by Damien George, an Australian, and I am 100% committed in supporting his efforts since I am an Australian also, however, I can't discount the incredible existing echo system, tutorials, blog entries, Github repositories that share valuable algorithmic and functional methods to solve problems in other languages including C and C++. Please keep up your good work and thank you for your effort.
The title ends with a question mark. My question was: What will happen next looking at the improved MCU performance and memory size? We had something similar many years ago when everybody used Assembler. You know the answer. I see indications that this can happen a next time in the near future. Especially because C++ is not widely used on SBCs. You saw the statistics...
@@pixelPlex While I am not sure of his origins, his accent is Australian, he studied at Melbourne University (which is in Australia) and so I think we all can be proud of his efforts. Not trying to be nationalistic just pointing out the strong connection for Australians who sometimes are made to think they live in a backwater. Ultimately it doesn't't matter, he leads a great project.
Python (of any kind) on a micro-controller is too limiting. Its a good way to learn programming, but try to do a serious project, and you'll hit a wall pretty quick. I learned C back in 1985 when Life boat and Assoc came out with their first compiler for the IBM PC. Since then, I've learned more than a dozen languages, but I've always gone back to C for any serious work. Yes, it's more complicated than today's interpreted languages, but with power, comes complexity. This is why they use C to write operating systems. I wouldn't be surprised if Python itself was written in C. Compare apples with apples.
Python is written in C. And a lot of its lower level libraries are too. But there's a point to be made here. Most Arduino projects lean heavily on existing libraries to do external device interfacing, PWM, etc. The user program is essentially just adding a bit of control logic to "glue" those functions together. IoT devices, especially, don't tend to do much custom number crunching or complicated arithmetic logic, they're just moving data around over some kind of IO interface and performing basic conditions. So a scripting language like Python actually makes perfect sense.
@Mai Mariarti That's true, but in terms of the low-level interfacing most sensors I've worked with on any serious capacity have used either analog, I2C, SPI, or UART. I can't remember the last time I had a sensor (except for maybe ultrasonic range finders) that didn't use one of those. And all of those protocols are implemented really efficiently for MicroPython and Espruino. You might need to do a bit of high level coordination of those protocols to process the results, but nothing that requires high frequency bit manipulation. In fact, when interacting with UART protocols I find that scripting languages like Python or JS are better because handling text in C is a pain. And that's not even factoring in asynchronous communication logic which requires an entire framework in C to cleanly integrate...
@@DavyBot You are literally giving excuses for your laziness at this point. A programmer or a task for that matter should not be stuck cuz it doesn't have UART or something common like that. You are developing new things and to interface new things you need to get your hands dirty at the low level, timer-counter, ROM address and bit level stuff at times. All you are saying is Python is for gluing together parts of a DIY-kit which makes you look like a kid playing Lego. If there's no python library for it, a python programmer will be helpless. Are we not handicapping the ecosystem by doing that? Why not just use C instead and distribute work in teams? When I learnt microcontrollers in school we were taught to interface the 16*2 LCD, not just in C without libraries but also in Assembly. I have never had any problem with handling text in C. If Python which is written in C can handle text as you desire why can't pure C not handle it? The reason is the programmer is lazy and doesn't want to write his own libraries/functions for the string handling which he needs to do so often and can't dedicate one or two hours once in a lifetime for.
@@Swanicorn The most popular videos on my channel are x86 assembly language tutorials. I've worked in the software industry for over a decade writing code in everything from C, C++, x86, ARMv6, Golang, Python, to Javascript. On projects ranging from industrial monitoring systems to cloud storage. My code has made its way into Apple and Google products. So before you call me a "script kid" or lazy... Keep in mind that every minute you're writing code that someone else has already written (because standards exist to promote reuse) all because you feel the need to flex your elite low-level bit fiddling skills is a minute that you weren't spending to work on the bigger picture (the higher level asymptotically significant algorithms, the complex network infrastructure, solving new problems, etc). Premature optimization is the root of all evil.
Interpreted languages "hide" all errors until runtime. Compiled langages detect many errors during compilation phase (not all of them of course). For a critical system interpreted languages will require much more testing.
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?
thanks for the nice overview. My question is can i run an normal pythonprogramm on my pc and use sesorvalues from the controller. is there an relayable way?
uPython? Might as well be Java. In the current u-controller realm, memory and clock cycles are precious. I've worked in environments where HW resources were extremely limited. I've worked in real-time processing environments where everything HAD to be completed within a 50msec (20x/sec) window. C/C++ are NOT that "high level" of languages - they are close to assembly language for a purpose. (Remember, C was written to write the UNIX OS more than a few years ago.) It all depends on the task being implemented and the resource load on the HW and that is the key determiner of language, OS, and HW selection. I can see uses.
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.
Python is a favorite language of mine. I have used it for class platform scripting where I used to write programs to do initial setup of routers, network switches , etc.
Where is not interpretation? Even microprocessor interprets encoded instructions, to determine what to do. But we have to consider the volume of interpretation, because it is resource bound.
@@2zz98 no it's not. The Arduino read/write pin functions are just as slow as MicroPython Saying python on Arduino is bad because of the performance loss is stupid when using cripplingly slow functions anyway Arduino is alot of things. Elegant or performance oriented aren't one of them
Really good material. I am not sure about one question. What if I would upload Micropython firmware. Can I still compile and upload programs written in c/c++ via VSCode or ArduinoIDE or program normally with the firmware loaded in the flash memory? Should I clean the flash memory when I want to change the programming method?
It might be worth mentioning that both the SAMD bootloaders from Adafruit and Arduino (zero boards) are not easy to burn on a fresh chip. I've saved one reference where someone used a STlinkV2 to burn the bootloader, but if you actually try to follow that example, there is no pinout mentioned and several details are not explained. In the comments you will find several people that discovered this the hard way. I looked into this around 2 months ago and haven't revisited it since. So maybe things have changed, but there were quite a few comments and blog posts about people having problems like this when I spent a few hours researching it. As far as the ability to execute code in a serial terminal. One option for AVRs is Forth. While I haven't actually tried it myself, there is a small electronics channel called "0033mer" that has several uploads where he demonstrates Forth on various platforms. Most of the time he is not actually demonstrating Forth like a tutorial on it specifically. He usually uses it while demonstrating other simple things. From the little bit I've picked up here and there, Forth is one of the early computer programs from back in the days when the specs of a modern ARM SOC exceeded the performance of most University mainframe computers. So Forth is one of those tiny programs that can run on simple microcontrollers with plenty of room to spare. I'm sure others know far more than myself here, but this is what I know on this subject, and the challenge that holds me back from trying SAMD hardware ;) -Jake
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.
Brilliant work again! The Micropython/C++ was a question sitting in the background for me. I'll be watching the Video again, as I'm a Fortran77 generation person and take time to assimilate. Thank you for your time, hope to support your channel, definite Thumbs up from me :)
Beauty of C/C++ on Arduino is the ability to seamlessly descend into assembler and ISRs when needed. Can you perform 40,000 input and output samples/second on an 8 MHz $5 Arduino Uno clone with microPython ?
@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.
I think you meant to say "Goodbye to C++"? Comparing Arduino IDE vs Python gives a bad taste in my mouth, as they are 2 completely different things :) Arduino IDE is not a programming language. In any case, you should definitely say goodbye to Arduino IDE. Absolutely no reason to use it now when PlatformIO is stable. Arduino IDE is a horrible IDE. It's almost like coding in Windows Notepad. No autocompletion or anything.
@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.
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.
Wow!!! 😲 That looks like it is going to be really simple and straight forward unlike anything that Arduino has to offer, I cannot get my ESP8266’s & ESP32’s to work well with the Mac Arduino IDE… Thanks Andreas!!!
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.
I think - out of all of the technology presenters on youtube - which I have reviewed - having to do with micro devices such as the Rpi , Arduino etc - you are probably the most informed. And I suspect you have a knowledge about the internals of these devices - such as how to read/write directly to CPU registers - than other presenters on youtube. Thank you for this excellent review! Sincere thanks!!
we find that makers run into the limitations of python very quickly. good to introduce your grandmother to arduino but too limiting for serious projects.
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 ruclips.net/video/hHec4qL00x0/видео.html
uPython looks pretty in case of proof of concept when you want to quickly check your program, without continuously rewriting code to MCU. But at the end in production implementation it will works as an operating system, that can give more potential problems, and ate MCU resources etc. It will be clever if be possible to develop and test in uPython and finally compile the whole program in legacy way, as a binary file, without interpreting inside MCU
It’s quite funny, at least, trying to force a high level language on a micro controller. It’s seems almost a marketing strategy in order to sell more uC to newbies, whom barely know what a voltage is.
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
Thank you for the video. I want to start making projects however the C++ programming was very complicated. I'm going to look into the Python programming in your examples that looks very straightforward. Hopefully I'll start making something and if I do I will share it with you
For me the big problem is ADAFRUIT. They do provide lots of support and libraries etc but I have had problems trying to get any of their code to run on non adafruit boards. They try to guilt you into buying hardware from them by telling you of all the development time and resources they have invested....(cue violins!). I feel their hardware is very overpriced. Life was so much easier back in the old days of Z80 assembler! Bob
My first micro was a TRS-80 and I did assembler on an 8085 for 18h a day. A complete nerd. But I lost a lot of time for simple things like a floating point division and waiting till the EEPROM was erased and programmed. I do not miss the tools of these times and enjoy what we have now. What I miss more is to get up in the morning without any pain ;-)
I hate the fact that Adafruit has forked Micropython instead of simply joining micropython and extending it. They are the Microsoft of uC and electronics now. Making overpriced proprietary solutions and taking Damien's hard work and using it for free!
I've got news for you: this is done intentionally and rightly so. The boards they are selling are for the purpose of learning. You aren't supposed to take their code and use it on different hardware. At that point is when you're supposed to start learning the actual code.
For non critical, and non commercial "Playthings" I'll agree with you. I use arduino daily in my job as the project manager of a large ioT project which has to deal with lot of legacy sensors and equipment. Implementing 4th Gen SCADA would be very difficult without these small devices to do things such as convert analog signals to BCD for older systems. Yes there are still a lot of controllers out there based on DOS and Turbo Pascal. Allowing companies to continue to deploy these systems, I can here you all laughing now, requires certain things to be built, such as serial scale heads talking to pc based systems which are still using parallel IO. The arduino IDE is not required but does a great job at what it was intended to do. Of course if you are as fluent in c/c++ as I am and know your programming environment well, you would be using the VS Code, arm cross compileer, JTAG interface, and BOSSA to get the job done. This Python stuff is just for those who want to throw hardware at every problem and are too lazy to actually learn a coding dicipline which has pretty much been invariant, works on thousands of platforms, and has standards. Having said that , how would you secure this type of environment in an industrial setting to protect from reverse engineering and intellectual property theft? Not that you could hide anything from me because I quite readily read the output from a c compiler as if it were english.
You remind me of one of my first paid project where I had to build an interface between an old, but expensive printer and the new computer. It was done in 8080 Assembler, of course...
Sorry, but Python is an interpreted language and is, by default, slower running than C/C++ which compiles into native code. I am sure I will trigger someone but facts are facts. C/C++ compiles down to machine language and Python is just slower. btw, I froze the frame with the chart of languages and you know what I see? Ease of programming at the cost of shitty slow programs. Java is the worst at creating slow code and is considered a dismal failure by any sane, and rational, programmer.
I think you describe the conflict of speed of the machine vs. speed of development. This is a universal battle in all technology. Technological advances sometimes shift this conflict to higher levels.
I agree, plus it's more powerful to use C. I have no idea why people think C is harder to use and slower to develop for. Python is a pretty bad language too.
I'm a little bit in-between.... I've worked with python as a frontend language for some kind of game editor where most it did was configuring or using the lower-level C++ code. That being said, python may be a nice high-level descriptive language, but the libraries it uses will still have to be C/C++, don't they?
You are right, but speed is not always most important thing. You can always optimize your code, even in the Python ruclips.net/video/hHec4qL00x0/видео.html&t=1055
Python has it's place and I enjoy using it for cross platform work, but I think Arduino is perfect for the little microcontrollers. It's a simple language that supports smaller hardware projects well. Controller projects should not be solved by pushing more and more hardware at them so we can run interpreted languages. We should be getting closer to the hardware for efficiency. Yes, it is harder to do, but it is also the right thing to do in many instances where power supply and processing power are limited. Adafruit seem to be a great company doing many things right, but I think their branching off into Microcontroller Python is the wrong thing to do.
The idea of running python on a micro just blew my mind... It's bad enough that we have crappy scripting languages running on PC, slowing them down and requiring 100x the processing power to do simple tasks that I used to have no problem doing on a Pentium 133. Now people want this crap on their micro-controllers? XD well now you need an arm8 and 1 gig of ram to run your iot sensor XD
For me, the huge, huge advantage is that the sourcecode is right there on the device. Years later I can access it and change the python code with no hassle. Can you be sure that you've kept copies of all the libraries etc you need for the arduino sketch (and a compatible version of the Arduion app) ?
You already use readily available pre made Chips? How pathetic, real engineers design ASICs for everything! But jokes aside, the key is productivity and maintabilty. Sure as an computer engineer I'm sometimes upset, because I was trained at carefully setting bits in registers in assembly and writing C-code for less critical stuff, but truth is, it's not required all the time and becomming obsolete. These days where an ARM SoC costs below 1$ when you have the ressources (computing power, batter life ect), why not go for a script? Its cheaper, easier to do and maintain and it's even more secure. There is a reason PCs moved on from bare metal programming. The vast majority of that code was written by experts, who had years of training, and if you look in any security/exploit database, even then they made tons of mistakes. Nowadays an interessted high school kid can do the same stuff within minutes. Its less efficient, but they can use their brain power towards more important problems that haven't been solved thousand times before, and I think thats a good thing.
To wait a month and no free replacement if it's DOA? No thanks, not for something under $20! Now Triangle Labs 3d printing stuff, that's chinesium worthy of buying.
I think in a few years BASIC will come back big, because it's much more convinient and intuitive than Python or any other programming language. And if we already sacrifice flexibility and performance for having easier programming, then why not go the full way?
After all these comments I plan to do a video with MicroPython on ESP32 and test the different aspects which were mentioned. Then we know probably more... But this will take some time...
@@AndreasSpiess i see a few discussion on something called forth, maybe worth some investigation efforts? then there are other platforms, maybe not very popular www.esp8266basic.com/ then there is a hackaday post, hackaday.com/2016/10/27/basic-interpreter-hidden-in-esp32-silicon/ and then, there was lua interpreter and so many others, i think most of them will have functionality for basic tasks, problems may arise for advanced or as my professor used to say, for the "boundary" conditions and measuring that using a tool like jack ganssle did ruclips.net/video/f8KGatsPTNo/видео.html but looking at the comments below, it looks like a lot of people are looking for alternatives to the arduino, interpreter is highly sought but compiler is also must. this probably implies, such tools still do not exist because nobody made them on account of complexity and work involved. but no one can complain because these tools are "free"
@@AndreasSpiess so i come to conclusion that religion as in this video 0:56 is a matter of "interpretation". we do not follow the principle of supply and demand but we think from hour hearts. but being humans, get carried away sometimes...but that makes the world complex and interesting, ruclips.net/video/m55HKChS2zk/видео.html please pardon me for ignorance. it is only a light-hearted joke in the spirit of this video...
While I like new micro controllers, I have yet to have a project I couldn’t complete with some arduino. I agree this micropython saves development time but if I need the extra power, I’ll use a raspberry pi zero which only costs around $15
Then you must not be doing deterministic real-time. The Parallax Propeller has 8 CPUs, running in parallel....no need for interrupt nonsense. They have just received engineering samples of "P2"....exciting times ahead. :)
I worked with both and both has its own place. Additionally to mentioned remarks in this video: Python/Micropython - Python is main programming language in Raspberry. For raspberry you have comparable community as Arduino. There is also Zerynth project in mature state, where you can mix python and C language in one solution.
When I develop embedded applications I do NOT want multiple layers of software between my application and the hardware. If there are bugs, I want them to be MY bugs. That way, I can do something about it. I'm using the ATMEGA328P (Arduino) in money making commercial applications. I need to be able to rely on the software. That's why C and C++ will be here for a long time yet. It probably IS time to move away from the ATMEGA family. You can buy a 32 bit ARM M0 for a lot less money. But use a 'black box' language to develop my applications? No thanks.
Where's the black box? MicroPython is written in C, you can debug the code. :) Admittedly it is adding a layer but that layer allows you to develop faster with less code.
ARM Cortex M series are great microcontrollers. :) NXP got some nice stuff. I think PIC and AVR are both also heading those ways. CPU architecture is standardizing towards ARM currently. Even Microcontrollers now. Was a fun time back in the day with AVR and PIC though. Even more amazing is that currently with the Architecture standardizing Rust language cane easily become popular. It's an Amazing compiler and generates Safe code with no leaks.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
I am overwhelmed by the number of comments! Thank you very much. I am extremely proud of how many professional programmers are watching this channel and the quality of the discussions. I will not be able to answer all comments, but I read all of them because it is a very good input for the future of this channel. I think I learned more about your thinking in this video than anytime before. This video was triggered by my decision to learn Python on the Raspberry because it is widely used. Then, I thought, let's check if this is also usable on my MCUs. And then I thought I share my findings...
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.
When adafruit stops charging 50$ for 5$ hardware I’ll consider getting smth from them.
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
Excellent! Thanks for dispelling my trepidation. Until now I thought: "feather? meh, it's not arduino."
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.
compiled codes works much more fast than interpereted codes. So Arduino much better than Micropython for realtime projects. and dont forget; you will write code 1 time but microcontroller will run it million times !
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
LowJack187 yeah those temperature reading are super important
For me it's not a question of either/or. Both have their rights and advantages in specific situations. Generally I would use Interpreted languages on beefy platforms like RasPi and for rapid prototyping, and compiled languages on low power and small form factors.
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.
What most commenters here don't seem to get: MicroPython has nothing to do with the Python interpreter on your PC. It is a new implementation optimised for running on microprocessors. In the same way you could argue the Arduino framework is slowing things down and you would be better off programming the microprocessors directly in assembler. Also MicroPython is not slow at all and it brings means to even further optimise your programs by precompiling parts in different ways.
And MicroPython already contains all means to develop programs. No need for any IDE, programmer or whatever. Connect it to your PC, a new drive will pop up and your code is in one or more text files on that drive. You can edit them with any text editor and once you save them and disconnect the board, your changed code is active. There's even a live REPL console to play with your modules and code. So much easier to work with.
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
I'll say that if you're a beginer maker, go for Arduino. It will allow you to have a better understanding of how code works on the inside. Also, moving from C++ to Python is super easy. The other way around takes a lot of time and re-learning of basic concepts.
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.
Something that may interest hard core C programmers is that you can have best of both worlds. If you need a function to be fast you can write it in C then compile it into the firmware to be called by python. All the experienced Micro-Python users are C programmers that like the quick development cycle of python and the fact it require very little lines of code to achieve the same as C.
When several tools can do a job, it's obviously wise to pick the one you're most comfortable with. Still, whenever I touch python on a microcontroller I cannot help but feel dirty, it's like keeping an entire PC only for checking the time on the little clock at the corner of the monitor :)
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?
@@candidmoe8741 life IS pain. Anyone who says differently is selling something.
CONGRATS, I'VE BEEN WATCHING YOUR VIDEOS... IT'S AMAZING HOW TECHNICAL AND SIMPLE IT IS... I HOPE THAT YOU CONTINUE DOING A GOOD JOB HERE.
I'm too old to change languages. However, I've used both and do have an opinion..
When my wife gets home, I'll ask her what it is.
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.
I love your stuff. It's like choosing a whole art gallery first, and then finding the painting - Not like other videos that take you through a look at each painting first, and then finding out you're in the wrong art gallery.
I see contrasting comments here and from my personal experience I am not a python fan. But thank you very much for a very informative video and I have learnt several things about developing with it today. Like python or not your video was excellent.
Thank you for your feedback. That was my intention and the reason for the question mark at the end.
And so starts the decline of the microcontroller real-time aspects as a Windows style bloat of resources takes over. We'll soon need full blown Cortex M7s to just run a background process and handle a digital IO in real time.
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.
I did my final project for my bachelor in electrical engineering using ESP32 and micropython. It worked very well, and impressed the examiners.
I know I'm 5 years late but what did you do for the final project?
You got me at the file system and REPL. My goodness, I had forgotten unix philosophy "everything is a file" on embedded. This is great! It lowers the bar considerably if people can use whatever editor they like, without any compilers and such. This is going to be the new thing
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.
Arduino low level programing IDE? Flashing LED with 20MHz CPU clock and sending data via uart at low speeds Arduino may do the job. But try running multiple processes in parallel with out "do nothing"(delay) getting in your way when your design reaches real word applications. Try squeezing your design into something like attiny series mcu, where you do not have 20k byte ram or 64-256k flash. Microcontrollers are not microprocessors and they should not be treated as such. My skills as an electronics design engineer ware development in parallel with all of the Arduino hype, but thank God I was shown the difference between a proper design and Arduino shield - include project stuff. Arduino is good for getting attention and getting comfortable with handling electronics, but in my opinion a hobbyist, a maker should know how to use interrupts, how to run multiple processes in parallel, how to design a basic schematic. P.S. delay beyond 20 NOP commands should be frowned upon.
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!
"I firmly believe there is no right or wrong programming language."
Spoken like someone who has never used Perl.
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).
I'll stick to plain old embedded C, thanks. Python is much more interesting in other applications, not MCUs.
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?
I've been using Espruino recently and while I know there's a lot of strong feelings about Javascript it actually works really well for IO-bound applications. Most of my own embedded projects rely more on IO than on raw processor speed and they usually interface with things over standard protocols like I2C/SPI/UART (which the interpreter has implemented really efficiently) so there's not much benefit to writing everything in C. But there is a lot of benefit in having an interpreter that's designed around an event loop which makes asynchronous IO easier to implement.
What a time to be alive...JavaScript on a microcontroller, Can't wait for the new PHP microcontroller!
Coming from java and python side and new to working with C++.. I was amazed at how difficult working with strings in C is.. There’s also a lot more freedom in python when dealing with high level data structures.. hopefully micro python support will continue to grow
Just the introduction, I have to give thumbs up. You are the only one who list out the content.
With RAM and speed being the largest issues, I won't be switching. I need RAM for passing and receiving strings from peripherals, and speed for interrupt handling and "real time" response
8051 Assembly !
Your videos are always very informative and entertaining. But this video really helped me understand Python and it's variants. Great work! I'll be very interested in seeing additional videos on the topic. Thanks!!
I've never bought from Adafruit because of their outrageous shipping charges to Canada.
They don't even want to be bothered sending stuff through USPS international.
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...
Gràcies!
Gràcies pel teu suport!
I really like Adafruit and its products. Always a pleasure to use them. But there is a huge drawback that always kept me from buying them: their prices. Adafruit’s stuff is way, way too expensive. And shipping cost to Europe is completely nuts, knowing that sometimes UPS and such will sneak into you package to make you pay 2, 3 times the taxes. All in all, with 1 Adafruit board I often can buy ten from AliExpress. That’s the sad truth.
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.
i am very excited to have found this! i recently got an Arduino, but was unhappy with having to learn C++ when all my other projects are python oriented. i will definitely be buying Adafruit!
Thank you Andreas for making this video and exploring a new frontier in MCU programming. I've been enjoying MicroPython for over a year now and definitely prefer using the language for fun and serious projects alike. Mainly because I can UNDERSTAND what the code is doing and because an interactive environment is perfect for learning, testing and trying new things. This does not invalidate the need and usefulness of the Arduino platform. It's just a different way to get things done that will appeal to many people. There will be room for both choices for a long time.
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.
I agree with you totally on strings,
I study computer engineering at uni and I'm in my first years, the string functions are really tricky compared to other functions.
Especially in C when you have to define your own string type
I'll just say that I prefer C++, it's like getting right into the guts of the machine. Python just seems like too much abstraction, we're spoiling future generations ;)
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..
So great! I'm excited to learn more about this. My guess on the pronunciation of "Mu" would be that they're looking to have it be like the greek letter "μ", for "micro". Maybe then you'd just pronounce it however that worked in whatever language you spoke. I've heard it pronounced "mew" (rhymes with "you"). Thanks again for making these.
As everything in life, there are advantages and disadvantages. As a software engineer I do agree that Python offers good advantage for beginners, being able to provide faster feedback. However interpreted language cannot be a better option for microcontroller. Once a person gets a solid understanding of the environment it will certainly be able to get more out of C/C++ than any interpreted language when developing for MCU.
That being said, Python is great for beginners, education and many similar purposes.
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
I don't want ever have to write "for (i=0; i
32 euros each + shipping
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 :)
Very nice project! Thank you!
You are welcome!
I expect Adafruit to continue strong development for circuit python. It is in their best interest and appeals to entry level makers and STEM students alike. And I think it is excellent for hobby projects and Halloween costumes etc. But when execution time is an issue or pointer usage is evident, the power that C++ gives is unparalleled me thinks. But this is also relative to the hardware that is being used. As that improves I expect the technology will plateau as normal, and a newer generation will emerge. We are extremely close to all-in-one single board units that lack nothing - speed, capacity, and scalability in all sectors of specification integration (all transport layers).
👍👍 Very nice overview, thank you! It helps beginner and intermediate hobbyists to make an educated decision.
Hi Andreas,
Thanks a lot for this info, always good to have a summary of the state of new development environments and options!
For me (have implemented ~a dozen projects successfully on ESP32 ) it's still way to early
to switch to something different.
For a project I plan to really use in my house automation, I do not buy one instance but at least 5 to be sure I have spare's for development defect's
or longer term use, so at the end price of a single device sums up as a important factor.
I really love the ESP32, it's dirty cheap and packed full of functions.
Need a board with a color OLED or battery included ?... just pay a few $ more and it's yours...
Beside that I do not really like the idea of additional 'complexity' on such boards and probably
decreased speed, I would have to solve further things like OTA and UDP debugging which I use a lot and work
perfect for me today. I agree that the language may be a little easier for beginners, but missing libraries will be a much bigger problems
at the end.
Regarding my environment I personally have replaced the Arduino IDE with Visual Micro (since I'm a hardcore developer and like the Visual Studio editor
very much), use OTA for all of my projects and use BUILD workflows to automatically compile, check into a source control system and OTA a new version of my code, very handy!
And even if ESP32
might be supported at some day, for a real project you typically do not want to be in the front line of discovering their new bugs ;-)
~waltsteinchen
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...
Very informative , I was electronics engineer from the past when digital electronics was just new and then moved away from it and joined Media and Broadcast, I just retired from media broadcasting after 40 years , now I wanted to get back into the new microelectronics but was not sure where to start, I tried Arduino Uno and the Arduino IDE and that pointed me on thinking that I needed to learn a Language and I was thinking of C++ but watching your video has given me food for thought. Thank you Sir you have been inspirational.
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!
I prefer the Arduino IDE. If i need to call functions over the serial port, i have a block of code that reads serial and executes the corresponding function. Most of my projects revolve around Neopixels and large flash usage, so i also need fast number crunching and minimal size. Plus with the Arduino Pro Mini at 2$ each, i can slap them in whatever embedded project i need.
Your videos are so informative and helpful.
I will always give you a thumbs up
Once you have your fully-developed Arduino C program, you compile it for the last time and then keep using it. You don't have to compile every time you run the program.
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.
Great video and in right time for me because now I want to learn coding in python. Thanks again and keep up with your channel because is great and very useful and informative.
As per usual, thanks for showing the full story ( pro's and con's) and providing another great illustration. For the new comer to either electronics or embedded computing, Python ( either circuit or micro ) is a great place to start. Its syntax is close enough to feel comfortable later with c/c++ as per the IDE.
About time! :) it will be good series to follow along. Thank you Andreas!
It's really great for prototyping and tinkering quickly, but I would never use it for a real project with any level of permanence
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
A nice explanation, I am bewildered by everything on a single board computers!
I can get Arduino boards off of Aliexpress for a couple of bucks. Why would I pay 10 to 20 times as much for Adafruit running interpreted code. Yes, it may take a little longer for pushing changes during the development cycle, but I will take it any day for better performance on the finished product.
I always go to Adafruit FIRST for anything I need in my work. Way to go Adafruit. Thank you so much. Great company and great support.
Andreas It does not have to be one or the other. Clearly it would make little sense to use a pi for a node that only reports simple data like temperature. A pi makes more sense if you are developing complex code, especially if you are writing object oriented code. The line between the two will vary based on budget and the programmers familiarity with each system.
c++ is a kludged extension of c and as an OO language it is clumsy, python is the better choice for serious OO programming. Given that most hobby types make little use of OO in programming this is not an issue. Other than that both are procedural languages and have much in common. You can find several c++ to python translators online.
Thank you for your feedback! I also mentioned that I the structure of the two look similar for me.
Thanks for your analysis and explanation.
Yah, nope. No Python for me on MCs. The tasks that need doing all to often need most CPU resources. Recent example ... ESP8266 as a fan controller ... With pwm feedback to interrupt driven line there is limit to how fast it can respond .... at arround 20khz by my measure. Try to get that with Python ... not a chance. Yah going to put hardware dividers in there to slow it down? ... now Python looks more like hassle very quickly.
probably initial prototyping before optimizing it using c
i think i did that using initially .. was it AVR or PIC using the basic .. ...
The only reason for why they brought Python to MCs is to introduce them to noobs and sugar coat it in simplicity so they can sell more boards.
@@TheChrisey There is an entire generation who only know Python and Javascript.
@@pt17171 Sadly that's true, and yet they dare calling themselves programmers or developers
@@TheChrisey Finally someone who thinks the same as I do. They're more like "problem solvers", and even that with a grain of salt. I started programming just now, at 13 years of age, my first language is Java, and I'm now coding in C++. Programmers should be able to code in C/C++, Assembler and Java. Then they are real programmers, not just doing what would you do with 40 lines of code in C++ and doing it in JavaScript with 1 line.
love your channel, you're so professional
Thank you!
How about multitasking in python? I have not seen an RTOS in python yet.
It's Zerynth in py for ESPs.
In uPy, threads work on esp32. On esp8266, there's only asyncio.
Thankyou. I used to love basic, C, C++ again was harder but enjoyed it. I must try this micropython more when am feeling a bit better.
What there should have been half a decade ago is an on-board FORTH for arduino, popularly promoted and mass-maintained so that it would become THE definitive way of using an arduino for most beginners. FORTH on the actual controller would have been ideal for most people to do most things, most of the time.
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.
Thanks for putting the effort to explain it on simple terms.
I still find it odd that people have an aversion to abstraction.
About 38 years ago, the BBC Micro computer (£300 -> About £700/$900 in today money) was made.
It had: 2MHz CPU (single thread) and 128KB RAM. No internal flash/ROM.
Now...you can get an ESP32 @ 240MHz (120x clock speed) with 512KB RAM (4x as much) internal flash/sketch space and also Wifi, BLE, SPI, I2C I2S and 3x UART built in....all for £5 (1/60th ish of the price) and fits on a 50p piece.
I mean why would you want to sit and write an entire RESTful webservice pushing files to an SD card while using a GPS locator and a mobile App for BLE for an IoT device in assembly or eve C...taking months...when micropython could have it done in a few days?
It will not be "as quick" or "using the hardware to it's full potential"...but my God, sometimes the abstraction means you can achieve a lot more in a shorter space of time.
One day (I am a Java dev work wise) a language will come along that compiles down to C byte code (like Kotlin for Java) that may make the process quicker and easier...but for now, if you want to build something quickly and easily and still relatively cheap batch wise...assembly and C is not the way to go.
Now of course, maybe once you have a working project in uPython, maybe try move it over to C/++/# to get the "speed gains" and a smaller cheaper MCU...but in the fast paced world...maybe just getting there first or proving "it works" is more important for the sake of "native assembly/C".
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.
I do research and development for lighting installations, and your approach and perspective is exactly what I would hope in a breakdown. Thank you very much for your time
Glad it was helpful!
"has the time come to leave Arduino IDE?" long time ago... I mean, just because it lacks code completion features (or it was when I last time used it) in my opinion the original Arduino IDE is good only for testing components where you use it for 5 minutes max. If you are trying to do something more advanced than blink then I would recommend to look for alternatives - for example "Visual Micro".
I didn't used Micropython but I guess it is just normal Python with some special libraries. About Python, which I'm learning, I must say it is not that easy once you started programming with other languages and just now moving to it. The indentation instead curly brackets was at the beginning a pet peeve for me but I'm getting used to it. One other thing to note is that in every other language that I used lambda functions, they could be just like normal functions meanwhile in Python it can be only one statement (one line) :/
You and others in comments mentioned that Python is slower than C++, perhaps you could make a video about it by measuring differences? Is the difference (delay) noticeable ? When should we be aware of it and in which cases we can just ignore it?
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
Useful AND interesting. I'm more a C++ (Assembly) kinda guy but I can see the merrits of using micropython if speed (or complexity) is not a concern or I just want to play around. Very useful ... thank you.
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.
I am sorry Andreas on this I don't agree. Python is a great scripting language and should be just another way to program anything. To entitle your episode with such a strong, "click bait" title just fuels the fires of "religious wars" between programming languages. Ask yourself, learning any language, be it Python, C/C++, Assembly, Lua, or whatever promotes logical thinking, solves the problem at hand and develops a desire to do more. Running an interpreted language versus a compiled version ultimately doesn't matter. However you solve the problem at hand is the most important thing for any beginner. C is a foundation language and there is nothing to loose by learning its limitations and strengths. I don't disagree that learning a modern language like Python/micropython is valuable also but to say "goodbye to Arduino" (which is like saying goodbye to C/C++) is not constructive either. My advice to beginners is to be open minded, learn from past examples/ mistakes and add tools to your arsenal to be flexible and knowledgable about how things were done in the past and how they are done now. I would like to say that Micropython was created by Damien George, an Australian, and I am 100% committed in supporting his efforts since I am an Australian also, however, I can't discount the incredible existing echo system, tutorials, blog entries, Github repositories that share valuable algorithmic and functional methods to solve problems in other languages including C and C++. Please keep up your good work and thank you for your effort.
The title ends with a question mark. My question was: What will happen next looking at the improved MCU performance and memory size? We had something similar many years ago when everybody used Assembler. You know the answer.
I see indications that this can happen a next time in the near future. Especially because C++ is not widely used on SBCs. You saw the statistics...
Its a good discussion to have so I get why you have it on your channel. @@AndreasSpiess
Damien George for the record is British ( dpgeorge.net/ ) not Australian.
@@pixelPlex While I am not sure of his origins, his accent is Australian, he studied at Melbourne University (which is in Australia) and so I think we all can be proud of his efforts. Not trying to be nationalistic just pointing out the strong connection for Australians who sometimes are made to think they live in a backwater. Ultimately it doesn't't matter, he leads a great project.
Thank you for content. I am always learning something new
Python (of any kind) on a micro-controller is too limiting.
Its a good way to learn programming, but try to do a serious project, and you'll hit a wall pretty quick.
I learned C back in 1985 when Life boat and Assoc came out with their first compiler for the IBM PC.
Since then, I've learned more than a dozen languages, but I've always gone back to C for any serious work.
Yes, it's more complicated than today's interpreted languages, but with power, comes complexity.
This is why they use C to write operating systems. I wouldn't be surprised if Python itself was written in C.
Compare apples with apples.
Python is written in C. And a lot of its lower level libraries are too. But there's a point to be made here. Most Arduino projects lean heavily on existing libraries to do external device interfacing, PWM, etc. The user program is essentially just adding a bit of control logic to "glue" those functions together. IoT devices, especially, don't tend to do much custom number crunching or complicated arithmetic logic, they're just moving data around over some kind of IO interface and performing basic conditions. So a scripting language like Python actually makes perfect sense.
@Mai Mariarti That's true, but in terms of the low-level interfacing most sensors I've worked with on any serious capacity have used either analog, I2C, SPI, or UART. I can't remember the last time I had a sensor (except for maybe ultrasonic range finders) that didn't use one of those. And all of those protocols are implemented really efficiently for MicroPython and Espruino. You might need to do a bit of high level coordination of those protocols to process the results, but nothing that requires high frequency bit manipulation.
In fact, when interacting with UART protocols I find that scripting languages like Python or JS are better because handling text in C is a pain. And that's not even factoring in asynchronous communication logic which requires an entire framework in C to cleanly integrate...
@@DavyBot You are literally giving excuses for your laziness at this point. A programmer or a task for that matter should not be stuck cuz it doesn't have UART or something common like that. You are developing new things and to interface new things you need to get your hands dirty at the low level, timer-counter, ROM address and bit level stuff at times. All you are saying is Python is for gluing together parts of a DIY-kit which makes you look like a kid playing Lego. If there's no python library for it, a python programmer will be helpless. Are we not handicapping the ecosystem by doing that? Why not just use C instead and distribute work in teams? When I learnt microcontrollers in school we were taught to interface the 16*2 LCD, not just in C without libraries but also in Assembly. I have never had any problem with handling text in C. If Python which is written in C can handle text as you desire why can't pure C not handle it? The reason is the programmer is lazy and doesn't want to write his own libraries/functions for the string handling which he needs to do so often and can't dedicate one or two hours once in a lifetime for.
@@Swanicorn The most popular videos on my channel are x86 assembly language tutorials. I've worked in the software industry for over a decade writing code in everything from C, C++, x86, ARMv6, Golang, Python, to Javascript. On projects ranging from industrial monitoring systems to cloud storage. My code has made its way into Apple and Google products. So before you call me a "script kid" or lazy... Keep in mind that every minute you're writing code that someone else has already written (because standards exist to promote reuse) all because you feel the need to flex your elite low-level bit fiddling skills is a minute that you weren't spending to work on the bigger picture (the higher level asymptotically significant algorithms, the complex network infrastructure, solving new problems, etc). Premature optimization is the root of all evil.
@@jamesd4846 I was quoting Donald Knuth: wiki.c2.com/?PrematureOptimization
you have convinced me ... since last week i use MicroPython at my esp8266 too ... very exciting ..thank you .. wirklich Klasse Andreas !!
Danke!
Interpreted languages "hide" all errors until runtime. Compiled langages detect many errors during compilation phase (not all of them of course). For a critical system interpreted languages will require much more testing.
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.
thanks for the nice overview. My question is can i run an normal pythonprogramm on my pc and use sesorvalues from the controller. is there an relayable way?
No, python will not take over microcontrollers.
Great introduction Andreas! I am addicted to python since an year, and I am looking forward to test circuit python!
I think you will like it.
uPython? Might as well be Java. In the current u-controller realm, memory and clock cycles are precious. I've worked in environments where HW resources were extremely limited. I've worked in real-time processing environments where everything HAD to be completed within a 50msec (20x/sec) window. C/C++ are NOT that "high level" of languages - they are close to assembly language for a purpose. (Remember, C was written to write the UNIX OS more than a few years ago.) It all depends on the task being implemented and the resource load on the HW and that is the key determiner of language, OS, and HW selection. I can see uses.
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.
Python is a favorite language of mine. I have used it for class platform scripting where I used to write programs to do initial setup of routers, network switches , etc.
Why not run an interpreter on an Arduino?......because its waste of recources. Arduino is elegant.
By that logic you shouldn't use Arduino functions and only use raw register access for everything
@@LuluTheCorgi hugely exaggarated maybe
Where is not interpretation? Even microprocessor interprets encoded instructions, to determine what to do. But we have to consider the volume of interpretation, because it is resource bound.
@@2zz98 no it's not. The Arduino read/write pin functions are just as slow as MicroPython
Saying python on Arduino is bad because of the performance loss is stupid when using cripplingly slow functions anyway
Arduino is alot of things.
Elegant or performance oriented aren't one of them
@@LuluTheCorgiThat's insane. You must be trolling.
Really good material. I am not sure about one question. What if I would upload Micropython firmware. Can I still compile and upload programs written in c/c++ via VSCode or ArduinoIDE or program normally with the firmware loaded in the flash memory? Should I clean the flash memory when I want to change the programming method?
It might be worth mentioning that both the SAMD bootloaders from Adafruit and Arduino (zero boards) are not easy to burn on a fresh chip. I've saved one reference where someone used a STlinkV2 to burn the bootloader, but if you actually try to follow that example, there is no pinout mentioned and several details are not explained. In the comments you will find several people that discovered this the hard way.
I looked into this around 2 months ago and haven't revisited it since. So maybe things have changed, but there were quite a few comments and blog posts about people having problems like this when I spent a few hours researching it.
As far as the ability to execute code in a serial terminal. One option for AVRs is Forth. While I haven't actually tried it myself, there is a small electronics channel called "0033mer" that has several uploads where he demonstrates Forth on various platforms. Most of the time he is not actually demonstrating Forth like a tutorial on it specifically. He usually uses it while demonstrating other simple things. From the little bit I've picked up here and there, Forth is one of the early computer programs from back in the days when the specs of a modern ARM SOC exceeded the performance of most University mainframe computers. So Forth is one of those tiny programs that can run on simple microcontrollers with plenty of room to spare.
I'm sure others know far more than myself here, but this is what I know on this subject, and the challenge that holds me back from trying SAMD hardware ;)
-Jake
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.
Brilliant work again! The Micropython/C++ was a question sitting in the background for me. I'll be watching the Video again, as I'm a Fortran77 generation person and take time to assimilate. Thank you for your time, hope to support your channel, definite Thumbs up from me :)
Beauty of C/C++ on Arduino is the ability to seamlessly descend into assembler and ISRs when needed. Can you perform 40,000 input and output samples/second on an 8 MHz $5 Arduino Uno clone with microPython ?
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 meant to say "Goodbye to C++"? Comparing Arduino IDE vs Python gives a bad taste in my mouth, as they are 2 completely different things :) Arduino IDE is not a programming language. In any case, you should definitely say goodbye to Arduino IDE. Absolutely no reason to use it now when PlatformIO is stable. Arduino IDE is a horrible IDE. It's almost like coding in Windows Notepad. No autocompletion or anything.
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.
when saving to the micro-controller with Mu can we not save the sketch to the PC as a backup ? Can we not verify the save? Did i misunderstand?
Wow!!! 😲 That looks like it is going to be really simple and straight forward unlike anything that Arduino has to offer, I cannot get my ESP8266’s & ESP32’s to work well with the Mac Arduino IDE… Thanks Andreas!!!
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.
I think - out of all of the technology presenters on youtube - which I have reviewed - having to do with micro devices such as the Rpi , Arduino etc - you are probably the most informed. And I suspect you have a knowledge about the internals of these devices - such as how to read/write directly to CPU registers - than other presenters on youtube. Thank you for this excellent review! Sincere thanks!!
Thank you for your kind words!
we find that makers run into the limitations of python very quickly. good to introduce your grandmother to arduino but too limiting for serious projects.
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 ruclips.net/video/hHec4qL00x0/видео.html
uPython looks pretty in case of proof of concept when you want to quickly check your program, without continuously rewriting code to MCU. But at the end in production implementation it will works as an operating system, that can give more potential problems, and ate MCU resources etc. It will be clever if be possible to develop and test in uPython and finally compile the whole program in legacy way, as a binary file, without interpreting inside MCU
It’s quite funny, at least, trying to force a high level language on a micro controller. It’s seems almost a marketing strategy in order to sell more uC to newbies, whom barely know what a voltage is.
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
Thank you for the video. I want to start making projects however the C++ programming was very complicated. I'm going to look into the Python programming in your examples that looks very straightforward. Hopefully I'll start making something and if I do I will share it with you
For me the big problem is ADAFRUIT. They do provide lots of support and libraries etc but I have had problems trying to get any of their code to run on non adafruit boards. They try to guilt you into buying hardware from them by telling you of all the development time and resources they have invested....(cue violins!). I feel their hardware is very overpriced. Life was so much easier back in the old days of Z80 assembler! Bob
My first micro was a TRS-80 and I did assembler on an 8085 for 18h a day. A complete nerd. But I lost a lot of time for simple things like a floating point division and waiting till the EEPROM was erased and programmed. I do not miss the tools of these times and enjoy what we have now. What I miss more is to get up in the morning without any pain ;-)
I hate the fact that Adafruit has forked Micropython instead of simply joining micropython and extending it. They are the Microsoft of uC and electronics now. Making overpriced proprietary solutions and taking Damien's hard work and using it for free!
I've got news for you: this is done intentionally and rightly so. The boards they are selling are for the purpose of learning. You aren't supposed to take their code and use it on different hardware. At that point is when you're supposed to start learning the actual code.
For non critical, and non commercial "Playthings" I'll agree with you. I use arduino daily in my job as the project manager of a large ioT project which has to deal with lot of legacy sensors and equipment. Implementing 4th Gen SCADA would be very difficult without these small devices to do things such as convert analog signals to BCD for older systems. Yes there are still a lot of controllers out there based on DOS and Turbo Pascal. Allowing companies to continue to deploy these systems, I can here you all laughing now, requires certain things to be built, such as serial scale heads talking to pc based systems which are still using parallel IO. The arduino IDE is not required but does a great job at what it was intended to do. Of course if you are as fluent in c/c++ as I am and know your programming environment well, you would be using the VS Code, arm cross compileer, JTAG interface, and BOSSA to get the job done. This Python stuff is just for those who want to throw hardware at every problem and are too lazy to actually learn a coding dicipline which has pretty much been invariant, works on thousands of platforms, and has standards. Having said that , how would you secure this type of environment in an industrial setting to protect from reverse engineering and intellectual property theft? Not that you could hide anything from me because I quite readily read the output from a c compiler as if it were english.
You remind me of one of my first paid project where I had to build an interface between an old, but expensive printer and the new computer. It was done in 8080 Assembler, of course...
Sorry, but Python is an interpreted language and is, by default, slower running than C/C++ which compiles into native code. I am sure I will trigger someone but facts are facts. C/C++ compiles down to machine language and Python is just slower.
btw, I froze the frame with the chart of languages and you know what I see? Ease of programming at the cost of shitty slow programs. Java is the worst at creating slow code and is considered a dismal failure by any sane, and rational, programmer.
I think you describe the conflict of speed of the machine vs. speed of development. This is a universal battle in all technology. Technological advances sometimes shift this conflict to higher levels.
Speed of execution is not always that critical. CPU and MCU have become faster and faster and it will continue.
I agree, plus it's more powerful to use C. I have no idea why people think C is harder to use and slower to develop for. Python is a pretty bad language too.
I'm a little bit in-between....
I've worked with python as a frontend language for some kind of game editor where most it did was configuring or using the lower-level C++ code.
That being said, python may be a nice high-level descriptive language, but the libraries it uses will still have to be C/C++, don't they?
You are right, but speed is not always most important thing.
You can always optimize your code, even in the Python ruclips.net/video/hHec4qL00x0/видео.html&t=1055
Python has it's place and I enjoy using it for cross platform work, but I think Arduino is perfect for the little microcontrollers. It's a simple language that supports smaller hardware projects well. Controller projects should not be solved by pushing more and more hardware at them so we can run interpreted languages. We should be getting closer to the hardware for efficiency. Yes, it is harder to do, but it is also the right thing to do in many instances where power supply and processing power are limited.
Adafruit seem to be a great company doing many things right, but I think their branching off into Microcontroller Python is the wrong thing to do.
Thank you for your feedback!
The idea of running python on a micro just blew my mind...
It's bad enough that we have crappy scripting languages running on PC, slowing them down and requiring 100x the processing power to do simple tasks that I used to have no problem doing on a Pentium 133. Now people want this crap on their micro-controllers?
XD well now you need an arm8 and 1 gig of ram to run your iot sensor XD
For me, the huge, huge advantage is that the sourcecode is right there on the device. Years later I can access it and change the python code with no hassle. Can you be sure that you've kept copies of all the libraries etc you need for the arduino sketch (and a compatible version of the Arduion app) ?
@@KSCPMark6742 years later i would put my uquantom cip in there or sell that chip for not so radiated water.
You already use readily available pre made Chips? How pathetic, real engineers design ASICs for everything!
But jokes aside, the key is productivity and maintabilty. Sure as an computer engineer I'm sometimes upset, because I was trained at carefully setting bits in registers in assembly and writing C-code for less critical stuff, but truth is, it's not required all the time and becomming obsolete.
These days where an ARM SoC costs below 1$ when you have the ressources (computing power, batter life ect), why not go for a script? Its cheaper, easier to do and maintain and it's even more secure. There is a reason PCs moved on from bare metal programming. The vast majority of that code was written by experts, who had years of training, and if you look in any security/exploit database, even then they made tons of mistakes. Nowadays an interessted high school kid can do the same stuff within minutes. Its less efficient, but they can use their brain power towards more important problems that haven't been solved thousand times before, and I think thats a good thing.
Well, personally I love coding these MCUs in uPy , coding time is 1/20 compared to C.
Now bussiness in wrong boat.
Wow.... its great job . Thanks again sir.
if the chinese clone it , i will buy it xD
To wait a month and no free replacement if it's DOA? No thanks, not for something under $20! Now Triangle Labs 3d printing stuff, that's chinesium worthy of buying.
Can I use esp32 for production purpose
I think in a few years BASIC will come back big, because it's much more convinient and intuitive than Python or any other programming language. And if we already sacrifice flexibility and performance for having easier programming, then why not go the full way?
@Andreas Spiess, do you do testing? can you share your unit test setup?
After all these comments I plan to do a video with MicroPython on ESP32 and test the different aspects which were mentioned. Then we know probably more... But this will take some time...
@@AndreasSpiess i see a few discussion on something called forth, maybe worth some investigation efforts? then there are other platforms, maybe not very popular www.esp8266basic.com/ then there is a hackaday post, hackaday.com/2016/10/27/basic-interpreter-hidden-in-esp32-silicon/ and then, there was lua interpreter and so many others, i think most of them will have functionality for basic tasks, problems may arise for advanced or as my professor used to say, for the "boundary" conditions and measuring that using a tool like jack ganssle did ruclips.net/video/f8KGatsPTNo/видео.html
but looking at the comments below, it looks like a lot of people are looking for alternatives to the arduino, interpreter is highly sought but compiler is also must. this probably implies, such tools still do not exist because nobody made them on account of complexity and work involved. but no one can complain because these tools are "free"
@jk44 One interpreter language on this channel seems to be enough ;-)
@@AndreasSpiess so i come to conclusion that religion as in this video 0:56 is a matter of "interpretation". we do not follow the principle of supply and demand but we think from hour hearts.
but being humans, get carried away sometimes...but that makes the world complex and interesting, ruclips.net/video/m55HKChS2zk/видео.html please pardon me for ignorance. it is only a light-hearted joke in the spirit of this video...
While I like new micro controllers, I have yet to have a project I couldn’t complete with some arduino. I agree this micropython saves development time but if I need the extra power, I’ll use a raspberry pi zero which only costs around $15
Thank you for your feedback!
Then you must not be doing deterministic real-time. The Parallax Propeller has 8 CPUs, running in parallel....no need for interrupt nonsense. They have just received engineering samples of "P2"....exciting times ahead. :)
Craig Webster can that not be done with a raspberry pi?
I worked with both and both has its own place. Additionally to mentioned remarks in this video:
Python/Micropython - Python is main programming language in Raspberry. For raspberry you have comparable community as Arduino.
There is also Zerynth project in mature state, where you can mix python and C language in one solution.
One of the reasons for this video was that I have to learn Python on RPI because I want to try Machine Learning and Vision
When I develop embedded applications I do NOT want multiple layers of software between my application and the hardware. If there are bugs, I want them to be MY bugs. That way, I can do something about it. I'm using the ATMEGA328P (Arduino) in money making commercial applications. I need to be able to rely on the software. That's why C and C++ will be here for a long time yet. It probably IS time to move away from the ATMEGA family. You can buy a 32 bit ARM M0 for a lot less money. But use a 'black box' language to develop my applications? No thanks.
Thank you for your opinion. If you browse through the comments you are not alone ;-)
Where's the black box? MicroPython is written in C, you can debug the code. :) Admittedly it is adding a layer but that layer allows you to develop faster with less code.
ARM Cortex M series are great microcontrollers. :) NXP got some nice stuff. I think PIC and AVR are both also heading those ways. CPU architecture is standardizing towards ARM currently. Even Microcontrollers now. Was a fun time back in the day with AVR and PIC though. Even more amazing is that currently with the Architecture standardizing Rust language cane easily become popular. It's an Amazing compiler and generates Safe code with no leaks.
Yes. Let's not write in C but debug MicroPython in C when it breaks.
I just want to praise your work. Thank you for it.
00:59 ha ha ... nice picture explanation