Transcript from 456: Left Right Symmetry of a Banana with Damien George, Christopher White, and Elecia White.

Welcome to Embedded. I am Elecia White, alongside Christopher White. We have mentioned CircuitPython, using it as a user. Let us talk about MicroPython, as a developer. Our guest this week is Damien George, creator of MicroPython.

CW (00:00:23):

Hi Damien. Thanks for joining us.

DG (00:00:26):

Hi. Hi Elecia. Hi Chris. Thanks for having me.

EW (00:00:29):

Could you tell us about yourself, as if we met on a Discord about MicroPython?

CW (00:00:35):

<laugh>

DG (00:00:36):

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

(00:01:04):

Towards 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. So now I work exclusively developing and maintaining and improving MicroPython, and everything around it. I like to think that I approach that from an academic and scientific point of view, as well as engineer. So it is a bit of both, and hopefully a good mix.

(00:01:39):

Also a father of two boys. So basically my life is either being a dad, or developing MicroPython.

EW (00:01:54):

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 are behaving ourselves, we will not ask more about the branes. Are you ready?

DG (00:02:11):

<laugh> Yes.

CW (00:02:13):

In 30 seconds or less, explain the method of Lie-point symmetries.

DG (00:02:18):

Of Lie-point symmetries.

CW (00:02:19):

See! You have already got me. <laugh>

DG (00:02:21):

<laugh> Lie-point symmetries. This is going back a while, but <laugh> you have got to first understand about Lie groups, to understand about Lie-symmetries. This is a really hard question to answer. <laugh>

EW (00:02:43):

<laugh> You can pass.

CW (00:02:45):

You can definitely pass. You should pass, because it is mostly a prank. <laugh>

DG (00:02:53):

<laugh> But yeah, Lie-point symmetries- They allow you to find continuous symmetries of a group. They have a physical system and a model, and symmetries lead to conservation laws.

CW (00:03:07):

Oh.

DG (00:03:07):

So that is the most important thing in the world.

CW (00:03:09):

Okay.

DG (00:03:09):

So once you know a symmetry, like a left-right symmetry of a banana or something, there is a conservation law with that. In the banana's case, I do not really think it has one, but the conservation law of the- Sorry, the symmetry of translation-

(00:03:24):

So if I move left or right, I am still the same person, and that is a symmetry. It is called translation symmetry. It is a continuous symmetry because it is not discreet. Like I can move an arbitrarily small or large amount to the left or right, and the conservation law associated with symmetry is momentum.

CW (00:03:45):

Oh, okay.

DG (00:03:47):

Momentum is conserved. So this is a really fundamental part of physics, is conservation laws and symmetry. So the symmetry of time is the conservation of energy. So now, and in one second, the laws of physics are the same, and that means energy is conserved. So they are the two fundamental ones. Conservation of- Sorry, symmetry in position and time, is conservation of momentum and energy.

(00:04:16):

But there are lots of other ones, like conservation of charge in electronic circuits. It has to do with group symmetries of the internal properties of electrons. So you can understand lots of physics by studying symmetries.

EW (00:04:35):

Did not that mathematician I do not like, do all of the group stuff?

CW (00:04:40):

Galois?

EW (00:04:41):

Yes. Galois. <laugh>

DG (00:04:42):

Galois discovered groups. There are a lot of people. Group theory is big, but Lie did a lot of work on it.

EW (00:04:55):

Do you think the large Hadron collider will someday create a tiny black hole that will eat the world?

DG (00:05:01):

People did think this, seriously, before it turned on. The work I did was a bit related to that, because 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 is what some calculations show. But it was a small possibility of something like that happening.

(00:05:27):

Although most people point out that if that is possible, it would have happened in the sun every day, because the sun is colliding particles with very high energy. So we are pretty safe.

CW (00:05:39):

And now I am going to stare at the sun, and worry all day long.

EW (00:05:44):

Only until your eyes burn out, then you will be fine.

CW (00:05:47):

<laugh> Black holes in my eyes.

EW (00:05:49):

Yeah, exactly.

CW (00:05:50):

What is your favorite microcontroller?

DG (00:05:54):

Favorite microcontroller? I guess I would have to say STM part, because I am just so familiar with them, and they are 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.

EW (00:06:16):

Do you prefer printf debugging, or a step through with a programmer like JTAG?

DG (00:06:21):

Oh, 100% printf debugging.

CW (00:06:24):

Which has your preferred summer weather? Melbourne or London?

