#323 – An Interview with Tony DiCola

Chris Gammell: This is The Amp Hour Podcast. Recorded November 16th, 2016. Episode 323. An interview with Tony DeCola.

Dave Jones: Welcome to the Amp Hour. I'm Dave Jones from the AEV blog.

Chris Gammell: And I'm Chris Gammell of Contextual Electronics. And I'm Tony DeCola of Adafruit.

Dave Jones: Hey, Tony, thanks for joining us.

MicroPython: Welcome, Tony. Oh, yeah, thanks for having me.

Dave Jones: Is this our first Adafruit? It is. Do Adafruit people have a name? That's a good question. Adafruiters. Adafruitians? Adafruiters, yeah, that could be it.

MicroPython: We'll pick that and we'll see that's the name.

Dave Jones: Right, okay.

Chris Gammell: Cool. And Tony's here because, well, last week we were talking about, I brought up MicroPython and I mentioned Tony's tutorials. And then I quickly sent him an email and said, hey, Tony, can you come on the show this week and talk about it? So, yeah, thanks for being here. And we're excited to talk about this stuff, mostly based on my interest and now Dave's disinterest, which will be turning into interest, I'm sure.

MicroPython: Yeah, and this is good. It's good to have kind of both sides of the coin, I think. So, you know, we can talk about what's good and, you know, where you might want to use MicroPython. And then maybe cases where, yeah, you might not want to use it in some instances to give you kind of both sides of how you'd want to use it. But yeah, I've been working a lot with MicroPython in the last couple months or so, just using it at Adafruit with some of our boards and things and doing lots of guides and videos. So if you've seen like our YouTube channel and our learning system, you'll probably see all kinds of stuff from me there. And so, yeah, we're trying to kind of get the word out that it's a really cool platform. If you've used things like Arduino or Raspberry Pi and you're familiar with those kind of systems for like learning electronics, MicroPython could be a really cool platform to explore to do things like high-level programming on small little microcontrollers, you know, things that are like the size of an Arduino or even smaller than that, for example. So, yeah, I'm really kind of passionate about it. And that's, I think, a good discussion that we can have about it here.

Dave Jones: All right. For the dummies out there like me, what is Python? Oh, yeah.

MicroPython: Great question.

Dave Jones: Let alone MicroPython. Right. Yeah, exactly. Python.

MicroPython: Exactly. Start there. So Python, it's a programming language. And I don't know exactly how old it is, but I think it was created in kind of the early 90s. And it's basically a high-level programming language. So it's interpreted. You write code that's, you know, not necessarily compiled straight down into assembly language that runs on the processor, but it gives you a simpler interface. And so it was built kind of like a lot of languages like Perl, you know, some of those higher level languages that are meant to do things like administration of your system. You know, you want to process a lot of files, read a lot of data, maybe parse out interesting things and go from there with it. And it was kind of created as a similar language like that, but with different principles. So in Python, things are meant to be obvious and easy and like only one way to do it in contrast to like Perl, where there may be like 10 different ways to open a file. Right. Exactly. So it was meant to be kind of a simpler little language, maybe not simpler, but a little more obvious, easier to learn language. And it kind of took off from there. And I'm not like a total Python expert, but it's really kind of become a beginner's language, like a great place to learn programming, but also a language for advanced things. So they're like full web apps, like Dropbox is actually all written in Python, apparently, like the client apps and the web servers and things like that. So it is a pretty capable language, but also used as a great way to learn because it's got a simpler syntax, you know, you don't have like the memory management and things that you have to deal with. It's got garbage collection and reference counting and things like that internally. So it's, you know, really good kind of platform to begin with, but then also to go further and do real things with it.

Dave Jones: So if apps like that, like Dropbox are written in Python, does that mean that my web browser, my computer has a Python interpreter built in? Your web browser, not necessarily, but... Like how, yeah, how does it, if I run Dropbox on their website, how does it run?

MicroPython: Right. They do a thing where they embed the Python interpreter into their executable. And that's one... Aha.

Dave Jones: So it's an interpreter running an executable.

MicroPython: Got it. Exactly right.

Dave Jones: As like an executable. Right. Okay. So in that respect, you can maybe think of it as a compiled language because it generates an executable, but there's a kernel, there's a Python kernel in there, which is running and then taking the code and then executing it.

MicroPython: Right. Exactly. It's, you, you can take Python and, you know, attach its interpreter to it and run that code, you know, run your code. And even though it's still interpreted, you're right. You've got like an executable that runs on their tools. I think Dropbox actually makes one that lets you take a Python app and like turn it into an executable that runs your code like that. So exactly. Does it really make that more portable or how does that end up?

Chris Gammell: What's, what is the net result of that?

MicroPython: Uh, you just have one executable, so you don't have to have Python installed. So like Dave was saying, you know, you don't necessarily have it installed on your machine. Like if you downloaded a .py file and you wanted to run it, unless you had Python installed, you're just going to get an error. Like a computer says, I have no idea what to do with this thing. Whereas you can use certain tools to say, okay, I want to make an executable like, you know, a Mac OS 10.app file or a windows.exe. And then inside of there, it will add the Python interpreter and your code. So when you double click that executable, it'll run the interpreter and then feed your code into it. So to the user, it feels like they're running a normal app, but in reality, it's a Python program that's running behind the scenes there.

Dave Jones: That's interesting. Why not at that point that you're generating an executable, why not actually just turn it into compiled assembly language? This is similar to like, uh, the versions of basic back in the old days, right? Basic was mostly an interpreted language, but then the basic compilers came along, which then took your existing basic code and would actually generate proper executables. And it would not run as an interpreter in the exit.

MicroPython: Oh, right. Yeah. Like do a conversion into like C or assembly, something like that. Uh, I, I would bet there are tools to do that. I haven't looked into it myself. Um, but one thing is that Python is a pretty dynamic language. So kind of like JavaScript where you could have an object and you can add things to it. You can remove things from it dynamically. So that sometimes gets a little harder and you, you can still model that and convert that into, you know, C and things like that. But yeah, it gives you a little more flexibility when you're really still dealing with that interpreted language. Like you can kind of control the state of it in different ways. Uh, that's, you know, it gets a little more advanced for it. So, but yeah, it's not necessarily like a, uh, the, the only way to do it. I mean, like you said, for performance cases, you know, you definitely might want to look at how do you go and actually have like native code that's going to be faster, uh, and works a little better. And that's actually one of the strengths of Python too, that I didn't really mention is that, uh, when I say Python for the desktop, it's really C Python. Like the letter C in front of it is the implementation that everyone uses. Oh, okay. They call it C Python because really most of Python is written in C. Uh, a lot of it is written in Python, like some of the libraries and things, but the core functions are really just C functions. So like, you know, things like outputting to your terminal or like doing any kind of graphics processing or even like advanced scientific processing. So there's this whole system called numpy and scipy, which are all these libraries to do, you know, advanced like Fourier analysis. Those are implemented in C because they need to be really fast and efficient and use all the features of your hardware, but then they give a nice Python interface. So you use that in your Python script to say, okay, I want to do a Fourier transform. So I'll just call this little function and maybe pass in, you know, big buffer of data to it and I get back my results and I go and process it from there. So that is the nice thing about Python. And then it's really made to work with native code, at least the desktop versions like that, so that you can plug in where you need the optimizations, uh, that kind of code and go from there with it. So it gives you a lot of flexibility like that.

Chris Gammell: Yeah. Interesting. The dataset stuff is definitely what I usually think about because the data scientists, I know they all are using it for their, you know, just for a very handy kind of pushing data around type of type of tool. It seems like that, that is the go-to. I don't know how I never, I never really got into it because I guess I was never doing like the processing at the, you know, at the web level or the, even the computer level. But it's interesting to hear about the, the interplay with C as well, because I think that that ultimately makes it compelling from the hardware standpoint, right? I mean, that's what a lot of people are going to immediately say, well, why not just program in C. So maybe, maybe could you start to contrast some of the, the, how, how it operates differently than C in the MicroPython version?

