Damien George Talks To Us About MicroPython

Hello, and welcome to podcast dot init. The podcast about Python and the people who make it great. We're recording today on June 29, 2015,

and your hosts as usual are Tobias Macy and Chris Patti.

You can follow us on Itunes, Stitcher, or TuneIn Radio, and please give us feedback. You can leave a review on Itunes,

contact us on Twitter, send an email to us at host@podcastandit.com,

or leave a comment on our show notes. And if you'd like, you can support the show by a donation

with details on our site at podcastandit.com.

Today, we're talking to Damien George, the creator of the MicroPython project. Damien, could you please introduce yourself?

Yeah. Hi. Thanks for having me on your show. I'm

a, I guess, physicist by

profession, but I did

my undergraduate, I studied computer engineering and physics and math. So I did a lot of software programming,

operating systems

level stuff, but also hardware based things like working with microcontrollers.

And and so I got a a computer engineering degree, which is sort of like a robotics degree,

and that was at the University of Melbourne in Australia and I also did a PhD in theoretical physics. So that's actually what I do at the moment, I study theoretical physics

and do research as a post doc into theoretical physics.

Right now, I'm at the University of Cambridge. And, yeah, it's really great. I like thinking about the world and how the world works, but I also like to get my hands dirty, and do a lot of programming and working with hardware and things like that.

So micro Python is just a side project for you?

Yeah. It started out as a side project, but it's grown into something quite large. I've always liked right programming languages. I think

a lot of people who get into computer science, when they discover programming languages

and actually making them, it's something that really captures people's

imagination and

people can get really passionate about the kind of language they like or that they use. Yeah. I don't know. It just gives you it gives you power when you when you actually can make your own language, and you can write it in just the way you want. It was always a hobby of mine to write languages,

and, you know, I never really had a big 1. There were all just hobby ones, but with MicroPython,

it was sort of rewriting

this existing Python. So So technically, it was something that I really enjoyed doing and just as a hobby or a side project to start with just to see if it was even possible

to get Python, which is such a dynamic language, to get it to fit on a microcontroller, which is very, very constrained in terms of RAM.

I bet. So as a perfect follow on to that, how did you get introduced to Python initially?

I guess it was during university when, we learned lots of languages back then. Like, we did our introductory courses in Haskell. We also learned c and Java

and c plus plus

and Python was there as well, just as, you know, you're encouraged to learn as many things as you can. We use Unix and we learn shell programming. So I guess I didn't actually do a course in Python, but it was just 1 of those things you pick up and you just you gradually get to learn the languages as you use it in, you know, in your studies and then in your hacking as well.

So is there a particular aspect of Python that made you decide to use that over some of the other languages that you learned in your courses or do you use it more prevalently than any of those other languages?

I really like c. I don't know why. I think it's because

maybe because it's low level and get to you get full access to the hardware and I like that. So I actually use c a lot a c plus plus a bit, but then Python is my choice of language when it comes to just banging out something quick,

or even, you know, relatively

large size and when you just want to express your thoughts in a much cleaner way and you're not worried about performance, then that's I'll choose Python for that.

So is there a particular problem that you're trying to solve when you first had the idea to create the MicroPython board and interpreter?

It was more of a technical challenge or I like programming, I like languages and I thought well, microcontrollers,

I have a lot of them lying around and I've used them for quite a long time and they these days are very sophisticated with microcontrollers you can buy and that means they're

difficult to fully utilize.

Especially if you have to write c with a really tiny microcontroller

from many years ago, you only had a 100 bytes of RAM and you only have a few instructions and it's quite simple to use. But nowadays, it's a full on ARM Processor

and we've got all these peripherals like I2C and SPI and buses

and DACs and ADCs and PWM

and timers and

to use all of these peripherals

requires a lot of programming

and to get the interrupts right and to get all of the low level things

correct on a microcontroller is actually very difficult. And sometimes you just want to get a microcontroller and make some light flash in response to some button press or maybe some wireless event

and you don't need or you don't want to spend

ages and ages

hacking at the low level.

You know, just like when you're on your PC and you just wanna write a quick script to do something,

you use Python. So you have a microcontroller

and you wanna quickly just do something,

with some motors and sensors and all

or or something you have lying around.

And I thought, you know, it would be good to have a language like Python to use on the microcontroller.

And I mean, the reason that I chose Python for this job was because it's well for 1, it's a great language and it's very popular and so

if you already know Python

then going to MicroPython, you already know half of the story. The only other thing you have to learn is how the hardware works. And from the other side, someone who knows a lot about hardware, but then in Python, it's easy to pick Python up and then they control all the stuff they already know. And Python also has lots of