DG (00:06:29):

Melbourne.

EW (00:06:31):

Do you have a favorite fictional robot?

DG (00:06:34):

Giskard from Isaac Asimov.

CW (00:06:37):

And if you could teach a college course, what would you want to teach?

DG (00:06:42):

I would teach physics, theoretical physics.

CW (00:06:43):

Alright.

DG (00:06:43):

Oh, well, all the things related to that, like electromagnetism and thermodynamics and quantum field theory and general relativity, and all those really interesting subjects. Also very hard to teach <laugh>, but I have taught them at college level, in tutorials and things.

EW (00:07:03):

You mentioned having a postdoc, and you worked-

CW (00:07:07):

Lightning round is ever.

EW (00:07:09):

Yeah, sorry.

CW (00:07:09):

<laugh>

EW (00:07:09):

And you worked on the Large Hadron Collider, and you have got a lot of papers!<laugh>

DG (00:07:20):

<laugh> Not as many as you probably should have, but it is a pretty cutthroat industry, academia.

EW (00:07:25):

And then the pyboard came out on Kickstarter, and your papers they do not- Did I miss recent papers?

DG (00:07:37):

No. It is totally unrelated.

EW (00:07:39):

Ah.

DG (00:07:39):

I guess there is no link, except me, <laugh> 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- Well, topology and things like this. And then physics, theoretical physics, and also engineering, computer engineering. So 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.

(00:08:23):

So I have computer engineering degree, and a science degree with a PhD in theoretical physics. And they are sort of two separate things, of course. I continued with the physics because it was really interesting. And on the side always played with robotics and programming and microcontrollers. So it was my formal activities during the day would be theoretical physics, and my hobby activities at night. They are not necessarily splits day and night, but my hobby activities would be computers and microcontrollers.

(00:09:04):

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 to detect light and other things. So the Large Hadron Collider and the ATLAS detector, which I worked with people who are on that, they have huge numbers of detectors and microcontrollers and petabytes of data coming in every second. And they have to put filters and cuts on the data to narrow it down to the interesting events, and then store that somehow. It was a huge computing and engineering effort to make that thing work.

(00:10:00):

In the past, early physics a hundred years ago, physicists were not really a theoretical or experimental, they were just sort of engineer/scientists who would try and discover something interesting, and do a lot of work with their hands to build an apparatus. These days you cannot really build an apparatus by hand. The era of physics we are 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 apparatus.

(00:10:38):

I guess what I am saying is that being an engineer and being a physicist are not totally disjoint. There was always room for doing both together. MicroPython was born out of my side projects to play with microcontrollers and programming languages. I always really liked implementing programming languages. I had previously implemented a few scripting language or virtual machines on very small AVRs. Nothing that was ever public. MicroPython was, given all the things I had done, a natural step, I guess. So that is how it came to be.

EW (00:11:28):

Does that mean your job now is your hobby? What your hobby was?

DG (00:11:33):

That is correct, yes. My job now is what my hobby used to be. It was always a fallback to go to computer engineering, if being a theoretical physicist did not work out. Being in academia is quite hard. There are not many jobs around the world, for the things like investigating extra dimensions and inflation and those sorts of things.

(00:12:02):

So I felt that I was better and 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 is going.

EW (00:12:22):

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. Their scientists know what needs to happen, but not necessarily in what order, or how much reagents need to go in at each step.

(00:12:49):

So they wanted to be able to script the device, until they get ready to finalize it. They want to script it in the lab for months. Talking to their scientists and how many applications they have, I suspect there will always be scripting. Python scripting works really well. What should I have known to start with?

DG (00:13:12):

Maybe that that is a very good use case. There is a project that I was part of that was almost exactly that, developing some workflow using scripting. I think that there are people out there to help you, like me, if you were <laugh> stuck. Because that is a really good, as I said, a good use of MicroPython in an embedded system. So definitely, there are people out there could have helped you bring it up, if it was of any difficulty.

EW (00:13:52):

You did, actually.

DG (00:13:53):

Yes. <laugh>

EW (00:13:53):

Since I ended up with a board that was not quite the same as the boards already supported, I squawked on the Discord. I think it was only a couple hours later, you had gotten it for me. It was fantastic.

DG (00:14:04):

Yeah. Yes. I did not know the application though, but it is always good to help people bring stuff up. I guess it is a bit of an open-ended question, what should have known. <laugh>

EW (00:14:25):