MicroPython: Yeah.

Dave Jones: And maybe, first of all, what is MicroPython? Exactly. What is the difference?

MicroPython: Right. So I'll give you just a quick kind of overview of MicroPython. So MicroPython, it's an implementation of Python for microcontrollers or really just memory constrained environments. Uh, because Python and C Python, like I was mentioning, those were really built for desktop environments where memory is effectively free. Exactly. You know, you've got a gigabyte, might as well be infinite memory. Uh, so Python does things like, you know, it's basic numeric type is just an infinitely large integer. So you could have, you know, giant numbers, whereas that's usually not going to be very performant if you're doing small math operations.

Dave Jones: Performance oriented. Yeah. If, if, if people don't know the tight, like in C, for example, the, the data type you choose, whether it's an eight bit integer, a 16 bit 32 bit, 64 bit integer, et cetera, that determines how many registers in your processor are going to be used and how many processor operations and hence speed and everything else.

Chris Gammell: And battery power and everything that's tied to that. Yeah.

MicroPython: Exactly.

Dave Jones: And if Python's in what you're saying, infinite size integer, how does that work?

MicroPython: Exactly right. So it just has a big integer implementation. So it's, as soon as you get above a certain value, you know, it can just, uh, add on more precision for it.

Dave Jones: Uh, but they actually dynamically based on the number that's already stored in there. It dynamically allocates. Yeah.

MicroPython: It can, it can add more, uh, more digits to it, but it actually has optimizations because for small values, you don't want all this overhead of like doing this more complex math. So it has to be smart enough to say, okay, if your integer is below this range, then we actually have like special, uh, they, they keep like one instance of each number below 255 or do lots of little tricks like that. Interesting. All right. But that type of stuff is really difficult on these little microcontrollers where, you know, you don't want to waste all of this memory to store arbitrary precision numbers. If you know, you're only dealing with maybe small numbers that you're talking to some hardware or some driver, uh, that, that has to deal with that. So, so micro Python looked at all these cases where Python was using a lot of memory. So, uh, you know, numbers are one example, um, just the objects themselves in Python have a lot of extra state associated with them. Uh, I think even the reference counting that Python does, they looked at using a garbage collector instead of that in micro Python, because when you do a reference count, every object has to have a count of like how many instances are out there and that's going to take up some memory. So they really focus on how to, uh, slim down Python, but still implement the core language itself so that, you know, if you do a for loop in normal Python, that should be exactly the same in micro Python. And even things like defining a function and classes and all kinds of the features that Python has are also meant to be supported in micro Python. And they're pretty close. It's about, I think like 90% or so compatibility with the Python core language, uh, that they've gotten so far with it. And I guess I shouldn't really say they, uh, it's really just one person who created micro Python initially, uh, Damian George, uh, he's actually from Australia. I forget exactly where, but somewhere in Australia these days. Uh, and so he's a really cool guy. There are a couple of videos out there of a talk that he's done a few times at different Python conferences. So you can search for those and see where he just talks through a lot of his motivations and goes into more detail about how he actually got Python to fit, you know, in these small memory constrained environments. Uh, but that, so that's the big difference is that, you know, it's, it's a new implementation. He didn't just take the C Python code from the desktop Python and just port it over to work on, uh, other processors. The, the other big difference too, is that it can run in kind of these bare metal environments where you don't have an operating system. So you don't have the typical kind of like Linux system calls and things that you might want to have available.

Chris Gammell: Which requires memory management and stuff like that, right?

MicroPython: Exactly. Or it might just even limit you because, you know, like in a Cortex M processor, you're not going to be running a full operating system on necessarily.

Chris Gammell: So yeah. Cause I guess you could these days, I mean, you could just get a BeagleBone Black or something like that and just run regular Python on it, right? That's not. Oh yeah, exactly. That's, that's kind of the modus operandi of processing on there anyways. As far as I've seen Adafruit has a bunch of tutorials about that too, right? Yeah.

MicroPython: Or even just like a Raspberry Pi, like the Pi zero, you know, tiny little Linux computer. And I'm sure like this time next year we'll be like covered in more tiny little Linux computers and things, you know, uh, small processors. And that's a perfectly valid option though, too. You know, if you want to do Python stuff on, uh, embedded or small systems, sure. Like a Linux running or a real kind of desktop operating system running machine is, is an option. It's, you're going to pay more for it probably with like power consumption. And maybe costs and things. Uh, but it is something to think about too, is, you know, maybe another extreme of when you need more power, uh, potentially or more memory.

Chris Gammell: So what, what is, what is the relative, can you give us an idea of relative size? Like, so maybe just giving it in, well, I guess you could, you could talk about it in memory, but also just talking about it in processors would be the easiest thing.

MicroPython: Right. So some of those processors that MicroPython runs on would be interesting. So the very first board that it was made for, uh, something called the Pi board, and it's a Cortex M4. It's an STM chip, uh, if I remember correctly. And so it's a pretty beefy, um, uh, processor. I forget exactly how much memory, uh, it has, but you know, more than I'm guessing like at least like 64 K or, uh, yeah, it's got 32, 64, 128.

Dave Jones: Is that order?

MicroPython: Right. Yep. So pretty decent size, uh, uh, processor for that, but certainly not big enough to run like a real operating system or a Linux or, you know, something like that. Uh, so that's kind of the first processor. And then, uh, the ESP 8266 came along, which is like the really popular wifi microcontroller from Espressif. Just kind of took off last year and people found that you could port MicroPython to that. Uh, they actually did a Kickstarter, had a bunch of success with that. And so that again is a relatively fast processor. I think it's like 84 megahertz, like 96 kilobytes of memory. So decent size. Uh, but a really interesting thing on the low end, they actually got MicroPython to run on the BBC micro bit, which is this tiny little, uh, computer that every, I think seventh grader in England received. And so it was kind of a initiative from the governor, uh, government to say, okay, we want to get more computer science education. And so every kid gets to have one of these little boards to learn with. And initially I think that was meant to run, uh, just kind of bare metal, like C Arduino kind of style code, but they got MicroPython to run on that. And that's an NRF 51, if I remember correctly, which only has 16 kilobytes of memory. And I can't remember exactly the processor speed that it runs at, but pretty impressive that they got Python to run just in that 16 K of memory. And apparently when you do have a program that runs there, you only have around four kilobytes of memory. Yeah.

Dave Jones: I was going to say how much left. Right.

MicroPython: You're not going to be doing a whole lot of things with that, but it's still for, for learning for, you know, showing someone like, okay, here's how you blink an LED or here's how you maybe make like, uh, you know, a relay activator or something like that. That's just a few kilobytes is really all you need to do stuff like that. That's great.

Dave Jones: Now comes the question, like, why? Why do that instance C? We don't get into that now. Yeah, yeah, yeah. Sure, sure.

Chris Gammell: We're going to get a couple more questions in before we go deep. Yeah.

Dave Jones: All right. Well, what other processes is it available on by the way? Like, does it, you mentioned Arduino before, is it available on an 8-bit, um, an 8-bit Yeah.

MicroPython: Great question. So no, not that I've seen, uh, I don't know of an AVR implementation for those kinds of 8 or 16-bit processors. Uh, it does run on the CC3100, I believe that's the Wi-Fi. Yep. Uh, and so that's a nice little processor. Uh, and then we're actually working at 8-bit.

Dave Jones: That's a TI one, isn't it?

MicroPython: A TI, exactly. Yeah. Yeah. Uh, and then we're working on, uh, the Atmel, the SAMD21, which is a Cortex-M0. So it's kind of similar to the microbit. That's a Cortex-M0 that the microbit had. Uh, the SAMD is just an Atmel's version of a Cortex-M0, uh, really popular. Like, you're starting to see that in a lot more boards and chips and things, uh, these days. Uh, but it's also kind of a lower-end chip. So this one, uh, ours, the one we're using has 32 kilobytes of memory, um, and, uh, runs at 48 megahertz, I want to say. So we're kind of, you know, shooting for that lower end, um, because that's maybe makes it a little more accessible to people. You know, it'll be less cost, um, less capabilities, but also if you can get more boards out there that people are using, it'll be more interesting.