really

nice features for programming on a microcontroller

which you might not sort of realize that bitwise operations like and and or and xor are there in Python as native operators

and that's what you use all the time on a microcontroller.

Python has a good separation between

integers and floating points, which is important

on the microcontroller

and it's procedural,

which is a good connection with when you're actually making something, you do A and B and C and events happen. So procedural language is good, but also with classes and object oriented, you can encapsulate like a server moves out with a class and then you have methods on that server to make it move. So I thought Python is actually it allows you to abstract very well

the hardware and it gives you good control

and it's very expressive.

So yes it was sort of a no brainer really and it's something that

it just fit really well and then the challenge of course is to see

what

actually fit when I wrote the language, so that was the funding.

And so are there certain aspects of the MicroPython

runtime that make it even easier to deal with some of the hardware concepts that might otherwise be more difficult to grasp like dealing

with interrupts or

figuring out which pins to interface with for a given output?

Yeah. So

for example with interrupts,

you can you can just register

a function to be called

when the interrupt occurs.

So you can say, okay, when this timer expires, I want you to call this function and that function could be like a lambda, anonymous function or it can be a class method or just normal function. So you can get the callback

when you have an interrupt, for example, it's just an event that gets fired by some external

event that is. So for example, if

a PIN goes high and low or a

because the switch has been pressed, then an interrupt will fire inside the microcontroller, and you can ask the ask MicroPython to call your function

when that interrupt occurs.

So in the video, you mentioned that MicroPython is a complete reimplementation

of Python optimized to run on the microcontroller.

How hard was it to create an alternative Python implementation?

Did you have hard decisions to make as to what to include given the limitations of the hardware? Well,

to start with, I just want to see if it was even possible. That meant writing the the Lexa the lexical analyzer to analyzer

to tokenize the input stream from the script, a parser to turn that into parse tree and then a compiler to turn into byte code and then the virtual machine and then the run time.

So all these things, I mean there could have been some hurdle where it just wasn't in the work for some reason. So I just to start with just a little proof of concept that I could actually get a REPL up and running a prompt on the board and that was the first goal and I didn't really

everything else was

secondary to that. Well, whether or not whether or not I had whether or not I had, you know, certain methods on dictionaries or strings,

that didn't really matter at that point until I could prove that the record would work. So it was yeah. I had to go through lots of sort of lots of tricks to get things to fit in RAM, you know,

stuffing integers into pointers

and things like that and in turning strings at appropriate moments,

trying to use as least RAM as possible. So the way the compiler works is once the parse tree is created,

it runs over that parse tree 4 different times and each time it collects

sort of information. So the first part

collects information about the symbols and then about the stack size

and then sort of does some more

manipulation and at the very end once it knows everything

and then you get the bytecode.

So it tries to be very efficient in RAM in that case and not to create unnecessary data structures

just use the 1 parse tree.

Then the bytecode is sort of a compressed version of see Python's bytecode

to make sure that it doesn't use much RAM, there's

lots and lots and lots of things are stored in read only memory

like on the flash and not on the ram. So all the inbuilt modules like the system,

OS and modules like that, they're all pre compiled and pre sort of ready to run

from read only memory. So when you import sys, it doesn't take up any RAM because it's already there and you can run all the sys

functions.

So all these things are done, all these tricks are taken

in order to minimize the RAM usage And actually as a consequence it makes it efficient as well because when you import something there's nothing to do. It just says, okay, I've imported this module but it's already been initialized. So it,

I mean it runs relatively efficiently and that was another thing. A microcontroller is not as powerful as a PC so you can't

just hold lots of resources to compute things. So it's a very fine trade off between

making it run efficiently, making it run without RAM

and also making it run without using up too much code space. So you're really constrained from lots and lots of different directions

and a lot of the time when you're designing

parts of the code, you have to make a trade off. So I could make it run faster and more efficiently but I might need to use more codespace or I could use less RAM, but I might need more codespace to do the compression

or I could use more RAM

and have less codespace. So there's always a trade off between 1 of these 3 things, efficiency codespace and RAM usage.

And, yeah,

it's a pretty fine tuned

system

in order to run

efficiently and with minimal resource.

I bet. What is the total runtime

size of MicroPython,

you know, when you sort of first fire it up?

So you if if you ask about the RAM usage,

so you can you can get a prompt, a REPL prompt,

in

about 1 kilobyte of RAM. You can type sort of 1 plus 1 in about 2 kilobytes and it will be able to execute that. So that's

