Embedded - 456: Left Right Symmetry of a Banana

Episode Date: August 3, 2023

Damien George spoke with us about developing with and for MicroPython while Elecia tries not to spill all the secrets about her client. To start at the beginning, you probably want to check out micropython.org. Wait, no, one step back. Before listening to the show, you probably should read the Wikipedia MicroPython entry because we kind of start in the middle in the show. You can find the code on github: github.com/micropython/micropython. The PyBoard can be found on store.micropython.org. It is out of stock but lead time trends show parts may be available soon(ish). For more about branes, Lie point symmetries  and other physics fun stuff, check out Damien’s list of papers on dpgeorge.net. Transcript

Welcome to Embedded. I am Alicia White, alongside Christopher White. We've mentioned CircuitPython, using it as a user. Let's talk about MicroPython as a developer. Our guest this week is Damian George, creator of MicroPython. Hi, Damian. Thanks for joining us. Hi. Hi, Alicia. Hi, Chris. Thanks for having me. Could you tell us about yourself as if we met on a Discord about MicroPython?

Sure. So I started my career with sort of formal training as a scientist, a physicist, and also a computer engineer. And stayed in physics for about 10 years, doing a PhD and a couple of postdocs. And that was really fun. I was learning about the world and doing research. And then towards sort of the end of that, as in the second postdoc,

I created MicroPython and got sidetracked by that. And then that turned into my full-time job. And so now I work exclusively developing and maintaining and improving MicroPython and everything around it. And yeah, I like to think that I approach that from sort of an academic and scientific point of view, as well as engineer. So it's a bit of both and hopefully a good mix. And yeah, also a father of two boys and yeah so basically my life is either being a dad or developing my cupid and we have plenty of questions to ask you about that but first

we want to do lightning round where we ask you short questions and we want short answers although that first question looks a little hard. And if we're behaving ourselves, we won't ask more about the brains. Are you ready? Yes. In 30 seconds or less, explain the method of Lie Point Symmetries. Of Lie Point Symmetries? See, you've already got me.

Lie Point Sy symmetries. This is going back a while, but you've got to first understand about leaf groups to understand about leaf symmetries. And this is a really hard question to answer. You can pass. You can to answer. You can pass. You can definitely pass. You should pass. It's mostly a prank. But yeah, leafoid symmetries they allow you to find continuous

symmetries of a group and of a physical system and a model and symmetries lead to conservation laws have a physical system and a model. And symmetries lead to conservation laws. So that's the most important thing in the world. So once you know a symmetry, like a left-right symmetry of a banana or something, there's a conservation law with that. In the bananas case, I don't really think it has one.

The conservation law of the, sorry, the symmetry of translation. So if I move sort of left or right, I'm still the same person. And that's a symmetry and it's called translation symmetry. And it's a continuous symmetry because it's, it's not discreet. Like I could move an arbitrarily small or large amount to the left or right. And the conservation law associated with symmetry is momentum okay momentum is conserved uh so this is a really fundamental part of physics is uh conservation laws and symmetry

so the symmetry of time is the conservation of energy so now and in one second like the laws of physics are the same and that means energy is conserved. So they're the two sort of fundamental ones. Conservation of, sorry, symmetry in position and times, conservation of momentum and energy. But there are lots of other ones, like conservation of charge in electronic circuits has to do with group symmetries of the internal properties

of electrons. So you can understand lots of physics by studying symmetries. Didn't that mathematician I don't like do all of the group stuff? Galois? Yes, Galois. There's Galois groups. There's a lot of people. Group theory is big.

Yeah. But Lee did a lot of work on it. Do you think the Large Hadron Collider will someday create a tiny black hole that will eat the world? People did think this seriously before it turned on. The work I did sort of was a bit related to that because, yeah, I mean, it could have been that we collided two particles so close and it created a mini black hole. It would have evaporated very quickly due to Hawking radiation, or at least that's what some calculations show. But it was a small possibility of something like that happening. Although most people point out that if that's possible, it would have happened in the sun

every day because the sun is colliding particles with very high energy. So we were pretty safe. And now I'm going to stare at the sun and worry all day long. Only until your eyes burn out. Then you'll be fine. Black holes in my eyes. Yeah, exactly. What is your favorite microcontroller?

Favorite microcontroller? I guess I'd have to say STM part because I'm just so familiar with them. And they're actually pretty good. I would have to say STM32F405 because that was the one on the original Pyboard. And I have a long history with using that microcontroller. Do you prefer printf debugging or step through with a programmer like JTAG? 100% printf debugging. Which has your preferred summer weather,

Melbourne or London? Melbourne. Do you have a favorite fictional robot? Giscard from Isaac Asimov. And if you could teach a college course, what would you want to teach? I teach physics, theoretical physics.

All right. Well, all the things related to that, like electromagnetism and the metanomics and quantum field theory and general relativity and all those really interesting subjects. Also very hard to teach. But I have taught them at college level in tutorials and things. You mentioned having a postdoc and you worked... Lightning round is over.

Yeah, sorry. And you worked on the Large Hadron Collider and some, you've got a lot of papers. Not as many as you probably should have, but it's a pretty cutthroat industry, academia. And then the pie board came out on Kickstarter. And your papers, they don't... Did I miss recent papers? No. It's totally unrelated.