Mm-hmm. But I can ask more specific questions.

DG (00:14:28):

Yes, please, narrow it down a bit.

EW (00:14:32):

I can make modules in C. I have 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?

DG (00:14:43):

Yep. That is a good question. Well, the usual thing I do first is write something in Python and then if it is too slow or not deterministic enough, it can go into C. But you usually find that Python is pretty good for most things.

(00:15:05):

For example, I developed a Wi-Fi driver for the pyboard in Python. It was a pure software SPI interface, bit banged. 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.

(00:15:35):

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.

(00:16:08):

Another case I had, reading an ADC very, very quickly and storing it into RAM. Easy to develop in Python. It is only a couple of lines essentially, because you are just reading from a SPI device and putting into memory. But then eventually that had to go on a very, very low, um, very high priority interrupt. That was basically timing, to get it very accurate ADC sampling, and that went into C.

(00:16:42):

So that is 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.

EW (00:16:58):

And that is why my motors are in C, because there are timers and counters and encoders, and all the things that need to work together.

DG (00:17:06):

Yes. Did you prototype it in Python first?

EW (00:17:11):

I did some, because I was on an odd board, my pin mappings have never been as good as they should have been.

DG (00:17:19):

Right.

EW (00:17:22):

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.

DG (00:17:35):

Yeah. If you already have a driver in C, just use that.

EW (00:17:38):

Do you usually recommend people make lots of modules for each part of their system, or one module to rule them all?

DG (00:17:48):

You mean when structuring a Python program?

EW (00:17:50):

Yeah.

DG (00:17:56):

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. In Python, there is not much overhead really to having things as separate components. Things are so object-oriented and like duck typing and very dynamic, that best to keep them well separated into separate files for the different parts.

(00:18:31):

So you could have a ten line driver for an LED, which just turns it on and off <laugh>. But that is 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. Yes.

CW (00:18:52):

I have a question, as producer of the show. What is MicroPython?

EW (00:18:56):

<laugh>

CW (00:18:56):

Because we jumped into, you know...

EW (00:19:02):

But I have a lot more questions to get through.

CW (00:19:04):

<laugh>

EW (00:19:04):

I want to talk about the boot process, and the pyboard-

CW (00:19:07):

Well, it is up to you. We can discuss all the deep, and how it all works first. And then our listeners can have a summation at the end, where it is described, what it is. Or we could quickly introduce people to MicroPython <laugh>.

EW (00:19:22):

They can read the Wikipedia.

DG (00:19:23):

So Python is a language, a programming language, which is used on desktops. It is a very dynamic language, and you really would not think it would be suitable for microcontrollers. So I guess what MicroPython is, is making Python work on a microcontroller, in a way that is efficient and actually useful in embedded situations.

(00:19:49):

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, it is designed to give you a very much a Python feeling, in an embedded system.

(00:20:15):

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/MicroPython, and make them run on the microcontroller, and build a whole application.

(00:20:35):

So yeah, "MicroPython" is two words, "Micro" and "Python." You can think of the "Micro" being small, but also being microcontroller. But the general philosophy is that it is trying to make Python work well in a microcontroller.

CW (00:20:52):

But people should not expect to take their giant Python script, that has NumPy imported and SciPy and-

EW (00:21:00):

OpenCV and SciPy. <laugh>

CW (00:21:01):

And drop it onto a Cortex-M0.

DG (00:21:06):

No, although there is ulab, which is a NumPy replacement for MicroPython.

EW (00:21:12):

Mm.

CW (00:21:12):

Oh, cool.

(00:21:14):

Which is becoming quite popular. That is not maintained by us. But 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.

(00:21:36):

But yeah, you cannot expect just 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.

EW (00:21:54):

How come the logger library from Python is not supported?

DG (00:21:58):

It is.

EW (00:21:59):

It is? It was not in my list.

CW (00:22:02):

<laugh>

DG (00:22:04):

It has been around for a while. It has been updated recently. You can install it from micropython-lib. It is there.

EW (00:22:12):

Oh, okay. Never mind. I must have just not read that part. Whoops.

CW (00:22:17):

I have one follow-up question, and then we can go back to the train that Elecia was on. How is, or is, MicroPython different from CircuitPython?

DG (00:22:26):

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 is what a fork is. And it has merged back MicroPython changes since it- CircuitPython's main theme is to, I think, be angled towards beginners more than MicroPython.