parsing, compiling to black code and executing.

And most of that RAM is used actually to create the parse tree

because you type 1 plus 1 and it gets through. But, yeah, I mean, that also actually includes,

a little bit of history in the repo. We even got test completion.

So

there's a lot just in 1 or 2 kilobytes. Yeah. But then if you go beyond that, if you want to write a script that's, you know, twin lines, you're going to need

a few maybe

5, 10 kilobytes to actually compile that and then have a chance to run it. But still, I mean, 5 or 10 kilobytes

is very very small compared to, I mean, c Python takes megabytes just to start up in

Motorola's internal. So yeah, it's pretty minimized. The hardware that we use, so that the microfiber,

it has

128 ks

ram which is used for the stack as well as the heap

and the data and VSS settings. But in $128, 000 total

RAM for everything,

you get an awful lot of room to play. You can I mean, you can create byte arrays that are 20 k long

without a problem? You can make lists that have 10, 000 elements in them. So

you've got a lot of room to play. There are other

boards that it could run on that have less RAM that have only, like, say 32 k of RAM.

A lot of effort has been going to minimizing the RAM and every time there's an extra addition,

it's really got to be

checked that it doesn't use more RAM or it doesn't use more stack or if it does, is it really worth it? So a lot of it's not just a project that you can

add stuff to because you want it. You've got to be like, okay,

is this feature really

gonna stay within the micro spirit? Is this feature,

unnecessary or is it really necessary?

So we do have to cut back occasionally and

it's not

a 100% Python because

you can't have you can't even, right? You can't have 100% Python running on the right controller. So what we try and do is say okay, you know let's try to fit 90%

of Python of the most useful parts

into micro Python. So it's still really as faithful as possible to Python and, you know, just feel like normal Python when you use it. Maybe there are some edge cases where things

don't work exactly if they're doing Python

or there's some missing features that are not there because they hardly ever use.

But we try and keep, we try and keep that to them and we try and make it work as well as possible.

So it's, you can get a script to run it on Python or on micro Python and it should work the same and if it doesn't, let me try and fix that when it does.

So it's important that it really does follow the the c Python specification.

So were there certain pieces of the standard library that you had to leave out because they weren't relevant or took up too much space to run on the MicroPython board?

Yeah. Well, there's lots of stuff that doesn't run on there for because it's a big or because it doesn't make sense to run on there. Like, I mean, you don't have or you you don't need.

But, yeah. And if you don't have any Internet connection, you don't have any this,

this in that library.

So a portion of the c Python standard library is ported to run on micro Python. Some of it just runs directly. You just take the c Python code and it works. Other parts, you sort of there's some built in modules that you need features for so they don't work directly. Things like NumPy, for example, that's not going to work because that's written in C specifically to CPython. So we would have to reimplement

NumPy if we want that to work. There are also big parts of it that are written in Fortran as well. And I imagine that you probably don't wanna try and get into the business of writing a Fortran interpreter as well. Yeah.

There's a lot of extra stuff you have to make. NumPy work is a lot, but it has to

but, yeah, I mean, if something's written in pure Python,

which relies only on models that are sort of working, then it should just work.

So that leads us into our next question. So I know that people who developed alternative Ruby implementations have run into issues due to the lack of a formal specification for that language. And has the fact that there is a specification for Python made your job easier?

Yeah. Definitely.

I think Python is very well defined

and a very yeah. It's a very robust language when you use it even though it's a high level script language. It is very robust because,

of operations

like, you know, integer division or or or truncation as opposed to integers. They're very well specified

to, you know, always have this particular behavior. And or for example, the modulus operation

where you take the remainder of the division. In in c, that has a certain specification, but in Python, it's slightly different and it's made slightly different so it's easy to use.

But it's very, very well specified

and that's very good because then you read the docs for C Python and I mean I shouldn't call it C Python, read the Python docs and you implement

as the doc say and then

it works and it matches c Python which is which is really good. So

for the most part,

all I have to do is just when I wanted to implement some really great features just read the

Python docs and just follow what they say. And most of the time you can get by just by doing that and you don't have to go into the c5 and soft code to see exactly what they meant.

You can sort of just forget about that the source code and just write it from the specs.

Also,

you make lots of tests and you're on those tests and

you get to micro Python and you make sure they match up, that's another way to definitely

that keeps

our code

running smoothly and we don't get hopefully any regression, but it was very good with the Python's documentation

to have such a formally specified language. And I think that's due part to the fact that it's got multiple implementation

like Iron Python.

So those those things lead it to to have a very good formal specification.