I guess there is no link except me between the papers that I wrote and then MicroPython. As I mentioned before, in university, I did a science engineering degree. So I studied maths, theoretical math, like topology and things like this, and then physics, theoretical physics, and also engineering, computer engineering. So I did a bit of microcontroller stuff, operating systems, networks, that kind of thing. A little bit of software engineering.

I definitely do not call myself a software engineer. So I have a computer engineering degree and a science degree with a PhD in theoretical physics. And they're sort of two separate things, of course. And I continued with the physics because it was really interesting. And on the side, I always played with robotics and programming and microcontrollers. And so my formal activities during the day

would be theoretical physics, and my hobby activities at night, they're not necessarily split day and night, but my hobby activities would be computers and microcontrollers. And they go together pretty well because experimental physicists, which I was closely working with, who built the LHC and the experiments there and other experiments, they use microcontrollers all the time and program firmware um to detect light and and and other things um you know so the the large electron collider and the atlas detector

which i i worked with people who are on that they have huge numbers of detectors and microcontrollers and and petabytes of data coming in like every second and they have to put filters and cuts on the data and then to narrow it down to the interesting events and then store that somehow. And it was a huge computing and engineering effort to make that thing work. And in the past, you know, early physics, a hundred years ago,

physicists were not really a theoretical or experimental. They were just sort of engineers slash scientists who would try and discover something interesting and do a lot of work with their hands to build an apparatus by hand because it's the the era of physics we're in requires hundreds if not thousands of people to work together on one experiment and so you split your job between the theorists which is what i was doing and the experimentalists who built and run the the apparatus so yeah i guess what i'm saying is that being an engineer and being a physicist, they're not totally disjoint. And there was always room for doing both together. So MicroPython was sort of born out of my side projects to play with microcontrollers and programming languages. I always really liked implementing programming languages.

And I had previously implemented a few scripting language or virtual machines on very small AVRs and nothing that was ever sort of public. But MicroPython was sort of, given all the things I'd done, a natural step, I guess. So that's, yeah, that's how it sort of came to be. Does that mean your job now is your hobby, what your hobby was? That is correct, yes. My job now is what my hobby used to be. It was always a fallback to go to sort of computer engineering

if being a theoretical physicist didn't work out. And being in academia is quite hard. There are not many jobs around the world for the sort of things like investigating extra dimensions and inflation and those sorts of things. So I felt that I was better and, yeah, sort of enjoyed more the hands-on computing, microcontroller, building things.

But I still keep up to date with physics, read some papers and try and see where the field's going. So talking about MicroPython, I started working with MicroPython specifically for a client who has a complicated robotic-ish system with chemicals and pumps and moving arms. And their scientists know what needs to happen, but not necessarily in what order or how much reagents need to go in at each step. So they wanted to be able to script the device until they get ready to finalize it. Then they want to script it in the lab for months. And talking to their scientists and how many applications they have, I suspect there will always be scripting.

And so Python scripting works really well. What should I have known to start with? Maybe that that's a very good use case. And there's a project that I was part of that was almost exactly that, developing some workflow using scripting. I think that, yeah, that there are people out there to help you,

like me, if you were stuck, because that's, I think, a really good, as I said, a good use of MicroPython in an embedded system. So definitely, there are people out there who could have helped you bring it up if it was any difficulty. You did, actually. Since I ended up with a board that wasn't quite the same as the boards I already supported, I squawked on the Discord and I think it was only a couple hours later you'd gotten it

for me. It was fantastic. Yeah. Yes. But yes, I didn't know the application though. But it was, yeah, it's always good to help people bring stuff up. I think, yeah, I guess it's a bit of an open-ended question. What you should have known. But I can ask more specific questions.

Yes, please. Narrow it down a bit. I can make modules in C, and I've done that to control some of the motors that have timing requirements. But how do I decide what things to write in C versus Python? Yeah, that is a good question. And the usual thing I do first is write something in Python.

And then if it's too slow or not deterministic enough, it can go into C. But you usually find that Python is pretty good for most things uh like for example i developed the wi-fi driver for the pyboard in python like it was a pure software spi interface bit banged um and then the entire stack all the way up to being able to send a ping from the Wi-Fi was all in pure Python. And it was fine. And then I converted it to C just based on the Python. And it was so much faster developing in the Python because, as you can imagine, interfacing to a Wi-Fi chip is not easy and getting everything correct. But that was translated to C for efficiency purposes,

because the Wi-Fi driver has to run on an interrupt and be rather low latency and high throughput, because sometimes you have a lot of data going over Wi-Fi. Another case I had, reading an ADC very, very quickly and storing it into RAM. Easy to develop in Python. It's only a couple of lines, essentially, because you're just reading from a spy device and putting into memory but then eventually that had to go on a very very low level low very high priority interrupt

and that was basically timing to get it very accurate adc sampling and that that went into C. So that's my general suggestion is to write it in Python first to get it working. And then if you see or if you feel that efficiency is important, put it into C. And that's why my motors are in C because there are timers and counters and encoders and all the things that need to work together. Yes.