Chris Gammell: So this is right up front. So this is a constrained list, right? There's what, six or seven on this list right here. So unless someone's willing to port MicroPython themselves and the processor has sufficient memory, you are constrained to a subset of all boards out there, right? I mean, that is an important thing to know up front. Definitely. Yep.

MicroPython: And they are actually working on, um, I believe there's a port for some of these new, uh, I don't want to necessarily say RTOS is, but like Zephyr and Minutes and some of these, uh, you know, higher level abstractions, uh, like HALs, like a common HAL across a whole bunch of chips. I believe they've got, they have a Zephyr port that's kind of in progress. And so that might open it up to more boards and more chips because, you know, in theory, if any board supports like Zephyr or some of these other operating systems.

Dave Jones: I haven't heard of any of these. Too many. Stop it. Yeah, exactly. They're kind of new.

MicroPython: I think Zephyr is like from the Linux foundation and Minutes, I think it's from Apache. So if you haven't heard of them, you'll hear about them soon, I bet. So, yeah.

Dave Jones: I don't want to hear about them. Right, right. Dave, you're not going to use it. You and I will not be using that stuff.

Chris Gammell: We'll be fine. So, so here's my question then. Okay. So now, okay. So there's six boards, seven boards listed here, whatever. Uh, does that mean now that if I pull in any normal Python code and I properly map a pin and the, uh, the underlying resources, like, uh, if there's a, uh, I squared C macro or some kind of hardware piece is there and is mapped any Python code that I import should pretty much work. Is that, is that a fair statement or no?

MicroPython: Yeah. And so that's a great kind of point. Maybe the differences between like desktop and MicroPython also. So, you know, the syntax of the core Python language is exactly the same. So if you wanted to blink an led in a loop, you know, you would write a loop exactly the same way you would do it in normal Python. Uh, but where some of the differences come in are with the libraries, because that's another big thing that desktop Python is known for. They call it batteries included where in the standard Python library, there's pretty much a module for everything. So if you want to go talk to your email server and download all of the, uh, email over like the IMAP protocol and process those and do certain things, almost all of that stuff is in the standard library. But it's really hard to fit all that into MicroPython because again, you're running on these tiny chips.

Dave Jones: I was going to say what, yeah. Does anyone who implements a new version, do they include everything or do they just include the stuff that they want? And then you miss out.

MicroPython: Ideally, when you implement a new version, you really just have to implement, uh, the access to your hardware because that's always going to be specific to your chip. You've got to have all your peripheral access.

Dave Jones: So you've got to have IO, you've got to have I squared C, SPI. Exactly.

MicroPython: You've got to have, you know, basic access to that stuff. USB. Right. And then there are libraries on top of that that are relatively common and can be shared across the board. So, uh, for example, like JSON, uh, the data format, that kind of parsing that doesn't even involve IO. Uh, so there's like a module built into MicroPython for that. And so all of the ports can use that, uh, for other types of processing. Like if you want to talk to a web service, uh, there's a library called requests in Python. That's really popular. And so they have a port of that to MicroPython. And so this is something kind of on their GitHub repository. They have this MicroPython library, uh, repository where they're putting all of this common code where you can pick and choose, you know, you might be more limited and maybe you can only fit so many libraries onto your board and your chip. So you choose, okay, yeah, I'm going to talk to web service. So I need this web service library and maybe the JSON processing. And I pull those in as modules into my, uh, code and use them from there. So it's a little bit different. Whereas in like the desktop Python world, it's just there and available and you just use it and go crazy with it.

Chris Gammell: So what about if I, okay, so the JSON is a great example, right? Cause a lot of people use that for, for web processing of like being able to pull out, you know, it's like key value pair, right? That's how a lot of that stuff works. So it would be like temperature 25 C, right? That would be like key value pair. Um, so if I wanted to implement that and see though, that would be a lot harder. Cause then I'd have to go like, I'd have to manually, are there similarly like C libraries that can do that same kind of thing? Cause like I'm, I'm never doing that kind of stuff anyways. That's what I'm really getting at.

MicroPython: It's, it's a lot easier in Python because in Python you have a native dictionary type. So a dictionary is like a name value store. You know, I have an object and I want to put like a temperature inside of it. And so I can assign a position in that dictionary of, you know, this is called temperature and here's the current value, which maybe it's a floating point value, or maybe it's a whole other object. Um, it's really easy and just a few lines of code to do that. And that's really nice too. And that when you parse JSON in Python, it effectively just turns this string of, uh, that data that you might've gotten from a web service request into a dictionary that you just immediately start operating on. Whereas if you want to do that in C, you're probably going to want to find a library. Like you could write your own JSON parser, but then, you know, make sure that you're checking all the links of your buffers. Yeah. That you're doing any kind of text processing. It's always fun. Uh, but it's going to be a little bit more different in the syntax. You know, I haven't used a lot of the C JSON libraries, but usually it's a very verbose kind of thing of you have to, uh, you know, process, initialize this thing and then start asking, okay, I've got this object. Does it have a temperature field inside of it? Yes or no. And then, okay, now pull out the value of that as a floating point or something like that. So it just turns into more code, a little bit more complexity, uh, in some cases for it. Whereas, you know, a few lines of Python might be like 10 or 20 lines of C code potentially to, to get the same result. Huh? Yeah.

Chris Gammell: So it's possible in both, but it's just easy. It's just less over, well, more overhead, but less, uh, less details that you have to implement yourself in Python. Is that right?

MicroPython: Exactly.

Chris Gammell: Yeah.

MicroPython: So it's just, you know, simpler syntax, less code that you might have to write, uh, makes it, uh, simpler to maintain potentially for it and easier to learn too. You know, if it's just a few lines of code to talk to web service, then that's a lot simpler than maybe explaining to someone, okay, here's how you initialize all these objects and how to, you know, fire off these requests.

Chris Gammell: I think this is why it tickled my brain in the first place. This whole idea is because, okay, so like hackathons, right? The thing for me at hackathons is you get people coming in who are doing like JavaScript stuff on the web and they're like, okay, what, what, what libraries are out there? What can we use? Let's look at the APIs and just implement it. Right. And that's great. Right. And that allows you to really quickly prototype things and, and put things together and then focus more on the design aspect and stuff like that in hard, like I think about doing that for hardware. It's like, oh, well crap. I got to like, you know, figure out all the low level processing stuff, make sure all that stuff works. And it's, you know, with, with an, uh, Arduino or something like it is possible, but it's not necessarily, uh, it doesn't seem like it's quite as elegant either. Right. So like you thinking now comparing Arduino and, and Python, you know, it's similar in that it's, it's high level. It's, it's easy to read and stuff like that, but it doesn't seem like there's as much stuff there. Maybe you can compare those two. I don't know.

Dave Jones: Yeah. Well, and that's, that's C, but the one thing there, Chris, is that's, uh, the, the Arduino language is C. Right. It is compiled C.

Chris Gammell: Correct. Yeah. Right. So it has you to go to like a lower language.

Dave Jones: It's just, it just uses libraries. It just uses C libraries. That's, you know, it, but it does actually compile. It's not interpreted or anything else.

MicroPython: Arduino opened up electronics to a lot of beginners, like people that wouldn't really know how to set up an AVR GCC tool chain to compile code, to run on these little processors. Yeah. It made it really simple. You just download the IDE, you open it up, you type in your code, you press upload, and it pushes out to the board. And MicroPython, I think we'll make it a little bit easier and even open it up to more people because, uh, with MicroPython, since it's an interpreted language, it gives you a lot of flexibility so that you can actually run code without having to compile it. So you don't need to have this whole compiler set up. You don't have to have a whole IDE even connected to this. You can just open a serial connection that talks to your board, like over a USB to serial connection and, uh, get a prompt that just lets you type in Python code. And so they call it a REPL in the Python world, R-E-P-L, a read, evaluate, print loop. And that's basically just a Python prompt. So you type in Python code, you press enter.