(00:22:58):

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 Ubuntu. Arch Linux is more for power users, and Ubuntu is more for people who wanted a graphical desktop that is easy to use. That is really a big simplification, but there are different flavors of Linux. In this case, you can think of MicroPython as having different flavors intended for different target audiences.

(00:23:30):

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 in the libraries, the display I/O and async I/O and bus I/O, and the way that CircuitPython give you access to the hardware. Also 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.

(00:24:13):

And then also they integrate tightly with Adafruit hardware. Because the development is sponsored by Adafruit, so they are 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.

(00:24:36):

Those are the main things, is the way you interact with the hardware, the libraries, and the tight integration with Adafruit hardware. And then the focusing more on beginners and tutorials to make a really good onboarding experience.

(00:24:55):

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 async I/O and- Though CircuitPython is introducing async I/O now. But we have 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 do not require USB, like CircuitPython did in the early days.

(00:25:37):

We do have a lot of industrial users who use MicroPython. We try and support them, and maintain a very performant core. We are 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 is the different flavor of doing Python on a microcontroller.

EW (00:26:23):

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. Do you have terms?

DG (00:26:50):

Yeah, so there are 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 is too hard to compile firmware these days. You need so much set up. So that is a benefit of MicroPython is that you just download firmware, and then write some Python code in a text file.

(00:27:17):

There are lots of I guess you could call them "users" like that. They want to install libraries, which you can do if they are Python libraries. But sometimes they want to install libraries like ulab/NumPy, and that is a bit harder because you have to recompile.

(00:27:34):

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 their device. Usually that is, yeah, not too hard. There are lots of guides about how to build firmware. So once you have got over that hump, you can then configure C modules yourself.

(00:28:01):

Then there are people who go further than that, like, "Well, I need this extra feature, because it is missing." And they have got to implement it. If people have the ability to do that, they go and do that. There is a whole scale there of people who just want some small feature. And then there are people who want to add some missing Python thing, like ordered 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.

(00:28:34):

Usually we do not hear from those people, right at the far end of integrating MicroPython, because they are highly skilled, and do not really need to ask questions. Usually they contribute back things that they think are useful for the wider user base of MicroPythons. They are like, "Oh, we have been doing this thing, and we found that it was better this way. So here is a patch to make it work for everyone." Or they contribute a new feature that was missing, like ordered dictionaries, or something like that.

(00:29:07):

So there really is a big scale. It is not like a black and white user/developer. It is user from just doing Python scripts, all the way to person who is modifying things, improving the garbage collector to make it faster, or something like that.

EW (00:29:27):

The whole project is under MIT license, which is one of the "you can pretty much do whatever you want, as long as you do not sue me" licenses. It is 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?

DG (00:29:50):

That goes back to the very early days of the Kickstarter. It did not have a license. I did not release the code, and I had not put a license on it. It was not even out there. But we were discussing what license to have, with some of the backers of the original project. That was over ten years ago.

(00:30:12):

It was basically a choice between MIT and GPL. I was not that up to date with, or into knowing, the details of licensing and open source software. But there were-

EW (00:30:37):

Because those are two very different licenses <laugh>.

DG (00:30:40):

Indeed. Indeed they are. There were very vocal people on both sides of the fence to begin with, saying- Both of them basically religions. <laugh> So there were people on both sides. The MIT license won, because it was simpler, and I usually prefer simpler things. And I guess that is the answer, that it is simpler.

(00:31:03):

I think it was almost luck that it was the right decision. <laugh> In hindsight and after learning a lot more about licensing, because we are very strict about licensing now. And making sure things interoperate with the MIT license, and keeping GPL away from the code base.

(00:31:24):

But at one point there it could have been GPL, which would have really changed things a lot, I think. Although Linux is GPL, that has a much different story. I think with embedded, you just sometimes have no option. If it is GPL, you just cannot use it. Because you have got to embed your code and you are not allowed to release anything, because it is secret of how it works.

(00:31:49):

Yeah, it was a decision, a very conscious decision, and there were input from a few people in the beginning to go with MIT.

EW (00:32:03):

You mentioned the Kickstarter. This was a Kickstarter more than decade ago, to create the pyboard.

DG (00:32:13):

Yes.

EW (00:32:14):

What is the pyboard, and why did you do a Kickstarter?

DG (00:32:17):

So at the time, which was about ten years ago, 2013, at that time, Kickstarter was a big thing. It was not brand new, but it was relatively new, and some things were getting millions of dollars and it was really interesting. There was Pebble around that time, the Pebble Kickstarter with the Smartwatch.