Did you prototype it in Python first? I did some. Because I was on an odd board, my pin mappings have never been as good as they should have been. Right. And so I should go back and do that and fix it. But instead I was like, but I know how to do this in C in fact the client provided a lot of code to do

some of the basic movements in C and so I just skipped to that Yeah, if you already have a driver in C, just use that Do you usually recommend people make lots of modules for like each part of their system or one module to rule them all? You mean when structuring a Python program? Yeah.

So I would recommend splitting it up. Personally, my coding style is to do more monolithic things rather than component-oriented, but it is always good to break things up into logical components. And in Python, I mean, there's not much overhead, really, to having things as separate components. Things are so object-oriented and like duck typing and very dynamic that it's best to keep them well separated

into separate files for the different parts. So you could have a 10-line driver for an LED which just turns it on and off. But that's useful sometimes because maybe you want to intercept it or mock it out for testing or whatever. So even abstracting an LED to a little driver is useful. So I would recommend splitting things up.

I have a question as producer of the show. What's MicroPython? Because we jumped into, you know. But I have a lot more questions to get through. I mean, I want to talk about the boot process. Well, it's up to you. We can discuss how it all works first. And then our listeners can have a summation at the end where it's described what it is. Or we could quickly introduce people to MicroPython.

They can read the Wikipedia. So Python is a a language a programming language which is used on desktops and it's a very dynamic language and you really you wouldn't think it would be suitable for microcontrollers so i guess what micropython is is is making python work on a microcontroller in a way that is efficient and actually useful in embedded situations. And so a lot of work has gone into making it work, making it small and fast in a microcontroller setting.

And so using MicroPython on a microcontroller, there are other places it can be used like on the web, but specifically on a microcontroller, there are other places it can be used, like on the web, but specifically on a microcontroller. It's designed to give you very much a Python feeling in an embedded system. So you can get a prompt, a REPL, you can type in commands right in the microcontroller over a UART, for example,

and turn a pin on and off and get immediate response. And then you can write programs in Python slash MicroPython and make them run on the microcontroller and build a whole application. So yeah, MicroPython is two words, micro and Python. And you can think of the micro being small but also being microcontroller but the general philosophy is that it's it's trying to make python work well in a microcontroller but people shouldn't expect to like take their giant python script that has numpy imported and

scipy and opencv and scipy and drop it onto a Cortex M0. No, although there is ULAB, which is a NumPy sort of replacement for MicroPy. Oh, cool. Which is becoming quite popular. That's not maintained by us, but it's definitely, yeah, we recommend to use it if you need NumPy sort of operations. But it is getting there.

We would be able to hopefully do machine learning and things like this eventually because the microcontrollers are getting bigger. But yeah, you can't expect us to run any arbitrary large Python program. You really write things from the ground up with MicroPython. Maybe being able to pull in some libraries here and there from normal Python. How come the logger library from Python isn't supported?

It is. It is? It wasn't in my list. It's been around for a while. It's been updated recently. You can install it from MicroPython Lib. It's there. Oh, okay. Never mind. I must have just not read that part.

Whoops. I have one follow-up question, and then we can go back to the train that Alicia was on. How is or is MicroPython different from CircuitPython? Yes. So CircuitPython is, I guess you can call it a fork of MicroPython because it took MicroPython at one stage and branched it. So that's what a fork is.

And it has merged back MicroPython changes since it fall. And CircuitPython's sort of main theme is to, I think, be angled towards beginners more than MicroPython. You can think of it like Linux and Linux distribution. So Linux is the kernel. Well, there is the Linux kernel. And then you have Linux distributions like Arch Linux and Linux distributions. So Linux is the kernel. Well, there is the Linux kernel, and then you have Linux distributions like Arch Linux and Ubuntu.

And Arch Linux is sort of more for power users and Ubuntu is more for people who want a graphical desktop that's easy to use. I mean, that's really a big simplification, but there are different flavors of Linux. And in this case, you can think of MicroPython as having different flavors intended for different target audiences. So MicroPython has the main MicroPython flavor,

which is the one that we maintain. And then CircuitPython is MicroPython core plus the CircuitPython flavor of how to do libraries. So the real difference is in the libraries, the display IO and synth IO and bus IO and the way that CircuitPython give you access to the hardware and then also sort of their user workflow

of how you get code onto the device and how it runs and what the boot process is and the supervisor they have to manage the board and manage Wi-Fi or Bluetooth connections. And then also they integrate tightly with Adafruit hardware because it's obviously sponsored, the development is sponsored by Adafruit. So they're very particular in making Adafruit hardware work well and out of the box with CircuitPython

and for CircuitPython to be pre-installed on Adafruit development boards. So I guess, yeah, those are the main things. The way you interact with the hardware, the libraries, and the tight integration with Adafruit hardware. And then focusing more on beginners and tutorials to make a really good onboarding experience. Whereas MicroPython, on the other hand,

is more about the power user who wants to get more out of the microcontroller. So we support interrupts, running Python on interrupts, and we support asyncio, and CircuitPython is introducing asyncio now, but we've had that for a while. And we support, I guess, a more in-depth hardware support on STM and some other microcontrollers and ESP32. We don't require USB like CircuitPython did in the early days. And yeah, we do have a lot of industrial users who use MicroPython,