Dave Jones: Why do these call it a Python prompt?

MicroPython: Uh, good question. I don't know. Everything has to be complex. So yeah, it has to have a fancy acronym. Uh, so you can get that REPL though. And as a beginner, that's really nice because you connect to your board. You don't have to worry about, okay, I have to go find all this software. Uh, and even in the Arduino world, it's a little more complex usually because you might want to use like a piece of hardware. And so you have to go find the library for that and then how to install that library. Uh, whereas with MicroPython, just connect to the board, start typing in some commands. Like you could just do the basics, you know, print hello world. And it'll do that. But you can also say, okay, I want to create an I squared C device. And now I want to maybe read a register or write some data to it and go from there with it. So that's kind of cool that it's something you can't really do with an Arduino or some of these platforms where you have to compile that code ahead of time and push it out to the board. You know, this gives you a lot more flexibility to just play with the hardware and experiment with it. Uh, and see how it goes there.

Chris Gammell: It kind of reminds me of actually like Dave brought up is kind of reminds me of basic where you could write, you could write a program in basic, but you could also just, you know, 10, 10, go to whatever, you know, like you just. Yeah, exactly.

MicroPython: Exactly. And that's, that's maybe the fun of it too. Uh, you know, as you get in and start playing with it, it's, it gives you that kind of sense. Like actually Q basic was the first language I learned how to program on. And so it's, it's, it's fun to come back and it's like, well, you know, Python isn't so different from that. It's, you know, it's like different syntax, but it's the same kind of fun.

Dave Jones: It gives you that immediate feedback. So you can just go, you know, I equals 10 and you don't have to put, and then it assigns that and knows that's a variable and it assigns it. Does that, does it work immediately? Like, and then you can go print a, does that?

MicroPython: Exactly. Yep. You can do that. So there's a whole global state and you can, you know, create variables and they'll stay inside of there. You can make functions, uh, cause Python's a very dynamic language. You can make classes at the REPL, uh, anything you can do with Python code. You can just type it in there and go from, uh, yeah, it's very basic like, yeah.

Chris Gammell: I was, I was just, I was following Tony's tutorials today and I had it plugged into a little led shield and it was really nice because, or they called feathers, I guess, for a fruit, right? Right. Yeah. The feather kind of form factor. Yeah. And it was just like, Oh, I have, I have it here. What does it say? It was, uh, uh, display dot fill and then zero in brackets and then display dot, dot fill with one 27 in brackets. And that just turned the whole whole display on the way, all the way on, all the way off real simple. Right. And it was just, just those two lines allowed me to toggle the whole thing on and off and get immediate feedback. So that was really cool.

MicroPython: Exactly. Yeah. And so that's where we think with beginners, especially it's going to be super powerful and super compelling, uh, because we've also gotten a lot of feedback from people that have used Arduino, uh, and tell us, you know, Hey, I did a workshop. And the first hour was just explaining to people how to install the software and how to get it set up and how to connect the boards. And so if you can get rid of some of that stuff, just get right to the meat of, okay, here's how you control an led or here's how, you know, you talk to this device, then that's going to make it more interesting to people. Uh, you know, you'll get less people tuning out and just rolling their eyes of, okay, this is way too complex. Uh, so, you know, we're excited about that, but on the flip side too, like micro Python is also a pretty capable language. And so maybe something interesting to talk about is, uh, especially around combining both C and Python code. And that's, I definitely, I definitely want to talk about that.

Dave Jones: Can you do it? Can you do inline code? Wait, wait, wait. Inline C? Yeah, yeah.

Chris Gammell: This is a huge discussion. I definitely want to talk about this, but I think that the thing I just wanted to bring up real quick is just that the, the prototyping piece, right? Because we were talking about that already, like the immediate feedback stuff. I ended up started doing that just with an Arduino anyways, right? Because for, for, and, and actually I remember linear tech, they started developing Arduino shields for their parts, which is like, that's really weird. But, uh, I didn't expect linear tech to do that, but yeah, yeah, no, but like, that's great. Right. Because it's just like immediately being able to kind of peek and poke at registers on a, on a ADC or something like that for someone like me, that's all I need, right? I just need to be able to pull data back out of an ADC. I'll put all the front end stuff in front of it, whatever. I just need to quickly get the data stream and put it somewhere. And that seems like where this is exciting for a hardware person is quickly getting data streams out of, get it, getting out of the heart, getting it out of the digital realm and into something that makes sense for me as quick as possible.

MicroPython: Right. Yeah. And being able to process that data, you know, and having even like a lot of libraries and things to use, uh, can make it more interesting. So yeah, totally. You know, even if you aren't a beginner, uh, could be useful. And like you said, the, the hack, uh, hackathon kind of scenario, that's a perfect example too of like, sure. Maybe if I wanted, I could spin my own board and like bring this whole thing up bare metal, but you know, we've got 24 hours. And so I've got a MicroPython board and I can just start throwing some code on there and evolving it and making it work as we go with it. So, you know, uh, a speed or just the, the ability to get started faster, uh, is useful in a lot of cases. Yeah, definitely. Okay.

Chris Gammell: So, okay. So sorry. I, I had, I had to say my piece there, uh, C and Python interoperability then. So, yeah.

MicroPython: And so this is kind of the second kind of audience I would say for MicroPython. So the first is the true beginner, totally new to electronics. You know, the interactivity of a MicroPython is great for them, but for the more advanced users, I think there's a compelling case for MicroPython because it does allow you to mix C and Python code. So even like desktop Python is very good about letting you write, uh, functions and extensions in C that you can just call from your Python code and your Python code doesn't really even have to know that it's a C function. It just looks like a Python function. You pass in all the arguments the same way, but underneath, you know, you're actually running native code for that. And same exact thing happens with MicroPython. And actually, I mean, most of MicroPython stuff is implemented as C functions because you're going to access like your hardware, yeah, your registers, your peripherals. Uh, so you need to drop down and get low level access for that, but you can add your own functions and things, which gives you a bunch of flexibility so that, you know, maybe when you're developing some, uh, piece of hardware, you've got a lot of this high level logic of, and especially for devices today that are all like IOT, internet connected, your internet connected toaster or whatever, uh, that kind of thing, it needs to talk to web services. It needs to process all this data from those services, uh, do certain things like, you know, authentication with these services, which gets pretty complex and gets to be a lot of text processing. It's the kind of stuff that's not like critical real time. You know, you're not generating some kind of signal at a really fast rate. You're just doing this mundane processing. And that's the perfect type of thing that you could put into Python code. That's a little bit simpler, easier to, uh, write it, maybe easier to test it, easier to manage it. And then when you need to actually call in and talk to your specialized piece of hardware and, you know, generate that fast signal or do some real low level access, you add in the functions that you need to do that as extensions to MicroPython. So you create some C functions and there's a little bit of like a macro syntax to say, okay, here's my C function. And here's how it can take in parameters from Python and what it expects and that type of stuff. Uh, but you do that implementation and then your Python code can call into it and say, okay, now go talk to my special hardware, do my magic thing. Um, in this case. And so that's a cool area that I, uh, hasn't been explored a whole lot yet, but I think you're going to see a lot more of that with MicroPython as it kind of catches on that people are doing this mix of like the low level and the high level where it makes sense. You know, you kind of pick like how low you want to go and how high you want to go with, uh, your, uh, your Python code for it.

Chris Gammell: So, yeah. Well, I think that the, I mean, so the piece that I would have seen in the past would like, if you wanted to add internet to something, right. Or say wifi specifically, right. You want to add wifi, what you could easily do is you could have, you know, a small micro or even Arduino or something, you know, uh, peeking and poking at registers on your ADC again. And then you're just interfacing that with a serial link link between the two, but basically now you can smush them together, right. So you can, you can have the same thing happening on a, on a capable chip, like the ESP8266 can handle the wifi piece, but then also has that low level access like you're talking about.