(00:32:45):

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 a new way of programming it. Like, one of them was the Arduino looked like a mass storage device when you plugged it in. You copied your file, and that flashed it onto it, which was cool. We took that idea for MicroPython.

(00:33:11):

But there were all these very same simple Kickstarters, that were getting hundreds of thousands of dollars for a simple idea. I was like, "Surely people want a more interesting thing, rather than just a little Arduino add-on." So MicroPython was designed to be a Kickstarter, in the sense that I thought, "I can do better than what is there," in terms of the Kickstarters that were there, and then maybe it can be a success as well.

(00:33:53):

I thought, "What is my skillset and interest? Microcontrollers and programming languages." And I am like, "What is a popular language that you cannot run on a microcontroller?" Yeah, Python was the obvious thing, because JavaScript was already there, with Espruino from the very early days. Espruino itself had done a Kickstarter and done very well. Python was sort of the next language on the list of popular languages that were not on a microcontroller.

(00:34:24):

So that was the idea, to get Python working on a microcontroller, and make a Kickstarter. The pyboard was the piece of hardware that the backer got as a reward. When you are doing a Kickstarter, if you did a pure software Kickstarter it is a bit boring, because people want something physical. All these popular Kickstarters that were doing well, the reward was a piece of hardware, something physical that you could use.

(00:34:54):

The idea was to come up with something relatively cheap. This was in the UK and I think it was 20 pounds, or something close to that, for the pyboard. So if you backed it for that, at that level, you got a pyboard and it would run MicroPython. That was the offering. The price point was designed to be relatively easy, cheap for people.

(00:35:21):

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. That was really the scope of the project, that you would just write like main.py and it would blink some lights and turn some servos. And it would be a self-contained thing.

(00:35:54):

There would be no compilation required. There would be no installation required for anything. So people on Windows or Mac or Linux did not need to install a single thing, because you have a text editor already, and you can copy 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.

(00:36:21):

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 prototype pyboard. And get quotes from manufacturers to make a few thousand of them, so I could get the pricing correct.

(00:36:44):

Once all those boxes were ticked, prototype and pricing and viability, then the Kickstarter went live. Made a video. Copied what everyone else did, in the sense that the video is describing the thing and making it exciting. The page explaining what it is, trying to explain how you do it, and what the risks were. Kickstarter back then was pretty open. Things got through easily, people were trusting, and projects usually got delivered.

(00:37:22):

It was a pretty fast ride. It was like got a hundred thousand pounds in 30 days, and then I had to deliver. I think it was about six months or maybe five months to shipping out the first pyboards from the close of the Kickstarter. Which I think is pretty good <laugh> in hindsight, getting things manufactured.

(00:37:51):

We did a run of 3,000 pyboards to start with. 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 a round number, based on the number of STM32F405s that you could buy in trays. Yeah, so built 3,000. Shipped them all out. And then started selling them post the Kickstarter. The money we got from that, we built another 3,000.

(00:38:23):

So really Kickstarter was a perfect name for what happened, is that it kickstarted it. I could not have funded development of 3,000 pyboards to begin with. But Kickstarter did do that, with people backing it and putting up money front and believing in the idea, trusting that I could deliver. Delivering and then using the further proceeds from selling more pyboards, to make the next run and so on and so on. It just ramped up from there.

(00:38:55):

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. I do not think you can never 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. It has always had a tie into reality or something physical, or some kind of project or people actually using it in the real world.

(00:39:33):

Yeah, that kind of mirrors my experience in physics, in that when you do theoretical physics, there is a lot of the theorizing and thinking up crazy ideas about black holes and extra dimensions, but it is always rooted in reality, because you have got experiments. If your theories do not match the experiments, then you go throw away theory and you start again. Or you tweak it.

(00:40:01):

In MicroPython, the hardware always directs us. If it is not for the hardware, then MicroPython is not there. And the hardware is sort of, you know, without MicroPython it is not interesting. Without the software it is nothing. So I try and keep that balance of hardware and software. Although these days MicroPython could run in the browser, so it can be a pure software thing, and then other things. But we are always trying to keep onto our roots, of connection to microcontrollers.

EW (00:40:35):

Do you still sell the pyboard?

DG (00:40:39):

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. But we have started production of pyboard again.

(00:41:02):

We are designing some replacements that use new microcontrollers, or new STM parts and other parts as well. 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.