and we try and support them and maintain a very performant core. We're concerned a lot about performance and code size and making sure things work well in an embedded environment. Whereas CircuitPython are more about making it work well for the beginner and having a good experience for them. So it's, yeah, a different flavor of doing Python on a microcontroller. What percentage or what kind of feel do you get for the people who use

MicroPython without modifying it and the people who develop for it? Are there words? I mean, user and developer, I develop with it, but I have not developed for it. What is, do you have terms? It's, yeah. So there's a lot of people who will use MicroPython out of the box. The firmware you can download from the website

and put it on a microcontroller and then write some Python code. We encourage that because a lot of people, it's too hard to compile firmware these days. You need so much setup. And so that's a benefit of MicroPython is that you just download firmware and then write some Python code in a text file. And there are lots of, I guess,

you could call them users like that. And they want to install libraries, which you can do if they're Python libraries, but sometimes they want to install libraries like ULab slash NumPy. And that's a bit harder because you have to recompile. And then I guess they become a developer because they want to configure MicroPython at a more low level, at the C level, and then rebuild it, and then flash it onto the device. And usually that's not too hard. There are lots of guides about how to build firmware. So once you've got over that hump, you can then configure C modules yourself.

And then there are people who go further than that, like, well, I need this extra feature because it's missing and they've got to implement it. And if people have the ability to do that, they go and do that. And there's a whole scale there of people who just want some small feature. And then there's people who want

to add some missing Python thing, like order dictionaries, for example. And then there are people who are really deeply embedding it within a product as a scripting language, and they do all manner of things. Usually we don't hear from those people right at the far end of integrating MicroPython because they're highly skilled and don't really need to ask questions.

And usually they contribute back things that they think are useful for the wider user base of MicroPython. They're like, oh, we've been doing this thing and we found that it was better this way. And so here's a patch to make it work for everyone. Or they contribute a new feature that was missing, like a lot of dictionaries or something like that. So there really is a big scale. It's not like a black and white user slash developer. It's

user from just doing Python scripts all the way to a person who is modifying things, improving the garbage collector to make it faster or something like that. The whole project is under MIT license, which is one of the, you can pretty much do whatever you want as long as you don't sue me licenses. It's very liberal, and it makes it easy for me to convince folks I work for to use it. But why did you choose MIT license?

That goes back to the very early days of the Kickstarter. It didn't have a license. I didn't release the code and I hadn't put a license on it. So it was not even out there. But we were discussing what license to have with sort of some of the backers of the original project. So that was over 10 years ago, and it was basically a choice between MIT and GPL,

and I wasn't that sort of up to date with or into knowing the details of licensing and open source software. But there were... Because those are two very different licenses. Indeed. Indeed they are. And there were very vocal people on both sides of the fence to begin with, saying, you know, both of them basically religions. So there were people on both sides and the MIT license won because it was simpler and I usually prefer simpler things. And I guess that's the answer, that it's simpler. And I think it was the answer that it's simpler and i think it was almost luck that it was the right decision in hindsight and after learning a lot more about licensing

because we are very strict about licensing now um and making sure things interoperate with the mit license and keeping gpl away from the code base. But it was at one point there, it could have been GPL, which would have really changed things a lot. Although Linux to GPL, it really has a much different story.

I think with embedded, you just sometimes have no option if it's GPL. You just can't use it because you've got to embed your code and you're not allowed to no option if it's GPL. You just can't use it because you've got to embed your code and you're not allowed to release anything because it's secret how it works. So, yeah, it was a decision, a very conscious decision, and there were input from a few people in the beginning to go with MIT.

You mentioned the Kickstarter. This was a Kickstarter more than a decade ago to create the Pi board. Yes. What is the Pi board and why did you do a Kickstarter? So at the time, which was about 10 years ago, 2013, at that time, Kickstarter was a big thing. It wasn't brand new, but it was relatively new

and some things were getting millions of dollars and it was really interesting. And there was Pebble around that time. The Pebble Kickstarter with the smartwatch. And there were a lot of Arduino-based Kickstarters which were like putting an AVR or something in a different form factor or making an add-on for Arduino or making sort of a new way of programming it.

Like one of them was the Arduino looked like a mass storage device when you plugged it in and you copied your file and that flashed it onto it, which was cool. And we took that idea from MicroPipe. But there were all these very same simple Kickstarters that were getting like hundreds of thousands of dollars for a simple idea. And it was, I was like, surely people want a more interesting thing

rather than just a little Arduino add-on. And so MicroPython was designed to be a Kickstarter in the sense that I thought, I can do better than what's there in terms of the Kickstarters that were there, you know, and then maybe it can be a success as well. And I thought, what is, you know, what's my skill set and, you know, interest microcontrollers

and programming languages? And I'm like, what is a, you know, a popular language that you can't run on a microcontroller yet? And Python was sort of the obvious thing because JavaScript was already there with Esperino from the very early days. And Esperino itself had done a Kickstarter and done very well. And Python was sort of the next language on the list of popular languages that were not on a microcontroller. And so that was the idea to get Python working on a microcontroller and make a Kickstarter.