MicroPython: Right. Exactly. Yeah. So just put everything all in the same processor. Yeah. Where as before you might've broken it out into like dedicated things that's talked to each other, yeah, this could simplify it a lot so that you've got your main kind of business logic in Python and then talking to all your hardware where you need it.

Chris Gammell: Yeah. That's cool. What about like the, um, so I know the, the Adafruit NeoPixel library, uh, actually has stuff in assembly. And so can it do that as well? I mean, I mean, I guess that's kind of. Yeah. Great question. Right.

MicroPython: So you, you can drop down to assembly if you need to. Uh, I mean, ultimately you just have to be able to link in the code to, uh, your micro Python firmware. And, uh, as long as you've got it all set up the right way with all the, um, kind of, it has like a table of all the functions that make up an object, things like that. Uh, but there is actually a simplification and we don't use it yet. I think on our, uh, Sam D 21 micro Python port, but on the, uh, the PI board port, the, the STM, uh, port of micro Python, it does actually have the ability to write a Python function where you put a special decorator on it that says, okay, this is actually assembly language and you can write arm assembly language inside of that function. And it will compile that down into assembly when you, when it builds the firmware and will give you a nice optimized function. So it's a cool thing. It's, uh, I haven't seen a lot of people using it yet, but it's something to kind of explore there. And it's just neat to see that that's possible because yeah, like why shouldn't you be able to mix in assembly language? You know, if you're building the firmware.

Dave Jones: Although C is reasonably close to assembly language. I know all the assembly language. You're fishing on those will jump down my throat, but you know, it's good enough. Someone's about to talk about milliseconds, Dave. They're going to talk about milliseconds. Yeah. Yeah. Microseconds, whatever. Flight of the moon in milliseconds.

Chris Gammell: About that, Tony. So you said it compiles down though. So like, does that mean that it's, so the assembly piece that's happening, it has to happen before. Right.

MicroPython: And so this is, you actually have to build the micro Python firmware, uh, and it will do kind of like a pre-processing step to say, okay, these are certain Python functions that are tagged as assembly implementations. And so now I'm going to actually do some extra steps to say, okay, let's actually turn this into assembly and, you know, make sure that it works with the chip and linking it and things like that. So yeah, it's not something where you can actually do at the Python REPL typing in, you know, the assembly code and creating that object, at least as far as I know right now, who knows, they might be adding stuff like that in the future. Uh, but yeah, it's, it's, it's like a pre-step for the, the firmware building. Gotcha.

Chris Gammell: Okay. Okay. So that would be that that's definitely hard mode, like advanced user kind of stuff. Yeah.

MicroPython: If you want to go crazy, but like Dave said, in most cases, C is probably good enough. And you know, that's also like something that you have to build a new firmware to add that capability. And so, you know, when I say building new micro Python firmware, like you basically just have to clone their code, you know, and get it set up and you pop out a new firmware image, uh, but in their code. So you add in your functions there and it will, it has it all set up to build those as kind of extension functions and things.

Chris Gammell: So it's like a black box. Like the C code would be like a black box. It's, uh, like the, the high level function would be like talk to ADC or some name like that. And it would just, you just pass it in and then it all happens.

MicroPython: And NeoPixel is a great example. So like we added that to our SamD 21 port and we literally just took the Arduino NeoPixel code for the SamD processor, which was, uh, actually, uh, there is a little bit of assembly in that one. It's, uh, it's just using like the GC inline assembly. Uh, and so we just took that function and put it into basically the signature that micro Python needs for, uh, a function and plugged it in and pretty much worked. I mean, there's a little bit of kind of tweaking. I think you have to turn off interrupts. Uh, we had to add to that, but otherwise, yeah, it was a pretty straightforward port. And that's what most people I think are going to do where you've got, you know, something you want to talk to with a low level. You just add a C function for it and then build your firmware for that, load your firmware and call it from your Python code.

Chris Gammell: So excuse my ignorance on this, but like what would actually be building that firmware then?

MicroPython: Yeah. So that's like building a new version of micro Python, which, which sounds kind of scary, but I mean, you basically, you've got the source code of micro Python. And by the way, it's all, it's an open source project. It's MIT licensed. Uh, so really nice to be used. So you pull down that source code and then you add in like a new module, like a NeoPixel module, for example. So you make like a C file, uh, that has the code for your, uh, controlling your NeoPixel and it has certain functions. And there's certain macros that you have to include in there to tell Python, okay, you know, this C function should be exposed in this way to Python. And these are the parameters expects and things like that. Uh, and then you compile that whole micro Python firmware. And so that's going to compile like the core language, uh, all the core libraries that includes. And then it's also going to include the new code that you add. It's like the NeoPixel module. And then that'll just pop out a dot bin file that, uh, you'll want to load on your board effectively and say, okay, this is the new firmware that bunches bare metal on my processor. And so that's, you know, basically a new version of micro Python. And now when you connect to the Python repl, you can say, okay, NeoPixel, like change color or whatever you've added to. Right.

Chris Gammell: So it kind of, it abstracts it out sort of, but not really. It's all just, it's just really the repl is, is a layer that looks like a programming interface, but it's actually part of the firmware that just looks like.

MicroPython: You're just running code. And if you really want to get down to a low level, um, micro Python, I believe it's a little virtual machine that it has internally. And so that repl is really just like taking in the Python code, parsing it, figuring out the abstract syntax tree, and just executing that against a little VM that it has internally for that. And versus like, if you have a Python script that you want to run and you can save to the board, uh, you know, that it'll just process that and generate the same tree and actually execute it against the VM for that. So yeah, as far as micro Python is concerned, it's no different. All of those functions that you've added are just extra things that, uh, other code might be calling.

Dave Jones: Right. If you make one small change to your Python code, it doesn't have to recompile everything else as the image for your board.

MicroPython: Yeah. Great question. And so that's maybe a difference of, um, you know, what are you changing? Like if you're just changing your Python code, your .py file, uh, then yeah, you don't have to rebuild the firmware. And that's actually one cool thing too, that I didn't really mention with micro Python is that all of the boards support a file system internally, like a fat file system.

Dave Jones: I would, right. That's great. That's maybe the missing piece. So it's a fat file system in memory. In flash memory. Exactly. Yeah. In flash memory. Right.

MicroPython: And it doesn't have to be there necessarily. So like we're looking at maybe an external flash or you can even mount an SD card on some boards. Yeah. Flash. Yeah.

Chris Gammell: For like data logging stuff would be great.

MicroPython: And that's usually where you plug in all of your Python scripts and your code, uh, that's, you know, actually written in Python. And then your firmware itself is, yeah, the, the actual thing that runs on the chip itself. And so that's gotta be in its flash memory, but that's, you know, usually you aren't changing that as much as you are your Python code. And so, yeah, when you change your Python code, you just effectively change that Python file. And there are certain conventions in MicroPython, like if you have a file that's called main.py, then that's kind of your main code that it will run after it boots up or after it starts up. Right. So that's how you can have, you know, I want my script to start immediately. You put it into that main.py file. Yeah. But it is nice too, in that you've got a full file system and in Python, it has a whole concept of you can split up code across multiple files. You can import other files to say, okay, I, you know, I have a class in one file. So I want to import that module and start using it. And it works exactly the same in MicroPython. So if you want to structure your code and have a whole bunch of different files and put different things into different files, you can just use them and import them like you would in normal Python, which is pretty cool. Kind of an interesting thing because again, you don't really have anything like that in the Arduino world where like you're just building this project ahead of time and you can't really change it without changing the whole file and re-uploading it, for example. Yeah. Cause it gets bigger.

Dave Jones: Can you have multiple programs in there? So you can call up when you boot your program, like depending on a pin configuration, can you run a physically different Python program?

MicroPython: Do something else? Yeah, you definitely could. Something like that? You want to structure it in a little bit of a different way. Like there's only one main.py file. And so that's going to be your entry point.