EW (00:41:25):

When you started the Kickstarter project, before it funded, could you have imagined still working on the project ten years later?

DG (00:41:38):

Yes and no. I guess I could imagine it being a success. And I could imagine it being something I did full time. But I do not think I would have thought that that was the probable path. I did not 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.

(00:42:12):

I really did not have a long-term plan for it. Just wanted to follow my nose, follow the lead of what users and people have 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.

EW (00:42:50):

We had a question from a listener, MattyC, who asked about MicroPython being used in a web browser. You have mentioned web browsers. I thought this was a hardware thing.

DG (00:43:05):

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 is still Python, has a lot more uses than just a microcontroller.

(00:43:26):

Some embedded projects have a little Linux machine, like single board computer running Linux, because it needs to do 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 is really fast. So you can use MicroPython as a Python replacement on an embedded Linux computer to do scripting. I know of industrial uses that do that.

(00:43:55):

Python can be embedded into games, for example, with MicroPython to script a game. Or in some scientific apparatus where it is 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 is all pure software as well.

(00:44:18):

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 in the browser. You can compile normal Python, but because it is so big, it takes many seconds for the browser to download it and load it up, which is really annoying if you are making a responsive webpage.

(00:44:46):

Whereas MicroPython is like ten times smaller and therefore ten times faster than normal Python to load in the browser. 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 "on button click, do this," you can write Python "on button click, do this," <laugh> however you would in Python.

(00:45:19):

So that is the idea with PyScript, which is a new framework for running scripting languages in a browser, not just Python, but other ones. And MicroPython and CPython via the Pyodide implementation, are both sort of backend implementations of Python in the browser. So MicroPython, because it is so small and efficient, it is useful in more than just the realm of microcontrollers.

EW (00:45:53):

Web development is radically different in their philosophies and development styles, from embedded development. Has the web development world influenced the MicroPython path?

DG (00:46:07):

It is 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.

(00:46:27):

So you freeze in all of the libraries that you have got, to provide logging for example, and datetime, and all those things. And you enable all the optional features, so that people have what they expect to be a Python environment.

(00:46:42):

It also needs a different memory management. On a microcontroller you have a fixed amount of memory, and a fixed heap size, say 100, 200 K. But on a web browser, you have got essentially unlimited memory, so you need to have an expanding heap, which we can implement as well. So it is very similar, but there are a few tweaks you could do here and there, to make it suit the browser more.

EW (00:47:14):

Another question came from Scott, which is usually my question, "How is MicroPython development funded?" You mentioned the pyboard, but you have not had those in stock.

DG (00:47:23):

<laugh> Yeah. Okay, so there are three main sources of funding. Sponsorship on GitHub, which has been the past couple of years, been really good. Really, really appreciate all the people who sponsor MicroPython. Even if it is a dollar a month, it all adds up. That goes towards paying maintainers to keep GitHub running, deal with issues, for requests and features that people want. So that is funding source number one.

(00:48:07):

Number two is hardware sales. So original pyboard, pyboard D-series, and a few of the accessories we had. 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.

(00:48:29):

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 had nothing, but we did have a bit of stock. In the future we will have hopefully more hardware as well. So hardware is number two.

(00:48:48):

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 are no embedded consulting services that are 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.

(00:49:32):

But there are lots of cases there, like European Space Agency improving MicroPython to run in space applications, as 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 kept private to the client, but sometimes there are improvements to MicroPython that can come through to mainline. So yeah, consulting is the third.

(00:50:11):

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, <laugh> well not voluntarily, but the maintainers of MicroPython are all paid people. It has always been paid since day one, and funded. I think that is really important, to keep a project going. And I am really proud that we can do that. That it is funded well enough that it can keep going.

(00:50:42):

It is not just relying on volunteers, although there are a lot of people on GitHub who donate their time. We are very grateful for that, for their contributions, who are not paid by 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.

(00:51:08):

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 is really great. So I think we have a great community of people who contribute, and it is, as I said, really great that we can be funded to keep doing what we love.

EW (00:51:33):

And you currently implement Python 3.4?

DG (00:51:38):

So Python 3.4 was the version of Python that was out when I started MicroPython. So that was the one I tried to match in the beginning, in terms of syntax features. Since then, Python mainline CPython has advanced quite a lot to 3.11. They have added a lot of staff, a lot of syntax features, like for example, underscores in numeric literals, which I love. We have tried to keep up with most of the syntax changes, although we have not done them all.