And the Pyboard was the piece of hardware that the backers got as a reward. Because when you're doing a Kickstarter, if you did a pure software Kickstarter, it's a bit boring because people want something, want something physical. And all these popular Kickstarters that were doing well, the reward was a piece of hardware, something physical that you could use. And so the idea was to come up with something relatively cheap. So this was in the UK, and I think it was £ pounds or something close to that for the py board um so

if you backed it for that uh at that level you got a py board and it would run micropython and that was the offering and so the you know the price point was designed to be relatively easy cheap for people and and the idea was supposed to be simple, that you had a small electronics development board that when you plugged it in to your USB port, you had a serial port that you could type Python commands in and then also a mass storage. It appeared as a mass storage device that you could copy scripts to and they would run when you unplugged it.

And that was really the scope of the project, that you'd just write main.py, and it would blink some lights and turn some servos, and it would be a self-contained thing. There would be no compilation required. There'd be no installation required for anything. So people on Windows or Mac or Linux didn't need to install a single thing

because you have a text editor already already and you can copy mass storage files to a mass storage USB device. So it was supposed to be a zero install way of writing microcontroller code or code that can run on a microcontroller. And then it was about six months from the idea to actually making the kickstarter go live as part of that had to get a proof of concept working where you could blink lights on an actual board which was the sort of prototype pie board and get quotes from manufacturers to make you know a few thousand of them so I could get the pricing correct.

And then sort of once all those boxes were ticked, prototype and, you know, pricing and, you know, viability, then the Kickstarter went live, made a video, sort of copied what everyone else did, you know, in the sense that you, the videos is, um, yeah, describing the thing and making it exciting and your product pay or the page explaining what it is, trying to explain how you do it and what the risks were. And Kickstarter back then was pretty open and, um,

things got through easily and people were trusting and projects usually got delivered. And it was a pretty fast ride. It was like got 100,000 pounds in 30 days and then I had to deliver. And I think it was about six months or maybe five months to shipping out the first pie boards from the close of the Kickstarter, which I think is pretty good in hindsight, getting things manufactured.

And we did a run of 3,000 pie boards to start with. So that was like, we had enough money for that. And that was how many we needed. We needed, I think, about 2,200, but we made 3,000 because it was around number, based on the number of microcontrollers or could or stm32 f405 so you could buy in trays and um yeah so built 3,000 shipped them all out and then started selling them post the kickstarter and then the money we got from that we we built another 3,000. So really Kickstarter was a perfect name for what happened is that you kickstarted it because I could not have funded,

you know, development of 3,000 pie boards to begin with. But Kickstarter did do that with people backing it and putting up money front and, you know, believing in the idea, trusting that I could deliver. Delivering and then using the, you know, believing in the idea, trusting that I could deliver. Delivering and then using the, you know, further proceeds from selling more Pyboards to make the next run and so on and so on. And it just ramped up from there.

So from the beginning, I think MicroPython has always been a combination of hardware and software. The Pyboard has allowed MicroPython to be funded. And the Pyboard runs the software, MicroPython. And I don't think you can ever split those two things up, the hardware and the software. MicroPython from day one has always been a funded project, as in has had a source of revenue.

And it's always had a tie into sort of reality or something physical or some kind of you know project or people actually using it in the real world um and i think yeah that's kind of mirrors my experience in physics in that uh when you do theoretical physics there's a lot of theory theorizing and thinking up crazy ideas about black holes and extra dimensions. But it's always rooted in reality because you've got experiments. And if your theories don't match the experiments, then you go throw away your theory and you start again. Or you tweak it. And so in MicroPython, the hardware always directs us.

If it's not for the hardware, then MicroPython is not there. And the hardware is sort of, you know, without MicroPython, it's not interesting. Without the software, it's nothing. So I try and keep that balance of hardware and software. Although these days, MicroPython can run in the browser, so it can be a pure software thing and other things, but we're always trying to keep on to our roots of connection to microcontrollers. Do you still sell the Pyboard?

Yes, except with the global chip shortage, we had to stop production because there were just no microcontrollers. Especially STM32F series was just impossible to get because I assume all the auto manufacturers took them. And we have

started reproduction of Pipeboard again and we're designing some replacements that use new microcontrollers. production of Pipeboard again. And we're designing some replacements that use new microcontrollers or new STM parts and other parts as well. So we will, there are none available at the moment,

at least to the general public on the web store, but there will be hopefully by the end of this year. When you started the Kickstarterstarter project before it funded could you have imagined still working on the project 10 years later um yes and no uh i guess i could imagine it being a success. And I can imagine it being something I did full time. But I don't think I would have thought that that was the probable path. I didn't really go into the Kickstarter with a plan for it to be long term.

Or for what would happen after the Kickstarter. I was just focused on doing the Kickstarter, making it work, being successful, and then seeing what happened if it was successful. So I really didn't have a long-term plan for it. Just wanted to follow my nose, follow the lead of what users and people have sort of shown that they want and need. But at the same time, not just do what people want, but do something that I find interesting, which I still do. I still find it very interesting

all the technical details of reading 3,000 pages of a microcontroller data sheet and then digesting that and then making MicroPython work really well on such a microcontroller. We had a question from a listener, Maddy C., who asked about MicroPython being used in a web browser. And you've mentioned web browsers. I thought this was a hardware thing. Yes. Yes. So MicroPython is, as I said, definitely microcontroller, Python, those two things combined.