Dave Jones: I was going to say, right, there's one main. So you'd have to do that. But then you can call up another file. How do you call it?

MicroPython: Exactly how you would with Python. So Python has an import function. Well, I, yeah, exactly right. So step one, get a little background Python. Exactly. But that's kind of the cool thing with MicroPython is that once you learn Python, most of that knowledge transfers over. And so then in the Python world, yeah, there's an import command, which Python has this whole complex hierarchy of it will look at its built-in libraries and then it'll look at like third party libraries. And then if it can't find anything there, it'll look actually in the local directory to see if there's a .py file with the same name and then it'll pull it in. And so some of that stuff still works. So you would call up a file.

Dave Jones: So you would go import file name. Exactly.

MicroPython: You call it program1.py and program2.py. Yeah, exactly. Let's say we had a neopixel.py file. You know, you would just say import neopixel and that will tell MicroPython, okay, go look for a file called neopixel.py and load it up and see what's inside of there. So like if there's a class inside of there, there's maybe even just function or global variables or things, it will load those and make those available. And then Python has a really good concept of namespaces so that it won't just throw all of that into your global namespace. It'll prefix that with like neopixel. So if I had like a neopixel.light function inside of there in my script, in my main.py, I'd say import neopixel and then neopixel.light. And that would say, okay, call the light function inside of the neopixel module from there. And so...

Dave Jones: So you could have several different modules each with a routine called print. Exactly, yep. And then pick the right one. And then it'd be a pixel print. It'd be something else printed. Exactly, yep.

Chris Gammell: Got it. That's cool. Nice. Somebody's been thinking. Yeah, that's... I mean, again, to go back to the ADC example, I think that if you... So once you... The interesting thing about that is once you have that lower level firmware figured out, then I imagine that you could kind of hand it off to someone, say... I imagine like, you know, someone who's more data savvy and then basically, you know, be like, all right, I figured out how to peek and poke all the registers in the ADC. I've got the data coming out. Do your magic. You know, make this... You know, format this data well. Push it up to the network however you need to do it. And then there's some interesting... You know, you could really get to the data pieces, which is what a lot of people really want to do, right? I mean, as much as we talk about electronics on here, and we love electronics, it's really that people are trying to get something out. And a lot of times it's data, especially in the IoT world.

MicroPython: Yeah, no, exactly. And again, it just kind of comes back to like making it easier for people who haven't done a lot of this and don't have a lot of experience with like microcontrollers, microprocessing. It's just, it's simpler to get started with this. Less scary, I would say, you know?

Chris Gammell: I would say it's even easier to maintain all this stuff. Like, so I'm sure we're going to hear from people that are staunch C people and that's fine, right? But like, I mean, a lot of this data handling stuff, it just seems like it would be a much bigger problem to solve and maintain over time, right? And it'd be less flexible if you needed to change something or you'd have to change the whole image at that point. Right. Yeah. And that seems like that's where it's really interesting to me.

MicroPython: Right. Yeah. Just having the flexibility. And the nice thing is too, like if you want to prototype that code on your desktop computer, you can just use normal Python. You know, you can write all of that out, maybe mock all the different interfaces, get it working there. You can maybe have a really nice test suite and then just take that code, port it over to your microcontroller running MicroPython. And for the most part, you know, it should work exactly the same as your normal environment. You still want to test it, obviously, on your hardware. But that's another kind of interesting case too of, right, you know, you aren't limited so much to just always having to do this in C and against this like constrained environment. Yeah.

Dave Jones: But having said all this, it's, you know, there's no one universal best programming tool. It's like if you're familiar with programming Python on the desktop, it's natural. You're going to want to use Python on an embedded platform. If you're a, you know, a C person, you're going to be, you're going to be familiar with C. Basic, you're going to be familiar with Basic, et cetera.

MicroPython: Yeah, I totally agree with that. I think that's a great way to put it is, you know, like MicroPython isn't out there to replace C. You know, it's not trying to be like the new language that everyone uses. It's just another tool in the toolbox, like you said. And, you know, I think it has good use cases for the beginner and even the advanced users. But yeah, it's perfectly fine to evaluate and say like, oh, it's not the right tool for this job. You know, it's maybe not capable enough or I need more performance or, you know, it does use a lot more memory and there is more overhead when you're doing an interpretive language like that. So yeah, there's certainly cases where it's not going to make sense to use it.

Chris Gammell: Can we go back to the compilation one more time real quick? I was just a little confused about, okay, so you said it can do assembly or it can do C and you have to recompile the actual dot, the binary image. The firmware for it, yeah. Yeah. So does that mean though that that piece is done with Python or it's then calling GCC or it's calling some other compiler? What is actually happening there?

MicroPython: Yeah, I'm not exactly, I can't remember exactly how they did that actual inline assembly. So there's a great talk that Damian George, the creator of MicroPython did, where he went into more detail about this. And it's a more advanced feature. I don't think they're actually invoking GCC. I think he actually just has a, effectively, I think he wrote like a real simple compiler that just takes, you know, that op code and just converts it into, okay, this is, you know, the binary equivalent of that, that I should make, you know, the language. Oh, really? For the C code though, it is using GCC because you're basically, like GCC itself is building the MicroPython firmware. And so when you add a function in C, you're basically just pointing GCC at, okay, here's all the MicroPython firmware. And then here's my extra .c files that have my, you know, new modules that I added. And so it's compiling that just as if it was compiling the rest of MicroPython. So you do use GCC in that case. Yeah, because at a certain point, it needs to know what processor is there, right?

Chris Gammell: You need to have something that understands which processor you're talking to.

Dave Jones: Everything defaults back to GCC. Exactly, yeah. I mean, that's what's doing the whole business. Okay. That makes a lot of sense then.

Chris Gammell: That's great. So some of that might be abstracted from you when you're doing the compilation process, but it's still under the hood.

Dave Jones: That's like the Arduino thing works exactly the same way. Exactly, that's true. People don't realize that they're using GCC because it's all handled by the nice little GUI and everything else. And you go, you know, download, you know, but it's actually calling GCC. Turn on Verbose. Yep, exactly.

MicroPython: Turn on Verbose and see all of the things happening behind the scenes. Right.

Dave Jones: Yep.

MicroPython: Okay. Okay.

Dave Jones: Now, what it comes down to, though, at the end of the day, when you want to get something done with your embedded platform, the language doesn't matter a rat's ass. It's what libraries are available. That is the pain point for getting stuff done on embedded platforms. So if you're trying to talk to the internet and your Arduino doesn't have a library that talks to the internet or your Python board doesn't have a library that talks to this or it doesn't talk to NeoPixels that you want to talk to or it doesn't talk to some accelerometer you want to talk to. That means you're writing it. Yeah, exactly. That means you're writing the damn thing or you're searching the internet to find if somebody else has written this library, you know, that you can sort of hack in there. And it's, you know, it's all about the stuff that's available.

Chris Gammell: Or you're talking to your firm or person very nicely and you're saying, hey, can you help me out?

MicroPython: Yeah, exactly. The library thing is definitely a big, important part of it. Just having, you know, access to, like you said, any hardware you want to talk to, having a library for it. And it's one interesting thing about MicroPython, though, is that it's still a pretty young project. So it was created originally in 2013. So it's about three years old. And that's pretty young in the scale of projects. Oh, yeah. Yeah, it's... Right.

Chris Gammell: As people are thumbing through their K&R copies right now. Right. Yeah.

MicroPython: So it's, you know, it's pretty darn mature as far as like the language. You know, I'm really impressed with how stable it is. I've used it a lot and haven't run into like weird head scratching. Like, wow, why did it crash there? Like, it's pretty stable. But things like library support are still kind of being figured out. So there's not, certainly not as many libraries as like Arduino and some of those other platforms. But they're coming. I think in the next year or so, we'll get a lot more things out there. And like, we're starting to do a bunch of libraries from the Adafruit side of just a lot of the hardware that we have. We want to make it easy for people to use in MicroPython. But yeah, that is also a good thing to look at when you're evaluating some of these languages. It's like, you know, what is out there? What can I use to get started with? And it's a little bit early right now with MicroPython. But the community is growing very fast, especially with the ESP8266 and some of these newer chips that have all this Wi-Fi capability. That's getting a lot of really interesting kind of projects and more people interested in it. And so we're pretty much every day just seeing new stuff coming out for it. It's, I think, going to continue going forward.