(00:52:15):

But then there are other things, like library changes, and semantics of built-in objects or methods. We have sort of stuck at 3.4 as the base reference version, but we have definitely added a lot of things from later versions. Like fromhex for example, to convert hex to bytes, just as one example.

(00:52:41):

We actually have in the documentation a feature matrix of things that were added in later CPython versions, and whether or not MicroPython has done that or we will do that. So yeah, it is 3.44 at least, but then a lot of other features. I guess one day we will bump to 3.5 and 3.6 hopefully, once we can confident that we have got most of the features from that version.

EW (00:53:08):

As you have mentioned, there is CircuitPython 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 are going to diverge, maybe not just those two, but in general?

DG (00:53:29):

I think there really is just those two. I do not- Well, CircuitPython retain our core and merge back the core interpreter and virtual machine into their fork and that is great, because it means we are the same there. As I mentioned before, it is the libraries that we offer that are different. That has led to issues for users, in that they would love for a library from CircuitPython to run a MicroPython, or vice versa.

(00:54:05):

There are adaptation layers to make that work, but they are 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 will get there. <laugh> But yeah, I think it is 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.

(00:54:51):

I think you making drivers work is biggest bit of that, to make sure it does not fracture so much into you have camp A and Camp B, and they both have completely independent drivers, so you have got to choose from the beginning which one you want to sit in. I do not think that is useful for people.

EW (00:55:13):

We have been making you do all the talking, but you mentioned you had a question or two for us.

DG (00:55:18):

Yeah, I was wondering- I talked about MicroPython and funding, and consulting versus open-source development. I am wondering for yourselves, how do you split your time between your podcast, and the embedded engineering that you do?

CW (00:55:37):

95% engineering, 5% podcast <laugh>.

EW (00:55:40):

Podcast is a hobby. Definitely.

CW (00:55:42):

Yeah. I would not mind if the podcast took more time, but also we would need to be compensated more for it, which is the challenge.

DG (00:55:51):

Right, because I can imagine it takes a lot of effort to produce-

CW (00:55:54):

It does.

DG (00:55:54):

A podcast. So 5% seems really low.

CW (00:55:57):

Well, okay, that is probably flip. No, it might be more like 10 or 15%.

EW (00:56:03):

I think I calculated it. It was about eight to ten hours per week, combined.

CW (00:56:08):

Alright, so maybe up to- Yeah, that is a day- Two of us combined day's worth of work. Probably. Yeah.

EW (00:56:16):

And now we are doing them every other week, so it is not quite as much, the percentage. But we have not been very good about monetizing. Our Patreon group is fantastic and we appreciate them very much, but-

CW (00:56:32):

We also spend all that money on the podcast, pretty much.

EW (00:56:34):

Right.

CW (00:56:34):

<laugh> Yeah. It is not a revenue source <laugh>.

EW (00:56:40):

But I believe Christopher will be posting soon that he needs a short gig. So there is always the possibility that it can serve its initial purpose, which was advertising. Although for the most part we do not. And it is fun. I get to meet people, and I get to ask them questions that I would not otherwise get to ask. So I enjoy it. It is a lot of work, but I still enjoy it.

DG (00:57:12):

And you get to keep up to date with embedded things.

CW (00:57:15):

Yes. Even when one of us might not have been working on embedded things for a while <laugh>.

EW (00:57:20):

It is 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 do not bring us the links, we do not notice anything." <laugh>

(00:57:35):

Although DigiKey has a nifty page that talks about which types of parts are becoming more available. It had a really, like up and down, it just had arrows. It was pretty cool.

DG (00:57:55):

Mm, have not seen that.

EW (00:57:56):

I will make sure it is in the links. Let us see. I do have another question from a listener, from Sila. This one was kind of, I do not know if I am this person, so I am a little sad, but "How can I convince my, 'I only do C and Fortran and maybe C#,' or 'Python and Arduino are silly and not embedded,' senior engineers to use MicroPython? How do I show its benefits?"

DG (00:58:26):

The first thing you can do is a board bring up. So if you are 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 have got to prove the hardware. So you have got an ethernet port and you have got some high speed ADC, and you want to show that it works. Because if it does not work, you have to do another round of hardware production.

(00:58:52):

You want to prove the hardware as quick as possible, and you do not care about what the software is. You are just like, "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, MicroPython really shines very well.