But it turns out that the wider scope is minimal Python interpreter and minimal Python interpreter that's still Python has a lot more uses than just a microcontroller. Some embedded projects have a little Linux machine like you know single board computer running Linux because it needs to do you know more than a microcontroller can and sometimes you want to run Python on that embedded Linux system and MicroPython is a good choice there because it uses very little RAM and it's really fast. So you can use MicroPython as a Python replacement on an embedded Linux computer to do scripting.

And I know of industrial users that do that. Python can be embedded into games, for example, like with MicroPython to script a game or in some scientific apparatus where it's controlled by a big computer, but then you want to actually script this scientific apparatus so you can use Python inside the software there. So that's sort of all pure software as well.

And then on the web browser, these days with WebAssembly, you can compile C code to WebAssembly, and then that runs in the browser. So you can compile pretty much anything and run it in the browser, and you can compile normal Python. But because it's so big, it takes many seconds for the browser to download it and load it up, which is really annoying if you're making a responsive web page. Whereas MicroPython is like 10 times smaller and therefore 10 times

faster than normal Python to load in the browser. And so it becomes a really good candidate for a Python implementation in the browser if you want to be able to write your client-side web logic in Python. So instead of using JavaScript to write your, you know, on button click, do this, you can write Python, on button click, you know, do this, however you would in Python. So that's the idea with PyScript, which is a new sort of framework for running scripting languages in a browser, not just Python, but other ones. And MicroPython and CPython

via the PyDot implementation are both sort of backend implementations of Python in the browser. So MicroPython, because it's so small and efficient, it's useful in more than just the realm of microcontrollers. Web development is radically different in their philosophies and development styles from embedded development.

Has the web development world influenced the MicroPython path? It's pretty new, web development, and MicroPython in PyScript, for example, is very new. It has already done a little bit of influence because the focus in PyScript, for example, is more Python compatibility. It really wants to be as Python as possible. And so you freeze in all of the libraries that you've got

to provide us logging, for example, and date time and all those things. And you enable all the optional features so that people have what they expect to be a Python environment. It also needs sort of a different memory management. On a microcontroller, you have a fixed amount of memory and a fixed heap size, say 100, 200K.

But on a web browser, you've got essentially unlimited memory. So you need to have an expanding heap, which we can implement as well. So it's, you know, sort. So it's very similar, but there are a few tweaks you can do here and there to make it suit the browser more. Another question came from Scott, which is usually my question.

How is MicroPython development funded? You mentioned the PyBoard, but you haven't had those in stock. Yeah. Okay, so there are I think three main sources of funding is sponsorship on GitHub, which has been the past couple of years has been really good. Really, really appreciate all the people who sponsor MicroPython.

Even if it's a dollar a month, it all adds up. And that goes towards paying maintainers to keep sort of GitHub running, deal with issues, pull requests and features that people want. So that's sort of funding source number one. Number two is hardware sales. So original Pyboard, Pyboard D series, and a few of the accessories we had.

And that provided quite a good source of revenue before the chip shortage. During the chip shortage, we still had a bit of stock, which we sold to existing customers who desperately needed them. We did also have some stock of some microcontrollers, which we then built more boards with. So we kept going a little bit, although even the online store sort of had nothing, but we did have a bit of stock.

And in the future, we will have hopefully more hardware as well. So hardware is number two. And number three is additional consulting and contracting that I and other maintainers do for people who want MicroPython in some fashion, either enhanced or adapted to their systems or features added or whatever, the work is all MicroPython-based

in the sense that there's no embedded consulting services that are not MicroPython. Everything is related to MicroPython and in one way or another feeds back into the development not MicroPython. Everything has related to MicroPython and in one way or another feeds back into the development of MicroPython because I can spend my time doing it. But there are lots of cases

there like European Space Agency getting, improving MicroPython to run in space applications as sort of scripting satellites, for example, in education,

in Lego Mindstorm products, in other educational products, and then in industrial use, which usually, well, those projects are always sort of kept private to the client, but sometimes there are improvements to MicroPython that can come through domain line.

So yeah, consulting is the third. So sponsorship, hardware, and consulting are the three sources of revenue. And yeah, everything we do and all the people who are working on MicroPython sort of, well, not voluntarily, but the maintainers of MicroPython are all paid people. And it's always been paid since day one and funded.

And I think that's really important to keep a project going. And I'm really proud that we can do that, that it is funded well enough that it can keep going. And it's not just relying on volunteers. Although there are a lot of people on GitHub who donate their time and we're very grateful for that, for their contributions, who are not paid by sort of George Robotics.

But some of them I know are paid by their company and then they have a bit of time to contribute to MicroPython, which is amazing. But then there are other people who are hobbyists and just enjoy it and contribute, which is also great. When you do what you love, then the work shows. So it's really great. So I think we have a great community of people who contribute.

And it's, as I said, really great that we can be funded to keep doing what we love. And you currently implement Python 3.4? So Python 3.4 was the version of Python that was out when I started MicroPython. And so that was the one I tried to match in the beginning in terms of syntax features. And since then, Python mainline, CPython, has advanced quite a lot to 3.11.