That's true. I mean, when you think about it, Python already has had a number of implementations

for quite a number of years, in Python and

PyPy and

Stackless, and and,

Jython, and all those guys. So so that's a really good point. The Ruby multiple implementations,

although they've been running for a few years now, aren't nearly as as mature.

So that has to help. The other people have already perhaps

smoothed out some of the rough edges for you.

Yeah. Well, we still find a few rough edges, but, they're not they're not common.

The Wi Fi chip seems like an interesting device. What are some ways in which it can be put to use? A MicroPython

cluster, for instance?

Yes. That would be 1 thing you could do. So the Wi Fi is a,

MicroPython

software

is a reimplementation of Python as we've been discussing.

The PyBOL is a piece of hardware that runs MicroPython

and has all these peripherals like ADC and DAC ports and so on. But right, micro Python, you can run off another hardware, you can run on the PC or it can run on these other development ports. And the Wi Fi is 1 that was specifically made to run micro Python and it has it's 1 chip that is a WiFi

transceiver chip, so it connects over WiFi

to other WiFi devices, your Apple or something.

And it actually it has a little application processor on this chip, which can run microfiber.

And the aim with the Wi Fi was to have this small

cheap low power sort of little wireless chip that runs Python. So you can telnet into it and you have a Python REPL right there, you know, remotely. So you can plug a battery in, throw it out in the garden, helmet in, and then read the temperature or turn your sprinkler

on. Or you can either drop behind the couch and

flash turn some lights on from your remote from your PC or from your phone even if you're not coming from your phone. So it's a really cool sort of remote type of prompt if you give it like that, and you can put it into whatever whatever you like, and you can control whatever you like in your fridge and send an email to you when the fridge is open or or tweak. So there's lots of different things you can do, and this is just sort of the the touching the surface. And this is all about the Internet thing, where everything 1 day will be connected to the Internet even if it seems crazy

right now.

Maybe in the future, it's not going to be so crazy to have everything

connected and everything having an IP address and stuff.

So hopefully with the Internet of Things so we can have micro Python running the Internet of Things just like normal Python runs the normal Internet.

Indeed. I mean, I guess 1 of the things that I had kind of envisioned when I read about this and heard about this is some of the robotics projects that you see where they have little, like, swarms of robots that can communicate with each other. And I thought how cool it would be, in addition to being able to sort of have a visual or or infrared or whatever other sensor

sense of each other, if they could all chat over Wi Fi and do interesting things and have interesting behaviors as a result.

Yeah. No. Definitely. I mean, robotics,

it's all connected. It's

all it's all hardware and microcontroller

that you just

need

a control board, some actuators, some motors, some servo motors

and

yeah and then you just need to connect them all together. So if you have Wi Fi that's the solution.

Yes and you can have a smaller things have a Wi Fi router they'll talk to and they'll communicate with each other sending some JSON strings to the JSON data to each other telling them where they are, what to do. Yeah.

Really

straightforward to do. I mean, it seems a few years ago, making such a thing would be very hard from the hardware and the software. But today

and

this has come about just very recently,

all these really easy to use Wi Fi chips. And you just give a power supply, connect nuts, and motors. You don't need much hardware knowledge to do that. And then software knowledge, you just write in Python, and you've got your little cost of robots sitting around. So it's pretty exciting times and I think it's only going to get better with

better hardware and more easy to program.

Yeah. Definitely sounds like it would have some pretty interesting applications in the smart home space as well-being able to have multiple sensors

networked via the PIE boards or the Wi Fi modules to be able to transmit information about your entire

habitat

to different regions within it. So maybe, say, track your progress through the house and, you know, maybe adjust the temperature

or start the oven warming as you come downstairs for breakfast, things like that?

I think the cool thing is that it's not just restricted to what some

someone is selling you. You can program it yourself to do whatever you like. Right? So

the power is in your hands to program your

Python board to to behave how how you like it and come up with some idea of how you wanna automate your house and you can implement that. I think that's pretty cool.

Are you familiar with the electric amp module? Is that something that the MicroPython implementation would be able to run on or is the CPU architecture too different or more micro Python was designed for?

Micro Python can run on many different architectures, it doesn't have to be ARM,

it runs on already 3 or 4 different architectures

and I don't remember

what the electric ink is. Could be an arm, but that's, I mean, whatever it is it could probably run on it. The main question is how much RAM does it have. It needs to have about 32 k RAM to do interesting thing with scripts. So that that would be if it had enough RAM which probably it does now with the latest revisions of it then yeah microPython could run on it. There's always

scope for someone

to port microPython to run on some new chip or some new board