(00:59:18):

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- You have got to well do a bit of development before the hardware comes, but you need the hardware to test on.

(00:59:36):

But with MicroPython, if you have got an STM part that has a 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 have got drivers for things. You can test your ADC controller by just writing a very simple driver in Python.

(01:00:02):

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 is in a few hours. I think it really shows the power of MicroPython there.

(01:00:20):

I have known of lots of cases of this, for board bring up. People say how great it is and how well it works. And then you do not have to use MicroPython again. You can then say, "Okay, we are proving the hardware, and now we write an application in C." And that is fine. 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.

(01:00:47):

And then maybe you see that, "Well for this application we can continue to- 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 are done." Maybe that is enough.

(01:01:08):

Yeah, to convince people, do board bring up. Or another one would be write a web server, <laugh> and JSON parser. You do not want to do any of those things in C. If you have 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 have got to pull in some existing framework and tweak it. But in MicroPython doing those dynamic things, like writing a web server, is very, very easy. There are two cases I think, which are pretty convincing.

EW (01:01:51):

The board bring up. I always say you should try to have a command line first, because it is 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.

(01:02:12):

My EE has not yet tried to compile Python, although he is going to have to. I know it is something he worries about. So that is very much a embedded software action. There were a lot of install steps, and that is not a complaint. For any embedded system, there are a lot of install steps <laugh>. But I agree that the bring up is the place to probably capture the hearts and minds of your senior engineers.

DG (01:02:48):

Yeah, compiling firmware. I do it a thousand times a day. But you have got to set up your tool chains. It can be a pain.

EW (01:02:58):

Yeah. I do not mind compiling a bunch of times a day. I do mind setting it up <laugh>.

DG (01:03:03):

<laugh> Yeah.

EW (01:03:08):

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. I do not 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 do not have a pyboard. What should I do about the servo module?

DG (01:03:34):

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. I wanted to make it so it was very easy for people to make their servo- Plug the servo motor into the pyboard, which has a special servo motor header, three pin header with ground, power and data. You could plug in four server motors, and then make them turn to the right angle, for example, or speed.

(01:04:04):

So I wrote a simple pyb.Servo class to make that possible, and that is where that comes from. It has stuck around for ten years, and not been ported to other ports like SAM D or ESP32. Because I guess we did not see much interest, and people can use PWM to do exactly the same thing.

(01:04:31):

Even though it is pyb.Servo, it runs on any STM based board. Again, there is a lot of legacy history naming thing here. To answer your question, if you are on an STM part, you can use the Servo 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.

EW (01:05:06):

That sounds like I cannot pull my encoders in, and I will be writing my own code, which is sad.

DG (01:05:11):

Ah, okay. The servo class does not implement encoders. Oh, I see, it is not a- Sorry, this is just a hobby servo. This is not a stepper servo class.

EW (01:05:25):

Right.

CW (01:05:26):

You have got a closed loop control, right?

EW (01:05:28):

Right. But I am not doing the commutation for-

CW (01:05:32):

Yeah, yeah.

EW (01:05:32):

The stepper. So at least I do not have to do that.

DG (01:05:37):

No. Sorry, the word "servo" is definitely overloaded <laugh>. I was talking about hobby servos.

EW (01:05:45):

Cool. That is good. Thank you, because that means I will not 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 would like to leave us with?

DG (01:06:01):

I guess go to MicroPython.org. Go to GitHub with MicroPython page, and have a look how it is going. There is 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.

(01:06:29):

Also if you are on GitHub, there are GitHub discussions we use. And then issues and pull requests on GitHub. 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.

(01:06:56):

But it is very easy to get a board, download MicroPython from the webpage, put it on, and get a prompt and flash an LED. Actually, even though flashing an LED is pretty cliche, it is pretty cool when you can do it <laugh>. Especially if they are bright LEDs or RGB LEDs. It is still a lot of fun to flash an RGB LED these days. So yeah, if you are interested, I encourage you to do that.

EW (01:07:23):

I do too. It is a lot of fun. And MicroPython has been fun to work with. Our guest has been Damien 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.

CW (01:07:47):

Thanks, Damien.

DG (01:07:48):

Thank you. Thank you very much for having me.

EW (01:07:51):

Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their many questions, many of which I did not get to. Sorry. And of course, thank you for listening. You can always contact us at show@embedded.fm or hit the contact link on embedded.fm.

(01:08:07):

And now I have a quote to leave you with. I think this one is going to come from W.A. Wulf, 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."