And they've added a lot of stuff, a lot of syntax features, like, for example, underscores in numeric literals, which I love. And we've tried to keep up with most of the syntax changes, although we haven't done them all. But then there are other things like library changes and semantics of built-in objects or methods. And we've sort of stuck at 3.4 as the base reference version, but we've definitely added a lot of things from later versions,

like from hex, for example, to convert hex to bytes, just as one example. And we actually have in the documentation a sort of feature matrix of things that were added in later CPython versions and whether or not MicroPython has done that or will do that. So, yeah, it's sort of 3.4 at least, but then a lot of other features.

And I guess one day we'll bump to 3.5 and 3.6, hopefully, once we can confident that we've got most of the features from that version as you as you've mentioned there's circuit python and and micropython and those are definitely two different flavors do you think there are potential problems with the splitting of the different flavors? Do you think they're going to diverge? Maybe not just those two, but in general? I think there really is just those two. And I don't, well,

CircuitPython can retain our core and merge back the core sort of interpreter and virtual machine into their fork. And that's great because it means we're the same there. And as I mentioned before, it's the libraries that we offer that are different. And that has led to, well, I guess issues for users in that they would love for a library from CircuitPython to run on MicroPython or vice versa. And there are adaptation layers to make that work, but they're not as seamless as you would like. I think ultimately it would be great if all the drivers from either side

work flawlessly on either variant or either flavor. And hopefully we'll get there. But yeah, I think it's more from the user's point of view. They just want to work with Python on a microcontroller and have a driver for their graphics,

for their display or for their accelerometer or whatever. And they want to have a good time and build a cool device. And I think you're making drivers work is sort of the biggest bit of that to make sure it doesn't fracture so much. You know, you have Camp A a and camp b and they both have completely independent drivers so you've got to choose from the beginning which one you want to sit in um i don't think that's useful for people we've been making you do all the talking but you

mentioned you had a question or two for us yeah so well i was wondering you know i guess talked about micro python and funding and sort of consulting versus, well, open source development. I'm wondering for yourselves, how do you split your time between the podcast and the embedded engineering that you do? 95% engineering, 5% podcast. Podcast is a hobby, definitely.

Yeah. I mean, I wouldn't mind if the podcast took more time, but also we'd need to be compensated more for it, which is the challenge. Right. Because I can imagine it takes a lot of effort to produce a podcast. So 5% seems really low. Well, okay. That's probably flip. It might be more like 10 or 15%.

I think I calculated it was about 8 to 10 hours per week combined. All right, so maybe up to, yeah. So, yeah, that's a day, two of us combined, days worth of work probably. And now we're doing them every other week, so it's not quite as much, the percentage. But we haven't been very good about monetizing. I mean, our Patreon group is fantastic and we appreciate them very much. We also spend all that money on the podcast. It is not a revenue source.

But, I mean, I believe Christopher will be posting soon that he needs a short gig. So there's always the possibility that it can serve its initial purpose, I get to ask them questions that, you know, I wouldn't otherwise get to ask. So I enjoy it. It is a lot of work, but I still enjoy it. And you get to keep up to date with embedded things. Yes. Even when one of us might not have been working on embedded things for a while. It's true.

People bring us stuff. Instead of having to go out and look at news, it tends to be that people will just tell us, have you seen this? And really, the answer usually is no, because otherwise, if you don't bring us the links, we don't notice anything. page that talks about which types of parts are becoming more available. It had a really up and down it just had arrows. It was pretty cool. I'll make sure it's in the links. I do have another question from a listener from Sila. And this one was kind of, I don't know if I am this person, so I'm a little sad. But how can I convince my, I only do C and Fortran and maybe C Sharp,

or Python and Arduino are silly and not embedded, senior engineers to use MicroPython? How do I show its benefits? I think the first thing you can do is a board bring up. senior engineers to use MicroPython? How do I show its benefits? I think the first thing you can do is a board bring up. So if you're developing a new product as an embedded product and you design the prototype hardware and you make one, or you make a few, then you've got to prove the hardware. So you've got an Ethernet port and you've got some high-speed ADC and you want to show that it works.

Because if it doesn't work, you have to do another round of hardware production. And you want to prove the hardware as quick as possible and you don't care about what the software is. You just say, I just want to show that the lines are all corrected correctly and it works and that the bandwidth is correct for the application and so on and in that case micro python is really it really shines very well um because usually if you wanted to get a complicated system with the ethernet controller, for example, running, it takes your C development team many months to do that.

And they need the hardware first because it's sort of got to, well, do a bit of development before the hardware comes, but you need the hardware to test on. But with MicroPython, if you've got an STM part that has an Ethernet controller connected, it should work out of the box

with one day of configuration on your custom hardware. And then you get everything else for free. You get a prompt, you can toggle GPIOs, you've got drivers for things. You can test your ADC controller by just writing a very simple driver in Python. And so board bring up to test all the lines work

and to test all the hardware works, it can be done within a week in Python, depending, of course, on the complexity. Sometimes it's in a few hours. And I think it really shows the power of MicroPython there. And I've known of lots of cases of this for BoardBringUp. And people say how great it is and how well it works. And then you don't have to use MicroPython again. You can then say, okay, we're proofing the hardware and now we write an application in C. And that's fine. I mean,