and

by all means if anyone is interested in doing that then please go ahead

and once you have it done, you can submit a pull request and we'll see if it's something we can incorporate into the main repository or at the very least you can just link on the forum and other people can use your code. So we're always looking for people to help contribute,

because it's completely open source project MIT license which means you can use it, the code to do whatever you like.

So

it's a true hypothesis project and it's driven by the community now.

So what changes did you have to make to get the Python interpreter to run without an underlying operating system?

So no underlying operating system

means that you need to write all of the sort of standard things that you you familiar with yourself. So for example, mem copy

and printer and malware,

all these things need to be implemented.

You also need to have some some IOs and put an output, so you need to have a USB driver and you need to be able

to send characters in and out of that USB

to your PC, you need to write a file system,

you need to so there's lots of lots of those things and I mean actually for me it's fun.

I enjoy it doing all that. It's really technically interesting.

But, yeah, you you literally have nothing to start with. You have some RAM and you have a CPU, and then you've got some peripherals.

And in order to control those peripherals,

you just got the right bytes to the right addresses in RAM, and,

you know you just you just got to work out what bytes are right where and then things happen. But luckily there's drivers that form these chips so it's not as daunting as it sounds but still a lot of work to do to make it into essentially

like a Python operating system so you've got only

new features that you're used to.

So when you were designing the hardware,

what were some of the requirements that you were targeting in terms of performance

of of peripherals?

Well,

the reason I chose the chip that I did was it was sort of the the best chip I could find with the most RAM

at time and that it wasn't, you know, it wasn't expensive. It was relatively cheap because that's what I wanted. I wanted something that was only, you know, was only a few few dollars. It was about $10 if you buy them 1 off chips. But you could solve it by hand. It's only about 64 pins, which is relatively

small. It's rather than even to solve it by hand compared to another thing. But what I'm telling you, you could just you could just get and you could just solve it and then, hey, it runs like a pipe. And because I

was designing the hardware at the same time that I was writing the software, I didn't actually know

at the beginning how much, how many resources I would need. So I picked the sort of

the chip with the most RAM and the most flash so that

I would at least have some chance of running. And then if down the line it turned out I needed less, I could just shrink the chip and get a smaller 1. But in the end, I kept this chip because it's actually very powerful and it's got lots of peripherals

like digital analog converters

and lots of DMA to do fast memory transfers and

it's a pretty capable chip. So but, yeah, it was it was chosen so that I I could be sort of guaranteed that it would at least work and now that microphone is quite, mature, you can go and choose a sort of a less powerful chip to run it on if you so desire that has the features that you need, and cost you what your budget is. So you can buy like a $2 chip and run it on it now and that's cool if you want to make 1, 000 of it.

It. So what level of hardware knowledge is required to start working with the PIE board?

Pretty much none, if you buy 1, you just have plug it into the zip 3 port

on the PC and then

you can sort of log in to the board using

a terminal program. Like, if you're in Linux, you can just use

screen or on on Mac, you can see the screen. And on Windows, you can use copy or teratone or something like that just to connect to the com port. And then you've got a piping prompt there straight away, and you can you can type LED on or LED off and then LED on and off. And you don't need to know anything more than that. But if you want to, there's lots of features to explore. You can change the frequency of the CPU using

p yb.freqfreq

and then you type frequency and then it changes the frequency. You can do low level stuff like enable and disable interrupts with Python call. You can create timer objects with 1 line and set their frequency and then get them to do something every time they fire.

So to begin with, you need almost no knowledge and you this sort of a nice shallow learning curve to introducing all the peripherals and seeing what they can do and how you can use them. So you can do quite a bit just by plugging it into USB. It has an accelerometer, so you can read the angle of the board by by, you know, a couple of lines. And so, really, it's just Python and then learning a few modules, the PIV module and the classes it has. So it's kind of no hardware at all in that in that respect. But then if you wanna start connecting things up, like, maybe the buttons or motors or

displays or

Wi Fi modules and things like that, then you need to know a little bit about electronics about

how to connect things to the power

supply and resistance and and and things. But, I'd say it's probably a good way to to get introduction to these things if that's what you're interested in doing.

Definitely. And so it sounded like you were saying that there's a module namespace for interfacing with some of the hardware of the board. Is that correct?

Yes. So there's

a PYD module which is standard for fiber and

if you can put that in under that module, it has the the classes

for all of

the peripheral. So each peripheral

class, so the UART class controls the UART which is

serial communications protocol. And so you can just create instances of these objects and they correspond to a physical piece of the hardware