Chris Gammell: What about the, so like, okay, so say I go to write a library. So I got a new ADC and there's no library for it. And I want to go write it myself. Is there any reason to think it's any easier to write a library for here versus in C or any other language?

MicroPython: Yeah, good question. So to do it in MicroPython, it's a little bit interesting. So ultimately, you need to talk to your hardware. And there are APIs in the MicroPython firmware for talking to like I2C devices or SPI or even just like digital I.O. and stuff like that. So if you can code against those interfaces, then you can use MicroPython entirely to talk to your hardware. But that assumes that your hardware doesn't have like maybe timing constraints, you know, where you have to do something really quickly. Because again, you know, if you're doing this in Python, it's going to be running in this virtual machine. It's interpreted. There's some overhead there. So it's not going to be as fast. So, but for a lot of devices, like if it's just a simple ADC, for example, you know, maybe you just want to get a reading and that's it. You don't care about like all kinds of continuous readings or things like that. It's probably good enough to just make a quick little I2C call to it, get your register back and then convert it into temperature or whatever and go from there with it. So you can definitely do that. The other tricky thing, though, with libraries is that how do you actually distribute them? Like how do people use them? Yeah. And that's still kind of being figured out. So in the Python world, they have this whole infrastructure called PIP, the Python Package Manager, or there's also PYPI. Aha.

Dave Jones: So you could submit your contribution to it. Yeah.

MicroPython: In the Python world. Exactly. So you can say like, you know, I created this really cool data processing library and I put it up on the Python Package Index. And then people with one little command on their computer can go and download it and start using it. And there isn't anything like that yet in MicroPython, but there is a lot of talk and there is some start to adding this PIP Package Manager to MicroPython. And so in the future, that might be something to look at and see, you know, what is out there is will there be a world where, okay, I want to talk to NeoPixel. So I just run a command and I get a NeoPixel module that downloads to my computer. Maybe I copy that onto my board and use it from there. So that could be maybe the future that they get to eventually with it. But even just in the interim, you know, most of the MicroPython libraries are just raw .py files that you can copy over to your board's file system and import them. And then they do have this concept of a .mpy file, which is basically the Python code, but pre-processed into that abstract syntax tree so that it's just storing the byte code. It's not storing the actual text of your program. So it's a little bit smaller. It doesn't have to load as much stuff in memory.

Dave Jones: It's kind of like a dynamic link library for the DLL type thing, except it's kind of. It's sort of like in the way that it's actually pre-compined.

MicroPython: Exactly. Yep. And so it just, it saves memory because again, they're always trying to focus on how to reduce the memory usage with it. And so that's kind of what we're doing right now with our libraries. You know, we have some libraries to control like the Charlie Flex LED display that Chris has. That's what I was using. Exactly.

Dave Jones: So, so here's a question. The, okay, so it's interpreted code, right? And it runs a little micro kernel inside that interprets your text thing. And it's saved as like a file operating system kind of thing. Is it actually saved as a text file? So if you include all the comments in your code, are they taking up space in your micro? They are, yeah. And actually, oh, that's evil.

MicroPython: And it's even kind of worse too.

Chris Gammell: It's easy to read though, Dave. You don't need a comment. Don't run anything. Yeah.

MicroPython: It's bad too. And that when you import that file. It's self-documented. Yeah. Yeah. Right. It's the dream. Yeah. Well, so actually two good things. So, but the first thing though is, yeah, it's, it's, it is bad in the sense that it's going to take up more flash memory. And when you import it, I believe right now it loads the entire file into RAM. And so, you know, yeah.

Dave Jones: So you've got to have the RAM for all your comments as well.

MicroPython: But that's, that's why they have the .mpy file because when you preprocess it.

Dave Jones: I'm starting to twitch just to lack of efficiency of this thing. I'm starting to.

Chris Gammell: No, here's the thing about this. Convulsive hits. Here's the point I wanted to make this whole time too. This is, the reason this is going to be successful in my opinion is because like this stuff isn't getting any more expensive. It's getting so much cheaper. Yes. Yeah, I know. Batteries are a big deal. But like the only thing that chip companies have left to do is give us more processing power and more, more RAM and more flash, right? That's all they can do to try and sell more chips. And that's what they're going to do. So yeah.

MicroPython: Power, sure. Definitely you will, yeah, start to see a lot more higher memory chips. But you don't have to live in a world where, you know, you are just only running that raw Python code. Like the, the preprocessing, like I mentioned, the .mpy files, that strips out the comments. That kind of boils it down to here's the core code. So you can work around those issues in some cases with that.

Chris Gammell: It kind of sounded like an infomercial. Like, are you, does your, does your Python code have too many comments? Right, there you go. Yeah, yeah.

Dave Jones: Instead of have comment bloat, you know. Do you suffer from comment bloat?

MicroPython: The flip side though is that it is actually kind of cool that you've got your script on the board in a text format.

Dave Jones: Right.

MicroPython: Because like in Arduino, for example, you open the Arduino IDE, you plug in your board, you don't really know what was the code that was running on it beforehand. Right.

Dave Jones: Oh, so you can list it. Can you go in via the command prompting you, whatever it's called, thingy, and then list your program?

MicroPython: You can, exactly. You can pull the file out. Oh, that's pretty sweet. And so, you know, a MicroPython Arduino IDE of the future might be pretty cool. You plug in your board and it just shows you, here is your program, and then you just start tweaking it, re-upload it, whatever, and go in there. So there's an open source card out right there, right? I mean, like, that's pretty great. Yeah, so it is kind of neat. I mean, it is, you know, it's good and bad, like you said.

Dave Jones: Unless you've got the pre-compiled libraries, right?

MicroPython: And then you don't get the code. But exactly right. The .mpy files, yeah, you're not going to be able to see with those.

Dave Jones: So if you're a real purist and you want to use the minimum amount of memory, et cetera, possible, then you're going to compile everything. You're going to write everything as routines, compile them all, and then just include.

Chris Gammell: Or you're probably not going to use MicroPython in the first place, right?

Dave Jones: Right, right, okay.

Chris Gammell: Yeah, yeah, or drop down to C functions if you need. Yeah, lots of options. What about the overhead stuff? I mean, how much – I don't really have – I mean, I don't have a feel. You said before that one of those processing things that had 16K on board and there was four left, so I assume 12K just to be running on the micro bit.

MicroPython: Yeah, yeah, and it kind of comes down to what features you want to turn on. So there's a lot of switches in the MicroPython firmware where you can add and remove different functionality. Like it has –

Dave Jones: Right, so if you've got floating point support or something, you can remove it.

MicroPython: You might be able to turn that on or like longer integers or things like that. So there are a lot of knobs to tweak with that. With the micro bit, I'm not super familiar with it, but I think they had to turn a lot of things off and just get it down to the core language. I suspect that. But it does kind of tell you that – String support.

Chris Gammell: We can tell that this is a .py file and that's about all we can do. Right, yeah.

MicroPython: Definitely limited. But it does kind of tell you that, yeah, like you can get it down to like just a few tens of kilobytes of overhead for that. On the other boards, I think – let's see, on our SAMD21, we have 32K of memory. We took 16K of that for the heap, which is kind of what Python uses, and then the rest is stack. And we haven't run into a ton of issues using that 16K on the heap. I think only a few kilobytes or so seem to be used by our MicroPython firmware right now. So it's not like you're paying a huge price for it, but there is certainly some overhead for having that up there.

Chris Gammell: Right, you're not going to be getting the same performance as you would if you were writing Assembly or even C probably because you have – there is some cost to it. Yep, exactly.