MicroPython is not the tool that will rule everything. Use the right tool for the application. And Board Bring Up is a really good application for MicroPython. And then maybe you see that, well, for this application, we can continue to, you know, the Board Bring Up that we did and the MicroPython application code that we wrote for the Board Bring Up is actually already 60% of the way of the final product. And you just write a little bit more in C and a little bit more in Python and you're done. Maybe that's enough. So I think, yeah, to convince people, do Bobring up or another one would be write a web server and a JSON parser. You don't want to do any of those

things in C. If you've got a Wi-Fi board and you just want to read a temperature sensor and post it to the cloud, in MicroPython, you can do that in like 20 lines. In C, you've got to pull in some existing framework and tweak it. But in MicroPython, doing those dynamic things like writing a web survey is very easy. So there's two cases, I think, which are pretty convincing. The board bring up, I always say you should try to have a command line first because it's so much easier to do board bring up. And I can see that if my board was on the MicroPython list or if it was an STM32 part, that would make board bring up much easier. My double E has not yet tried to compile Python, although he's going to have to. And I know it's something he worries about.

So that's very much an embedded software action. There were a lot of install steps. And that's not a complaint. For any embedded system, there are a lot of install steps. But I agree that the bring-up is the place to probably capture the hearts and minds of your senior engineers. Yeah, I mean, compiling firmware. I do it, you know, a thousand times a day. You've got to set up your tool chains.

It can be a pain. Yeah, I don't mind compiling a bunch of times a day. I do mind setting shop. Yeah. And then I have one more completely selfish question. The servo module in the Pyboard library. Should I use that? I have servos and I was

planning on writing my own code. And I don't know whether I should go ahead and do that because I know what I want to write or should I look at the Pyboard even though I don't have a Pyboard. What should I do about the servo module? That has a long history in the Kickstarter because with the Pyboard, the original Pyboard that was sold with the Kickstarter, you could buy a kit where it had some servo motors and i wanted to make it so it was very easy for people to make their server plug the server motor into the pie board which has a special server motor header three pin header with you know ground

power and data and you could plug in four server motors and then make them turn to the right angle, for example, or speed. And so I wrote a simple pyb.server class to make that possible. And that's where that comes from. And it has stuck around for 10 years and not been ported to other ports like SAMD or ESP32 because I guess we didn't see much interest and people can use PWM to do exactly the same thing. And even though it's PyB, it's pyb.servo, it runs on any STM-based board. Again, there's a lot of legacy history naming thing here. So to answer your question, if you're on an STM part, you can use the server class

and it gives you a very simple way to control servos. Otherwise, feel free to just use machine.pwm. Set the frequency to, what, 20 hertz and the duty cycle to like a millisecond. It will work. That sounds like I can't pull my encoders in and I'll be writing my own code. Which is sad. Ah, okay. The server cluster's not implementing code. Oh, I see. It's not a, sorry,

this is just a hobby server. This is not a stepper server class. Right. You've got a closed servo. Right. You've got a closed loop control, right? Right, but I'm not doing the commutation for the stepper, so at least I don't have to do that. No, sorry, the word servo is definitely overloaded.

I was talking about hobby servers. Cool. That's good. I mean, thank you, because that means I won't spend hobby servers. Cool. That's good. I mean, thank you, because that means I won't spend much time on it. Now I know I need to focus on my plan, which I probably should start thinking about. Damien, do you have any thoughts you'd like to leave us with? I guess go to micropython.org

go to github the micropython page and have a look how it's going there's also

a discord server that we have with a link from micropython.org which is where a lot of the community chats

so if you want to get involved the discord is probably the place to start and also community chats. So if you want to get involved, the Discord is probably the place to start. And also, if you're on GitHub, there's GitHub discussions we use and then issues and pull requests on GitHub. So yeah, boards these days are very cheap

and easy to get. There are thousands, if not tens of thousands, of different variants you could buy. ESP32 are very popular. STM32, hard to get, but hopefully that will change. But it's very easy to get a board, download MicroPython from the webpage, put it on and get a prompt and flash an LED.

And actually, even though flashing an LED is pretty cliche, it's actually pretty cool when you can do it, especially if they're bright LEDs or RGB LEDs. It's still a lot of fun to flash an RGB LED these days. So yeah, if you're interested, I encourage you to do that. I do too. It's a lot of fun, and MicroPython has been fun to work with. Our guest has been Damian George,

creator of MicroPython and founder and director of George Robotics. That is micropython.org and GitHub. Just search for MicroPython. There will be links in the show notes, of course, including the secret link to my favorite PDF that is their documentation. Thanks, Damian. Thank you. Thank you very much for having me. Thank you to Christopher for producing and co-hosting.

Thank you to our Patreon listeners Slack group for their many questions, many of which I didn't get to. Sorry. And of course, thank you for listening. You can always contact us at showitembedded.fm or at the contact link on Embedded FM. And now I have a quote to leave you with. I think this one's going to come from W.A. Wolf, a computer scientist. More computing sins are committed in the name of efficiency

without necessarily achieving it than for any other single reason, including blind stupidity.