and then you just, like, the UI has read and write methods to send in the same data. So you just read and write a text string. And then if you've got the UART connected to, say, another panel, then you can communicate between the 2 just by doing UART dot read and UART dot write.

So how

portable is that module? Is it able to run on other hardware devices, or is there some sort of an abstract base class that people can inherit from for implementing their own particular

specific implementations for a given board?

We're trying to make it so that it's, the code that you write for 1 PIE board would run on another variant. I mean if you write code for

but for example, the wifi is a different board but we've tried to make it so that they have the same class they have uarts and we use them the same way they have LEDs they're using the same way the same methods.

So it's like if you run if you write some code for 1 board it should run on the other board if it has the peripherals

are there

Some boards won't have all the peripherals that you had on another 1 but if they do

the code

should run the same.

So

if you're trying to implement

or if you're trying to put my practice to a new board

then

the idea is that you will take a look at how all the methods that UART has and you'd make sure your UART object has the same methods

and corresponds to the same behavior and we tried to make it so that that's possible to do so it's, you know, there's not some obscure behaviors. They're all very clear and it's it's clean. So it's not possible to try to do that so that it's easy to use. And just as another example, the way the WiFi works on the WiFi port if you want to use

the the ethernet features which of course you do, you can just use normal Python sockets. So there's no there's no fancy things to do at all. You just import socket module and you do create a socket and you connect where you bind and then you connect server or a client and It's as simple as that. So in fact the script that you write for your PC

to make a server or a client

will be the same script that runs on the Wi Fi. So it's it's sort of a seamless transition

to your knowledge and also for testing purposes.

So for anyone who's writing libraries, what kind of restrictions do they need to be aware of as compared with regular c Python?

Well, they need to be able to fit. They need to if they're if they're too big, then they just won't be able to be compiled with the RAM. So and that's just a a sort of

an almost hard limit because, yeah, I mean, you just can't you can't do everything.

It's

not gonna fit it's not gonna fit. But given that it would fit then really there's not much,

there's not much in the way of restrictions all the Python language features are there, The inbuilt types like strings and dictionaries are should all all work just as you expect and have all the methods or at least most of them. If your library relies on other libraries, then you have to make sure those other libraries don't work. But, otherwise, there's not really much in the way of restrictions.

And so do the c based modules run on it as well, unaltered, or would the c implementations need to be rewritten? The c the c stuff is different because the that relies on, a c Python specific

API. So, you know, for example, NumPy, that's written with special

calls to CPython,

which don't exist in micro Python because micro Python's internals are different.

Now they we could write a sort of glue layout so that

c code written for c Python could run on micro Python. And I actually I've looked at that and tried to do it. Yeah. It's possible to do, but

not really an active area of work at the moment.

So what license is used for the MicroPython interpreter and the PIE board, and are they compatible with commercial use cases?

So I mentioned before that MicroPython is MIT licensed, so that means that it's free completely for commercial use or hobby use. You can take your source code to what you like, change it, release something

with it and not release the source code. It's up to you. So, yeah, there's no strings attached. It's

compatible with commercial use and compatible

with hobby use or whatever you like. And the the firewall itself yeah I mean the schematics are there and you're free to make your own version. Some people have made their own. It's a pretty basic circuit actually. It's supposed to be simple so that can understand it as well and if the firewall doesn't exactly what you need, you can go and implement your own and run like a firewall. So the aim is to make it as acceptable as possible

not to

get just trap people in 1 of the things that is hardening thing that they they're free to go and change the source code. You can write your own sort

of extensions and see to the source, make your own board with your own ship and yes do what you like. So I think good, and and I think that helps the community grow.

So what are some of the most interesting and innovative projects that you've seen people make with the micro Python board or 1 time?

Well, there's I tried to make a quadcopter.

You know, like,

the drones nowadays. They're very cool. And I I have this this quadcopter that's,

that's controlled with micro Python, so it controls the server, the so the motion, the propellers. It's it's not completely finished yet,

but, yeah, it it does, like, a little bit. It can take off, but then,

you can't control it so well.

So hopefully, we're gonna finish that 1 day, but some other things people have been working on. So someone has made a,

has controlled the guitar so

they

had actually plucked the strings and change the

so work on the fret and can play the chord. And so they have a pie board connected to all of these

actuators

to connect you to the car.

That's pretty cool.

So how does the experience of using MicroPython

and the PIE board and the Wi Fi module compare

Arduino has been around for quite a while and that's you're right you're right essentially writing a c plus plus using an Arduino

and you need to compile and then download.