MicroPython: It's not free, but the advantage is – Right.

Chris Gammell: I mean, this seems like it's really – I mean, like I said, I think this is really targeted towards prototyping at the beginning, but that's what seems right to me where it's like you want to iterate fast. You want to try a bunch of different things. You want to get your data out and to some other thing to prototype with. You're not going to be using that as your – maybe a couple people will ship it in production, but probably you would pay to send it to – bring an embedded person in and tighten that whole thing up. Maybe, yeah.

MicroPython: I mean, it's a good question. It depends on how complex the thing is that you're trying to create with this. Like if it's just a simple thing that like talks to a web service and then maybe actuates something on some results, you might not have to drop down into low-level stuff for that. One kind of interesting thing related to that is MicroPython, the .org or the Damien and his project, I believe the ESA, the European Space Agency, is actually looking at MicroPython to use on satellites potentially in the future. Wow. And it was a little surprising to me to think like, wow, okay, they want to use like this newish project for this. But it kind of made sense because they like the idea with satellites that are out in space. You know, when they update the firmware, it's a very scary nail-biting process of like, oh, boy. Put the wrong bit when you're updating firmware. I hope all those bytes, yeah, get sent up there correctly. So they like the idea of having an interpreted language where you don't really need to change that firmware. You've got your Python core up there. But, okay, we want to change the satellite functionality a little bit. Let's upload a new file and then let it run that file and go from there. And not to say that that's necessarily any better. There's all kinds of other problems and things that might go wrong. But it is kind of cool. You know, that would be a good case of like you've got some product or something. And you want to change the functionality. And so it's a little bit easier when you've got a language that's just interpreting your code and able to swap out that code pretty easily.

Chris Gammell: So a firmware change, would that be so? It wouldn't be native, right? The easiest way to switch out firmware is to plug in.

MicroPython: Just change the Python code. Exactly.

Chris Gammell: Right. But in theory, it would be possible to load it into Flash, like a new firmware image into Flash. Like when people are doing like field updates. Exactly. Yeah. You totally could do that too. Same kind of thing, right? Yep. So NASA could still do the scary thing. But then for everyday operational stuff, they could do the easy thing. Exactly. Yep.

MicroPython: So it's nice to have that flexibility for it, which is also good too for beginners. Like all of the boards that support MicroPython, at least the Atmel, SamD, and the ESP, they also support Arduino. So it does give you a lot of options in that, okay, if you want to experiment with MicroPython, you can play with it. And then if you realize like, okay, this Python thing isn't for me, it's still an Arduino. You know, you can still use the Arduino IDE to program the board and like, you know, completely erase the MicroPython firmware and just run like your bare metal code on top of it. So you do have some options there too. The flexibility of, you know, if you want to use it or if you don't want to use it. Yeah.

Chris Gammell: So, okay. So the last thing I want to bring up was the ESP because I had tried using it. I had tried one before, but I didn't have, I didn't, I didn't get it working before. Not that that, that, that was on me. But, um, uh, finally, I, so I, I got this featherboard thingy with the ESP 8266 on it. Oh, the Huzzah, it's called. Is that right? Right. Yeah. The ESP 8266. Yep. And that was shockingly simple. Oh, that's good. Yeah. Yeah. I mean, so basically I got it. I, all I had to do is reprogram. So Tony has all these tutorials and we'll link to all of them. But, um, all I had to do was reprogram to get it, to get the firmware image updated, to put it on my network basically. And then it was right now I am talking to, there's a web repl, right? So that's the re-evaluate. What is it? The re-evaluate print. The prompt. Yeah. The command prompt. Yeah. The prompt. Yeah. Yeah. And, uh, super simple. Right. And so now I basically am just talking to a, a board with the Python interface. Exactly. Yep.

MicroPython: Over wifi.

Chris Gammell: The thing that really tripped me up was I didn't, I didn't realize, uh, I didn't have, I didn't, you know, it's just pretty much like just a web-based serial terminal, but I didn't have the, um, the library. And I thought, oh, I'm going to have to go like pull it off the other part of my desk and come plug it in, whatever, whatever, plug it into my computer, get the serial terminal up. And I'm like, oh no, there's actually a send to device. You could just send another library to it. Yeah.

MicroPython: You can copy files through the web-reple, which is a really nice, a handy thing. And again, it just goes onto the file system on the board. Um, you know, you can copy the library file, or if you had like a text file, you know, with maybe some data in it, you could copy that over. And then, you know, in your code to open that file, it's just like opening a file in Python. Like there's an open command, there's a read command, a write command, uh, to, to process it. So that's, uh, you know, another cool thing too, is just, you've, you've got files that you can put on there and you can use them in your program.

Chris Gammell: Yeah, no, that, that piece is, um, again, like this is, this is not new stuff for most people, I think. But I think that the reason that I've been so excited about this is it feels like it's very enabling for a hardware person like me, who I, I'm not going to take the time to, to do all the other stuff. You know, like people are like, oh, well you can do like a Lua server on an ESP, or you can, you know, you can talk to a, you know, you can set up a micro to talk to a, a secondary, um, wifi shield and talk to that. And it's like, yes, but this is, it feels really simple.

MicroPython: Just a few steps, right. Load the firmware and then connect to the REPL effectively and you're ready to go to start running code. Uh, and, and that's exactly why I think we like it so much, uh, at Adafruit because, you know, we want to help more people get interested in electronics. And we've just seen even with Arduino and that, you know, it's opened up a lot of doors to more people, but there's still a little hard. It's still challenging to get started with that stuff. And so, like you said, you know, just you plugged in the board, loaded the firmware and you've got Python code running on it. Uh, that's kind of the dream hopefully to get to, you know, making it that easy for people to play with electronics.

Chris Gammell: Well, that's the shift that I've been making too, is that no one wants to run code, right? No one wants to build electronics. No one wants to run code. No one wants to do most of that stuff. Well, not no one, but most people don't want to do that stuff. What they want to do is make a thing blink or make a motor move, right? I mean, they want the output or they want the data out of something, right? Out of a sensor. They don't care about the details and the closer you get people to there, once they can do it once, they're going to dig down and figure out how they can do it faster or better or in a, you know, a larger scale or something. And that is when they start learning electronics. Yeah, true, right. Like the gateway drug maybe of electronics. Exactly. Right. Yep. Yep. That's it. Yay, drugs. Dave, you got any other questions about this stuff? I'm sure I'm going to talk about it more.

Dave Jones: I'm all firmware to out and command prompt.

Chris Gammell: I thought we did pretty good this episode. We did.

Dave Jones: Considering that we know Jack all about Python. Yeah. I think we asked sensible questions, Chris. Well done us. Hey, hey.

MicroPython: The big question, are you going to go off and are you going to learn Python now? You know, did I sell it enough to you that this is something that, you know, you want to try out and experiment with?

Chris Gammell: No. No. I mean, no. I'm not going to go like sit down and learn Python.

Chris Gammell: Okay. But I'm going to use it as a tool. There you go. There you go.

Dave Jones: I might use it as a tool.

Chris Gammell: And that's where that's the same argument as before, right? Like someone tells me, someone hands me a book that says go learn Python. It's like, eh. Right. I've been handed that book a bunch of times. I don't have a project in mind. But when I need to go talk to a sensor or light up a thing, I will get that done. Very quick. Yeah. That's it. Yeah. Exactly. That's great. Well, we always love this. The stuff that Adafruit's doing. I'm glad that you're doing this stuff at Adafruit as well. That's, you know, you guys are doing a great job in the education and electronic space. We love you guys.

Dave Jones: Oh, excellent. Yeah. Keep it up. Thank you very much for joining us, Tony. It's been awesome. Oh, thank you. Yeah. Great to be here.

Chris Gammell: All right. Well, we'll keep looking out for new projects. And I'll probably be talking about this more in the show in the future and bugging Dave about it. So thanks again for being on the show. Excellent. Yeah. Thank you.

Dave Jones: Catch you next time.

Speaker ?: Bye. administered administered administered