Raspberry Pi, on the other hand, is a full computer as you might know, and so you can write in whatever language you like and and and run on there.

And micro Python is sort of in between those 2 the the pi board is in between those 2. It's more powerful than an Arduino, and I think

more fun and more easy to use because, you know, you get a prompt and you can set on the LED 1 line, Whereas on an Arduino, you have to compile your code and it's you've got all this boilerplate stuff and you go download it and then it'll run. And if you get it wrong, you've got to recompile and download. But in microfiber, you can sort of develop on the prompts to check things out and then write your script as you work things out. Raspberry Pi, on the other hand, is is like a full

PC. It uses a lot of power. It's relatively big. It's relatively expensive in terms of the chip and yeah. So I mean, it's it's in a different league again. So if you want something that's small,

low power, as in probably that much battery,

then,

Macropython is a good choice and it's easy to easy to program.

The TESOL is

sort of similar to Macropython, but it runs JavaScript. So if you like JavaScript, then go for that. But so I think Python is a much more friendly language than JavaScript programming.

So is there anything that you

wanted to talk about that we didn't ask you about or anything that we should have asked you about?

So I don't know if you have some of the announcements that we've made, but, the

European Space Agency

is actually

interested in

micro Python.

So European Space Agency, Europe's version of NASA

and they

they approached us and and we're asking whether we thought micro Python

could perhaps run-in the space based application, say, up in up in orbit. And we said, yeah, maybe it could and they have prepared to to fund the development of MicroPython

for the the short term future to see if micro Python is capable of controlling things in space and of doing things in in constrained environments

and, in in embedded environments that are very critical and have very critical limitations

of them. So, you know, if something goes wrong, that's a big problem. So you gotta make sure that the code is very well written and doesn't have any bugs in it and that it runs

as you expect it to. So that's very exciting I think. So there'll be lots of interesting developments I think in the future and seeing if we can make MicroPython suitable for these real critical

embedded systems.

So that brings up an interesting question as well

as to whether or not MicroPython

is capable of being used for any sort of real time systems whether hard real time or soft real time?

Yeah. So that's exactly that's exactly the point with the ESA,

the ESA stuff is that it's seeing if micro Python can be used

in systems such as real time systems where things have to be executed by deadline,

you can't run out of memory,

things are critical. So

yes,

at the moment I wouldn't say you've microfiber for a critical system because it's not yet, including, you know, verified. There's there's still there's still things that have to be have to be ironed out, but I think in the future, if if enough work goes into the run time, to make it

suitable

for real time systems, then, yeah, I think it's I think it's

possible. But, yeah, we'll have to wait and see because it's it's a

little bit of uncharted territory, you know,

Normally, you see the real time systems,

and you don't allocate any memory at all, it's just very basic stuff. So going all the way to Python is a little really big leap that you've got.

You're allocating stuff on the heap all the time, but always dynamic data structures and doing lots and lots of different things,

which are not, you know, perhaps deterministic. So it's a big step, so it requires a bit of work to make sure that it's actually

possible to do to see if possible and what changes have to be made.

Maybe you have to program in sort of a restricted Python, so you can't use say, dictionary because they allocate memory,

when you can't in a restricted way. So, yeah, it will be interesting to see how far

this can go and then whether or not it can be used in those houses.

That's really interesting too because it just struck me. I was at the Red Hat Summit this last week, and a few of the talks that I was at were talking about network function virtualization

and how

so much of

the currently specialized hardware that runs networking devices for telecom and and also for our you know, for the technology industry

are are these specialized

devices with hard coded firmware to do these tasks,

and it's being moved into more general purpose computers now

running specialized

software to do the job,

it strikes me that something like MicroPython might be a really interesting sort of middle ground as opposed to having

general purpose computers with fragile disks

running this stuff. It might be kinda interesting and neat to have MicroPython

chips with

Python coded firmware doing some of these tasks.

MicroPython is, as we're talking about before, is sort of like when you're running it on bare metal, like the operating system itself. And, yeah, there's no moving parts. It's running from Flash. It's it's only a little bit of RAM but it's got complete control over it and because it's a managed system

then you know you don't really have straight point. And so it is a very tricky territory. Yeah. Control systems. Yeah. Is it possible to use such high level languages alone with the control? So, yeah, it's interesting.

At this point in time in the show, we we'd like to transition into the picks. Could recommend anything that you might like or enjoy, and think our listeners might like. So, So, Tobias, why don't you kick us off?

So my first pick today is going to be the movie Machine Gun Preacher with Gerard Butler. It is the real life story of Sam Childers' work in South Sudan

to try and free the child soldiers that are embroiled in the conflict there. And it's a very well done movie.

Doesn't try to gloss over anything. It also doesn't try to glorify anything,

and it's definitely worth a watch.

My next pick is the Pocketbook Android app. It's the e reader that I've been using on my tablet for a while now to read PDFs and EPUBs. And it's just got a really good design and good UX with a solid feature set that doesn't get in your way. So I've been enjoying that.

And my last pick is a combination pick of Hoopla Digital and Overdrive,

which are online platforms that let you access

digital media whether it's ebooks, music, videos

through

your local library memberships. So if you have a library and you have a membership there, it's definitely worth checking out to see what sorts of other content you can get access to through those platforms.

Chris, go ahead.

My first pick is Real Ramen.

A lot of people, at least Americans,

when you mention the word ramen to them, they think of what's known as pot ramen, those plastic

in sheathed packets of generic noodles

and a dubious flavor packet full of stuff.

But the actual dish of ramen noodles is something completely and utterly different.

And if you're lucky enough, as I am living here in Somerville, Massachusetts, to have a really great ramen place,

right down the road from me, you should go there, and you should get it. And sit there at the bar and watch the ramen chefs prepare it because it is a beautiful thing to watch. It is an art, and it is like nothing you've ever tasted. It's really pretty amazing. So that's my first pick. My second pick is the Red Hat Summit, which, as I said, I just went to last week. I walked in, kinda, not knowing what to expect, looking at the talk descriptions, thinking, okay. This looks like a lot of middleware Java stuff, and I don't really know how much of it's gonna be interesting to me. And oh my goodness, I walked away learning so much about Linux,

and where the internals are going, and performance tuning, and

non unified memory architectures,

and

SELinux,

and security, and containers. And it was just a great conference. I met a lot of great people and it it really surprised me. So if you're a Linux geek and and you have any truck at all with the Red Hat CentOS world, I I highly recommend it.

And my last pick is something that I learned about and received through 1 of the talks that I attended there called the SE Linux coloring book.

Dan Walsh of Red Hat has become mister SE Linux in a way.

And 1 of the ways and he's very, very creative and really great speaker, and I and I highly recommend, if you ever get a chance to see him speak, you're doing that.

But he produced this coloring book, which explains the basic concepts of how SELinux works in an attempt to get everyone to take the time to understand it and not just turn it off because you received an error message and said,

and walked away. So it's very cool stuff. He also gave a really great talk that when it comes available, I'll I'll pick it and link it here on, container security

last week that was that was really great.

And that's it for me. Damien, what picks do you have for us?

Well,

I'm I'm gonna be technical. I'll say

but maybe I don't know if you've heard of this program, but

MOS, the mobile shell, I don't know, maybe you already use it. But it's been around a couple years, but I think it's really fantastic with software. It basically replaces SSH

and allows you to well, it is SSH, but MOS stands for mobile shell and you can MOSH into your machine just like you would SSH in, but then if your WiFi or Internet connection goes down, you don't lose the session. It comes back when your WiFi comes back. So you can actually put your laptop to sleep with the MOSSS session open, and then when you wake your laptop up again, the MOSSS session will reconnect and you just have everything there like you did before. So that's something that I use all the time, and I think it's it's it's really useful when especially when you you if you're sick of SSH and then drop connection then definitely need to use Marsh.

That's great. I I have used the Marsh shell and it does make it very useful for when you're dealing with different servers on a regular basis because, yeah, having having SSH connections drop can be very annoying and potentially problematic if you forget to

run your command and screen or tmux and then all of a sudden your connection drops and your 2 hour long compilation session fails because of that.

Yeah. Yeah.

Yeah. No. I use it all the time.

So, Damian, we'd like to thank you very much for taking the time out of your day to join us and talk to us about the MicroPython

project. It's been very fascinating, and I'm sure our listeners will really love to hear about it. So for anybody who wants to keep in touch with you and follow what you've been up to, what's the best way to do that?

So just go on GitHub. I think that's the best way. Go to github.com/micropythons,

and that's where the MicroPython code is.

And you can start the repository,

and you can watch the repository, and then you'll get all of our,

conversation, all of the development work. You'll, will be a stream that you

it will annoy your inbox, but yes, a stream of consciousness

of the development of microfiber.

And yes,

can raise issues there

and you can sort of contact us that way. Yes, I think that's the best way to attain touch. Thank you for having me, it's been a pleasure.

The Python Podcast.init

Summary

Brief Introduction

Interview with Damien George

Picks

Keep in Touch

The Python Podcast.__init__