When you think about embedded programming, does it bring low-level languages and tools to mind?
Maybe embedded C or even assembly language?
Thanks to the groundbreaking work by Damian George back in 2014 to create MicroPython,
Python is one of the very solid choices for building tiny programmable devices.
On this episode, we welcome back Damian George from MicroPython,
along with Scott Shawcraft from CircuitPython and Adafruit.
We'll talk about how these two frameworks are solving similar problems with slightly different philosophies.
More importantly, they are working closely to bring MicroPython and CircuitPython more in sync.
This is Talk Python to Me, episode 325, recorded July 8th, 2021.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy,
and keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Sentry and Linode,
and the transcripts are brought to you by Assembly AI.
Please check out what they're offering during their segments.
It really helps support the show.
Scott, Damian, welcome to Talk Python to Me.
Damian, welcome back.
Scott, great to have you here.
Thanks for having me.
Hi, yeah.
Thanks for having me as well.
Really good to have you both here.
And normally I ask people how they got into programming.
Damian, you've already told your story,
and maybe I think we'll mix it up just a little bit.
Let's maybe just have you both do a quick introduction about,
you know, how you fit into the Python world and what you're up to these days.
Damian, you want to go first?
Sure.
I'm the creator of MicroPython.
It's been a long journey in the past nine years or so.
Before that, I was a theoretical physicist,
and I studied at Melbourne University in Australia and did a PhD in theoretical physics.
My PhD was in extra dimensions and kind of string theory related stuff.
That's super cool.
Yeah, it was.
Oh, see, it couldn't be like a, you know, astrophysics type thing.
It's got to be something small if you're working on MicroPython, right?
Like if that's your deal.
Well, the thing with the particle physics is all about the tiny, tiny things.
The quarks is sort of as small as we know,
but also linking to cosmology, which is the really, really huge thing.
And the idea of cosmology is to link the tiny with the large.
But yeah, that's all, I guess, very different from microcontrollers and programming and software
and hardware and real tangible things.
How'd you get from physics to programming side of things?
I always liked computers and programming.
And I always sort of had that as a side hobby.
And I actually also studied computer engineering and mathematics.
But physics was the thing I kept, you know, I did sort of professionally,
if you could say that.
And always had on the side, you know, microcontrollers and my desk and CNC machines
and sort of half-built robots.
Fantastic.
Yeah.
So turned that eventually into MicroPython.
And when I was doing my PhD, when I was doing a postdoc in Cambridge and yeah,
did a Kickstarter with MicroPython.
And then that all sort of continued on and continued and grew and grew.
And that's how I sort of end up where I am now.
Cool.
Kickstarter was so neat when it came out in 2015, 2014, whatever time that was.
It seemed like it had such possibility.
Now I don't hear about it as much anymore.
And I know it's still out there, but...
Yeah, I think it was a bit earlier than that because we did it in the end of 2013.
And it had already been around a few years.
Yeah.
But it was, yeah, such a huge thing back then.
So super cool that you launched it on that.
Scott, how about you?
So I got into programming with PHP was my first language.
So I came kind of like from the web side of things.
And then when I wanted to do desktop apps, I found Python.
And you can still find a source for page, source forge page for a program called Denu,
which was like dynamic menu stuff for like managing your menus in Linux.
That was my first Python program.
That was 2004.
So that's before I went to university.
And then I got a computer engineering degree and I taught some of the intro TA classes there
and did like a Python version of it there.
So like Pythons kind of always followed me throughout my career.
After university, I did six years in industry and then took a year off and did drone flight
controller hardware stuff.
And then when that was like coming to an end, when I was going to have to find a new job,
I went to Adafruit and said like, hey, I need a job.
And they were like, hey, we have this project in mind, our UK doing a project that we want.
And it was to do bring MicroPython to their boards that had a different microcontroller
than what MicroPython supported originally.
So that was in August of 2016 that I started working on the Adafruit version of MicroPython,
which then became CircuitPython.
So CircuitPython is a fork of MicroPython that originally was for Adafruit's microcontrollers.
And we've really pushed it to be really uniform and a good beginner experience.
That's kind of how we fit in.
Yeah, super interesting.
In brief.
Well, it sounds to me like with your drone experience and all the small servos and electronics
and then this programming background, it's kind of a nice thing to bring together as well, right?
Yeah.
I mean, I had done Python for a long, long time and I had just gotten into Embedded and
I really like that the software depth, so to speak, is like much thinner, right?
Like there's a lot less software between the hardware and your code.
And I thought that was really cool.
And MicroPython was amazing how well it brings Python to those inexpensive devices.
Yeah.
So MicroPython was first, Damien.
And then CircuitPython was forked from it to, like Scott said, to make it work a little bit
closer with the Adafruit stuff.
Is that sort of the history of it there?
Yeah.
There's sort of a different focus on the end user and what level of experience you have
and kind of what you intend to do with the device.
So I see it as MicroPython being used in industry and professionally to build products.
And CircuitPython is to support, well, initially to support Adafruit's hardware, but also more
for kind of beginners and people who are getting into hardware and want to have a sort of much
easier onboarding with libraries and things that are working with the hardware that Adafruit
provides.
So there's a real distinction there with the audience and therefore the kind of features
and things that we focus on.
So there's a lot of focus in MicroPython on code coverage and making sure things are really
stable or as stable as we can make them across releases so that people who are working with
MicroPython in a product can continue to work and be confident that updating will fix bugs
and not change other things too drastically.
And we get, yeah, we get a lot of sort of requests for features and bug fixes and things from
people using it professionally.
And so I have to keep an eye out sort of on a lot of all these things so that when they
come together, all the people I know who are using MicroPython are not going to suddenly
be, have the rug pulled out from under them when they switch to the next version because
something else has changed.
Right.
That's an interesting distinction.
The sort of pro production side versus Adafruit is so very welcoming towards this is your
first project, your first IoT thing.
I like to build something for like a science project.
I mean, Scott, maybe you could classify it better.
You know, certainly better than I do what the specific focus is.
But when I go to Adafruit and I look around, I get this feel that it's very much like these
kits and very supportive of getting started and not like, hey, how's your robot doing?
Here's where you plug in the thing for your industrial car making robot.
I think you're both right on it.
I think there's, there's a bit, two aspects to it.
One is like the focus that I brought to the project.
And I mentioned the TAing, the intro course in university, because I think that does have
a lot of influence over how I drive our focus for CircuitPython is like, we're very focused
on what that experience in the first five minutes that you've ever programmed, not just hardware,
but programming in general, what that first five minute experience is.
So we've done things like all of those CircuitPython boards that we now support are all show up
as a USB drive once you've put CircuitPython on it.
And so all of the tutorials and things that we've written on top of that is uniform across
that.
And then that dovetails nicely into Adafruit's business model, where they really do focus on
beginners, because the reality is, is there's far more beginners than there are intermediate
and advanced electronics folks.
So from a business perspective, Adafruit's interested in the beginner side, just because
that's where the vast majority of people are.
Yeah.
I also feel like the Zen or the ethos of Adafruit at the beginning was to inspire people getting
into programming and getting into hardware, like from the beginning, right?
That was sort of almost why it was founded.
Yeah.
I mean, like Adafruit started around, like it's always been a matter of open source software,
open source hardware, and open source tutorials, right?
Like Lomor, the founder of Adafruit, who goes by Lady Ada, like she started even before Adafruit
was a company, writing tutorials about how people could go get all the parts to build this one
thing.
So that's very, you know, a lot of what we think about with CircuitPython is not necessarily
teaching you new code from if statements and for loops, but actually just getting you all
the code to do a project.
And then from there, now it's modifying that project in the way that you want rather than
starting from a blank screen.
Yeah.
Very cool.
Coming out in the live stream, Sean Tibor from Teaching Python Podcast.
Hey, Sean.
He's a teacher who teaches programming.
Also, I know uses some of the Adafruit stuff in CircuitPython.
It says the speed from zero to blinky lights is really important for learning.
You know, we've got that study from the BBC Microbit where they gave that to, I guess, all seventh
graders or something in the UK.
I think that's roughly right anyway.
And it really changed how many people saw themselves as interested in programming, especially
young girls that, well, they're way more likely to take a programming course after having something
physical and neat that you can play with rather than just a terminal with a print statement.
I think that I agree with that as well.
What do you all think?
I agree.
Getting a blinking light is, it's the hell of a world of microcontrollers, but it's actually
really quite hard, you know, whatever your piece of hardware is.
So often when I'm making MicroPython work on a new piece of hardware, the thing you can get
to is once you can get a blinking LED, then you're sort of set.
But getting there is really hard.
And I'm not talking actually about blinking an LED in Python.
I'm just, you know, blinking an LED however you can in assembly or C or whatever.
Because, you know, getting a tool chain working, making this, you know, plugging in the board,
powering it up, knowing how to power it up, knowing how to get it into a mode where you
can change the firmware on it.
These things take, you know, it can take days.
I mean, yeah.
Or longer.
And why is my serial port working right?
And, you know, all sorts of stuff.
Yeah.
So to port MicroPython to a new microcontroller, once you've got a tool chain, a way to flash
the device, and you can blink an LED or write characters to a UART, then getting MicroPython
working is probably another hour's worth of work.
And then you've got, you know, the whole of MicroPython ecosystem that you can play with.
But from a beginner's point of view, it's a similar sort of story.
When they want to, they get something, they've never done it before.
They've got a piece of hardware and, you know, what's going on.
So blinking an LED, to get to that stage, there's a lot of kind of conceptual hurdles
and also, you know, maybe installing things on your computer hurdles as well.
But to get to a blinking LED is really the beginning.
And then from there, you can be a whole sort of world of possibility opens up because you
can see then how you can turn that into a real life project.
Yeah.
Start to work with the other sensors.
Yeah.
Things like the accelerometers or motion or microphone or anything, right?
Exactly.
Yep.
Yeah.
I think maybe it makes sense to pause for just a moment and define microcontroller for people.
So I have a Mac mini here.
It's small, right?
That's not a microcontroller.
I could get a Raspberry Pi, which is even smaller.
Still not a microcontroller.
Like, give us a sense for the size of these boards and like, what does the hardware look
like?
It's not really physical size.
A microcontroller itself is actually more complicated than a PC in some sense.
A PC like a Mac mini or a laptop or Raspberry Pi that has a CPU in it.
And it's connected usually to a keyboard and a screen and maybe some audio and Wi-Fi, some
kind of internet.
And it's relatively straightforward.
It's a CPU that is fast and does a lot of processing and can output to a screen at a
high refresh rate and you can interact with it.
But a microcontroller is a CPU plus a lot of other peripherals around it, like UART and
SPI and I2C and I2S and Ethernet and Wi-Fi and then really low level stuff like DMA and
things that make the microcontroller work in a microcontrollery way, timers that interrupt
it very precisely.
So a microcontroller is what they say sometimes a system on a chip SOC.
It's a real tightly interconnected piece of silicon which has a CPU at the center which
controls things.
But what's more important is the things it's controlling.
And it's got to do that in a really precise and real-time way so that what it's controlling,
say a coffee machine or an airplane, is guaranteed to work every time the same way and run for
years without having any problems.
But if you have a laptop and it's probably not going to run for years without needing
to be upgraded or crashing for some reason or...
It's odd how that works, right?
There is this kind of distinction there.
It's a bit subtle, but the microcontroller is a really precise machine and a really complex
machine in the way it interacts.
Would you say more real-time?
Yes, that's one of its tasks is to be real-time.
And it's not as powerful as a laptop or a PC, but it is more sort of capable.
And also programming it is a lot harder.
So I think it's important to say that microcontrollers are typically used to do a single task in a larger
system.
So think of your car and I think a Tesla has a microcontroller that manages the door handle,
for example.
So microcontrollers are in a lot of things.
Damien said toasters in another example.
So that means that they're everywhere.
You just don't see them.
And that has the benefit of being very low cost.
So the microcontrollers, which are like the black chip on the circuit playground you see here,
they're only like a couple centimeters square.
They'll cost under a dollar or a few dollars at most,
which means that they're really inexpensive to get into.
And in terms of processing power, what you'll see is like if my desktop has 32 gigs of RAM,
right, but a microcontroller will have anywhere from like eight kilobytes of RAM up to maybe a
megabyte of RAM or a few megabytes of RAM at the higher end.
The distinction between like a microcontroller and a microprocessor also involves like how good it is
doing multiple things.
Specifically, like there's memory protection stuff that will happen in your like desktop CPU that a
microcontroller typically cannot do.
So really, it's usually just a single task thing.
Unlike macOS or Linux or whatever, you've got the OS and then it's running your processes often in user
space.
They have protected memory.
There's a bunch of them.
The OS is doing preemptive multithreading, all those kinds of things.
This, your Python program, your micro Python or CircuitPython basically is the operating system
almost, right?
It's like full control.
Right.
This portion of Talk Python or me is brought to you by Sentry.
How would you like to remove a little stress from your life?
Do you worry that users might be having difficulties or are encountering errors in your app right now?
Would you even know it until they send that support email?
How much better would it be to have the error and performance details immediately sent to you,
including the call stack and values of local variables and the active user recorded in that report?
With Sentry, this is not only possible, it's simple.
In fact, we use Sentry on all the Talk Python web properties.
We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got their support email.
That was a great email to write back.
We saw your error and have already rolled out the fix.
Imagine their surprise.
Surprise and delight your users today.
Create your Sentry account at talkpython.fm/sentry.
And if you sign up with the code talkpython2021, it's good for two months of Sentry's team plan,
which will give you up to 20 times as many monthly events as well as other features.
So just use that code talkpython2021 as your promo code when you sign up.
In some cases, there's a real-time operating system under the hood, but in some other cases, there isn't.
Okay.
Interesting.
So one of the things that might be fun to talk about is we've got MicroPython and we've got CircuitPython.
And we've also, you know, when people say Python, they often mean python.org, CPython, Python.
They mean you want to start us off with maybe, like, what's the difference between this huge, I don't know how large it is, 40, 50 megabyte thing I download from python.org, and then maybe what MicroPython is.
What's the same and what's different?
Can I write, can I take a random Python program and run it on MicroPython and so on?
It's sort of the biggest thing about if it's called Python, like MicroPython, you know, shouldn't it be just the same as Python?
And why can't I just use Python instead if it's the same?
Yeah.
So to begin with, you can't run Python on a little microcontroller because Python, it uses too much memory is kind of the base, really the reason.
Just to load the runtime libraries probably exceeds the entire working memory of some of these chips, right?
Just to load sort of the mapping table of Unicode character names is megabytes of data, which MicroPython obviously doesn't support.
So one of the main things when I was writing MicroPython was to make sure it didn't use memory where possible.
So all of the things that could be put into read-only memory or Flash or ROM were put in there.
So dictionaries and modules and things that are sort of built in, like a sys module, all of that is in read-only memory in MicroPython and CircuitPython.
Whereas in normal Python, pretty much everything is put into RAM.
And so when you make, if you try to run Python on a, CPython on a microcontroller, you would need megabytes of RAM.
And that really is the main difference.
But then there's a lot of other, you know, things on a sort of a list of things that are different to make MicroPython efficient on a microcontroller.
To make it small in code size, to make it run relatively efficiently.
And as part of that, we had to make some sacrifices in compatibility with CPython.
So there are some things that are not the same.
But for the most part, MicroPython and CircuitPython really do feel like normal Python.
The syntax is the same, at least up to a given Python version, because Python keeps adding syntax.
The syntax is exactly the same, and the semantics of the syntax are the same.
And a lot of the built-in types, you know, will have one-to-one mapping with the same semantics and the same methods.
So there's a lot of things down there that are very, very similar.
And I think that's a lot of things that are very similar to Python.
I think that's a lot of things that are very similar to Python.
And I think that's a lot of things that are very similar to Python.
I'm expecting to patch that when we load this module.
Yeah.
Yeah, exactly.
Scott's shaking his head like, maybe not.
But even down to things like how division and modulo work with negative numbers is sort
of very specific.
You know, when you have A modulo B and the negative numbers, then the answer is a certain
way.
And MicroPython copies that as well.
So there's a lot of subtleties there that you may not realize that over the years we've
gotten to make sure it's the right same as CPython just because we've got a lot of tests
and a lot of people giving feedback when it's not exactly as they expect.
Yeah.
And yeah, I mean, I've definitely learned so much about CPython and well, the Python language,
because so many things I had no idea about.
Like, whoa.
You had to get the exact nuanced details of how this thing or that thing works, right?
Yeah.
Make sure it's the same.
One of the things that I think is worth keeping in mind as people think about this is when somebody
says, I love Python, or I think Python works this way, or Python is this thing and it's
productive or it's whatever, it's slow, it's fast.
They often can be talking about many things.
Somebody could say, I love Python and they mean the Python syntax.
Somebody could say, I love Python, or I get the standard library so cool that it comes with
all of these things in the standard library.
They could mean IPIP installed pandas and requests and now something cool happened.
Yeah.
Right.
When you say Python runs there, there's like, you kind of got to say, okay, well, what are
we talking about?
Right?
It's mostly the language for sure, but there's got to be a ton of standard library things that
don't make sense.
I think that's one about parsing CSS hex values.
Like who cares?
Tk enter.
Don't care.
Yeah.
SQLite maybe?
I don't know.
I did actually do a lightning talk at the last language summit, kind of on this topic.
Perfect.
And like Damien was saying, like, to his credit, MicroPython is Python in the core syntax areas
and the built in types.
But as you kind of grow outwards into like the standard library, things get omitted a lot
because the, frankly, the standard library in CPython is large.
Yeah.
And so I did kind of a comparison there and I can share people with the slides, but like,
take all this stuff in CPython and show what's in circuit Python.
That's cool.
I've been having like discussions off and on with Brett Cannon about this as well.
Cause he's been thinking about like, how would you define like a minimum version of Python?
And I think that MicroPython did such a great job of that.
It feels like Python to me.
I had the background in Python before.
So like coming to MicroPython, it felt very natural.
So I think we're a good case for that.
Yeah.
I think you definitely are.
You know, Brett was, I know he's been thinking a lot about WebAssembly and what would it look
like if we could have Python and WebAssembly and we could have it in these other,
you know, like what would a mobile Python look like and these different environments that are
not just desktops plus servers and having this standard core Python subset is a pretty neat idea.
Yeah.
A couple of things from the live stream.
Sean has a warning for everyone who gets into this, that these microcontrollers tend to multiply
quickly.
He started with just one or two.
Now he has a whole collection.
I can't see what's in your background, Damien, but Scott, you seem to have a bunch of these things
gathered around.
Oh yeah.
This room is a mess right now.
I probably have at least a dozen on my desk though as well.
Yeah.
There's, I just got to find new and inventive ways of actually organizing them.
Cause you know, I mean, there's things like, you know, a box full of dev boards sort of in
plastic blister packs.
I take them out of the, the blister packs are too big.
I try to take those out.
Yeah.
Oh my gosh.
I have bins per manufacturer.
So like STM, NRF, Atmel, of all the different development boards.
Yeah.
There's just, yeah, there's a whole lot of stuff everywhere.
Like just, just, they're inexpensive.
They're impulse buyable, which is bad.
Exactly.
I'm going to buy those and one of these and yeah, amazing.
But it's gotta be a collection of cool little things.
Yeah.
It's also important to figure out like what each individual microcontroller can do unique,
uniquely.
Mm-hmm.
What makes something unique?
Like it's obvious, like if it's a BLE chip, then that's obviously what you want to do.
If it's wifi, that's what it can do.
But the RP2040, which is the new chip from Raspberry Pi, like they have this really weird,
unique peripheral that allows to do really, really, really real time stuff because an actual
CPU and a microcontroller is still not perfectly real time.
So they have this like special thing that they added that can do some really impressive
real time stuff.
It's very interesting to see like the stuff that's standard between all these things.
And then what's different.
Yeah.
I can imagine.
One more interesting thing I want to ask you about from the live stream.
Tim out there asks, you know, what are your thoughts on circuit Python being used in TI
calculators?
So the new TI 84 comes with programming as, and you can write Python in here.
I don't remember what the, oh, here it is.
The programming bits where you can see, but yeah, I mean, I remember programming in calculators
being like really, really weird.
Yeah, I did that actually.
Yeah.
I mean, a little bit funky, but you know, having Python there is quite neat as well.
And yeah.
So this is a fork of circuit Python.
Interesting.
It's not publicly released, which is totally okay.
They are careful not to call it circuit Python, which is good as well.
But that does mean that like, if you go to circuit Python.org slash downloads, you won't
find like the latest version of circuit Python for your calculator.
But generally, I think it's great.
Like, I love seeing people build on circuit Python, just like we've built on on micro Python.
Like, yeah, people should do that.
It's really neat.
Yeah, absolutely.
And then another one out there that's neat that says, Matt says, "Micro Python and the
new Lego spike delighted the inner teenager in me."
Did you catch that?
You must've known about this, right?
Yes.
How do you take this news?
Yeah, that was pretty amazing.
I don't know if it was a year or a couple of years ago, I think, maybe even longer, three
years ago.
Yeah, a little while.
When they started, well, they contacted me about it.
So it's still an ongoing thing.
You can, there's a Lego education, which is separate to sort of Lego retail.
Lego education is for schools.
I remember using that when I was in high school a long, long time ago.
Lego, it's obviously Lego, but it's the different kit and it's different focus on what you do
with it.
And the Lego education these days, sort of the new version of Mindstorms uses MicroPython
in the hub of the sort of the central processing unit of the central sort of Lego control block.
Do they expose that to the kids to play with or is it just like a runtime internal sort
of thing?
It's kind of both.
The thing that you can get for Lego education is using MicroPython to implement sort of what
what the kids say.
But I think there are plans to make it so that you can actually use MicroPython directly.
That'd be really neat.
Yeah.
Very cool.
I think it's great.
Scott, I asked about the comparison between MicroPython and CPython.
You want to close the circle and go from maybe the differences of MicroPython and CircuitPython.
Like, why are there two things here and whatnot?
How people think about like, if I'm going to work with one or the other, where would they go?
Yeah.
So I think the why is what Damon iterated earlier is like our focus in CircuitPython really is
beginners.
And coming into Adafruit, I also knew that their model is that like for every device that they
sell, they provide example code and drivers for it.
And because Adafruit was going to do this for the Python world, we had to make sure that the
hardware abstraction layer, like the modules you import in Python that allow you access to
the hardware would be consistent across everything that runs CircuitPython.
So you saw me get like a little niggly about like, it's not actually CircuitPython on the TI
calculator because like, I think the branding of CircuitPython is really important because it means that
you can download it from the website.
You can use the APIs that we have standard as CircuitPython.
And therefore, all of our CircuitPython libraries work on top of that.
All our guides for CircuitPython work on top of that.
Yeah.
So that was really, you know, one of the more important things for us is having that uniform
API that we can then build all of this Python software on top of.
That's one of the main differences.
It should be, I should say that we do actually have this layer called Blinka now that allows
you to use MicroPython under the hood or actually CPython under the hood.
But it presents that same CircuitPython API for other things as well.
This line has been blurred some.
The thing that doesn't come with that is that we, in CircuitPython, we still do ensure
that your kind of workflow is the same as well.
So all of the CircuitPython boards that you can download now, except in the future, this
is going to change, show up as a CircuitPy drive and you can edit the code.py file on it.
It runs after you save it automatically.
And it's really quick and easy to iterate on.
Right.
So basically there's a file watcher that looks at your source file that is the program.
And if it sees a change, it kind of just reboots super quick and reruns it, right?
It's not even that smart.
It's any write to the file system.
It doesn't know what file you're writing to.
It's just any write will trigger that.
And the caveat I had is I'm working on a Beely only workflow as well.
So in the future, there will be two ways of using CircuitPython.
There will be a USB way and a Bluetooth low energy way.
I see.
So you don't have to actually connect physically to the thing.
It could be over there.
Right.
You could program it.
That and from phones, phones and tablets in particular.
Devices that are really easily interoperable over USB.
We want to bring the beginner experience of programming in CircuitPython to those devices as well.
Yeah.
So that's the caveat.
Like right now everything does USB, but I'm like working on the micro:bit v2 right now that will not be doing USB.
It'll only be doing Bluetooth low energy.
That sounds more complicated.
Yeah, it is.
But also very useful.
But I just, without a wire, you know.
Yeah.
I'm just thinking of when my headphones like get disconnected.
I'm like, oh, interference.
How frustrating.
And, but you know, when that's your connection, right?
Yeah.
Bluetooth's come a long way and I have had it working a bit.
A lot of the challenge with Bluetooth is there's no standard way of doing like file transfer.
So we really like we're working on apps to be able to transfer files and apps that are letting you pull that will pull down all the example code and automatically load that over.
And that file transfer API that we have is all public.
So if folks want a link to that, I can send them a link to that protocol.
So yeah, there's a lot more work off the device to do for it for this Bluetooth stuff.
That's cool.
So I see on circuitpython.org, it says Blinka and circuit Python libraries are just a pip install away.
So if I'm working, but I'm on my desktop machine or server machine, can I still do like prototyping and try the libraries?
What does that mean?
It's not every computer.
If you're on a Raspberry Pi, it will work because that is supported.
If you actually, I think if you click that single board computers link, it'll show you all the ones that we specifically support.
But single board computer is like a Linux class computer that usually breaks out general purpose IO, GPIO.
So that's kind of the class of Linux computers that you'll be able to use this on.
Okay.
And then we do also have a couple cases where you could like plug something into your USB that would also like give you that GPIO on another device.
This portion of Talk Python to Me is sponsored by Linode.
Visit talkpython.fm/linode to see why Linode has been voted the top infrastructure as a service provider by both G2 and TrustRadius.
From their award winning support, which is offered 24/7/365 to every level of user, to the ease of use and setup.
It's clear why developers have been trusting Linode for projects both big and small since 2003.
To pull your entire application stack with Linode's one-click app marketplace or build it all from scratch and manage everything yourself with supported centralized tools like Terraform.
Linode offers the best price to performance value for all compute instances, including GPUs as well as block storage, Kubernetes, and their upcoming bare metal release.
Linode makes cloud computing fast, simple, and affordable, allowing you to focus on your projects, not your infrastructure.
Visit talkpython.fm/linode and sign up with your Google account, your GitHub account, or your email address and you'll get $100 in credit.
That's talkpython.fm/linode or just click the link in your podcast player show notes.
And thank them for supporting Talk Python.
Question from the live stream from Tim again.
How has the workflow changed over the past few years for SugarPython and MicroPython when deploying code?
And it sounds like Matt's talking about MP remote.
Tim, do you want to talk about what the deployment looks like?
Yeah, there's a lot of answers to that question from a MicroPython point of view.
As I mentioned, if you're using MicroPython in a product, then it's a really different setup as if you're using it in a hobby, trying to make your light turn on and off.
So using it in a professional setting, you'll probably have a big sort of workflow or setup where you can freeze the code into MicroPython and deploy it or something like this.
Yeah, in production, what do you put actually on there?
Do you put, would you go and say, well, we're going to put a PYC file there instead of the Python file?
Yeah, yeah.
Or is there stuff like that you might do?
Yeah, it's not, we have our MPYs sort of instead of PYC, precompiled code, yes.
But there's sort of another, a further step where you can take precompiled code and then sort of freeze that into a C data structure, which becomes part of the firmware itself.
So big projects might have hundreds of Python files, which are then all precompiled and frozen and then built into the firmware and then deployed onto the device.
Is there any room for something like Cython or number or some one of these C compiler type things?
Yeah, Cython don't really support that.
But you can write C code as well if you need to, if you really need speed, you can implement a module in C and then tie that into Python quite easily.
So there are lots of options in terms of making things faster or efficient or the way you do your workflow.
But sort of to get back to the original question, MP Remote is a new tool that was released in the last version.
And it's intended to make a workflow, well, give you more options.
You can use it to copy files on and off, get a REPL on the board, or one of the main features is to mount.
So make your PC's file system available on the device that you're running on.
So you mount your PC's file system on your PI board or ESP32 or whatever.
And then when you go onto the board and do it OS.Lister, you actually can list the files on your PC running on the board.
So this allows you to basically do all your work on the PC and then your board can import and run code from the PC, read and write files from the PC.
And so the workflow is very quick.
And when you're sort of happy, you can then precompile or copy files, MPY files onto the board to run it disconnected from the PC.
Yeah.
This is also good for sort of testing integration tests of devices.
They can sort of interact more closely with the PC that they're testing against.
And yeah, it just aims to provide you with more tools at your fingertips to make your workflow more productive.
Yeah, it's neat.
When I want to put something onto my server to, you know, to upgrade like for site, something like that.
I'll do some work locally.
I'll do a get push.
Some magic will happen.
GitHub will do a web hook back over to the server.
The server will grab that.
It'll pull it down, install the new dependencies, restart the server through like a zero downtime sort of firewall type of thing.
If I have a robot in a factory, what do I do?
Is there a continuous deployment equivalent for MicroPython things or what's the story look like over there?
That's a good question.
We don't, we don't.
I think this came up the last time we had a couple chats between like the folks that work on CircuitPython and the folks that work on MicroPython.
And I think this was kind of a topic that we all said like, yeah, that would be really nice.
We don't have a sort of recommended or official way to do all of that.
But what I guess what you're talking about is over the updates maybe kind of answers your question.
Yeah, basically.
Yeah.
Like if I had a Tesla, it sometimes I wake up in the morning, maybe my Tesla does different things.
It's something like that.
Yeah.
MicroPython things.
Well, if you have a factory full of robots, you probably don't want them to automatically update because you, you need to be there when it happens and you need to control it and do it at the right time and so on.
Yeah.
It really depends heavily on the project that you have.
But over the updates are sort of definitely, yeah, the way to do this and they have been done and they are sort of out in the field.
And they're done in lots of different ways, like some over Bluetooth where you download the new firmware and then.
It's a little like what Scott's working on now.
Yeah.
Sort of an automated way to install the new code and then reboot.
But, and then other places where it's, they're connected by a USB and you can just do a normal DFU upgrade or similar, or maybe over I2C they're listening in a special mode to download new code.
There are, there are lots of ways to do it and there are lots of sort of parts in MicroPython's code that allow you to do it.
And it really depends on your project.
I think probably Scott has a different answer.
I was going to say from the hobby side, like it's never, I don't, we don't focus on the automated update story.
But you know, a lot of the folks that use CircuitPython are coming from an Arduino world.
So Arduino is really common hobby.
It's based on C, but it's got some like stuff on top of the C stuff.
But it means that you have to like have a computer that has Arduino installed that can compile the source code.
And because we focus so much on this interaction of like, it shows up as a USB drive.
It actually means that anybody, it makes it more accessible to update.
So if, if I'm remote and somebody wrote the software for me once, but now they want me to update it.
Like, even though I don't understand how it's doing, I can plug it in, it shows up as a drive and I can copy files over.
So it's really has been beneficial for, for folks that way, whether it's the Python code they're updating, or a lot of our boards also come with a bootloader,
which is like the software that manages what you're installing.
And a lot of our bootloaders for devices also show up as a drive as well.
So it's still a manual process, but it's a manual process that's gotten better from, from the previous things.
Right. And from the hobby perspective, you could have a little app or something that says, oh, I noticed we're connected to this thing and we're just gonna, it's out of date.
We're just going to push some stuff to it.
Yeah.
We actually have some community members who've really fleshed out this app called Circup, C-I-R-C-U-P, which you can pip install.
And that will like figure out all the libraries on your circuit-py drive that are out of date and update them for you.
Okay.
Which is pretty neat.
Yeah.
It's kind of like the pip of circuit-python.
Yeah.
I'm just sure the requirements and concerns are extremely different.
if you're working with, you know, a small hobby device versus something that is controlling a robot or runs a thing that shouldn't go down.
Yeah.
So one thing I wanted to definitely focus on while we were here together, seeing I find it is somewhere, is I do now this.
The, there's a lot of work that has been done.
It sounds to me like on the circuit-python side to catch up with micro-python.
Is that right?
Mm-hmm .
You want to tell us about that, Scott?
Yeah.
So the history of this is like when Adafruit started paying me to work on what became circuit-python, it was like, okay, I'm going to write a whole lot of code, right?
So that's when on GitHub I hit fork.
That's when I add a new port for atmels.md.
And that's kind of when we split.
And later on we decided like, oh, you know, like we have enough changes here that it would be a lot of work for both Damien and us to get those changes merged back together.
And that's still very true.
But what I said at the time was that we would kind of keep pace for every stable release that we do.
Keep pace with stable releases from MicroPython.
That wasn't true for about like two or three years.
We stopped updating.
We do.
It's basically a git merge, right?
So it's a whole lot of work.
And so I did, we had six versions of MicroPython to merge in.
So I did those.
That's like 112 through 115 or 110, something like that.
And then since then we've actually updated 116 as well.
So what's involved with that is like MicroPython has both like a PI folder, which you can think of as kind of like the VM.
We think of that as kind of the core.
And then there's separate ports for each main type of chip that we support.
And we don't really share code with MicroPython for those different implementations for different chips.
But we do share that core Python VM.
So a lot of the work to merge in MicroPython is like updating all of that core stuff.
And the discussions that Damien and I have had along with the other folks that work on these two projects has been like, all right, like what can we do just to get back to this world where we have the same copy of that PI folder?
Yeah.
Because there's like a few weird things that like CircuitPython has done that haven't been merged back into MicroPython.
And we've had discussions about which things are those are interesting and which ones would we want to make configurable and things like that.
Yeah. Interesting.
Now that we're updated, we have this foundation where we can have this discussion again, because we actually can tell like what the differences are between the two latest versions of these projects.
Yeah.
Larry Bank out of the live stream says my imaging codec still haven't been merged into MicroPython.
There's a lot of things that haven't been merged into MicroPython.
Yeah.
David, I was going to ask you, you know, what does this mean for MicroPython?
Like, obviously, it makes sense for CircuitPython to just not be out of date.
And, you know, the farther you are away from one of these merges, it's more like credit card debt.
And then a little bit is fine.
But as it gets farther, it starts to become a problem.
But in reverse, there's probably a lot of things that people who are engaged on the CircuitPython side could bring back if it was basically the same.
There's some great things that CircuitPython Scott has done with garbage collection for one thing.
And it would be great to share a common PY folder at least.
And we have, as he said, we've had discussions about sort of how we can smooth things or make things more common and where we know we differ, you know, how we can make it easier that we differ.
Recently, actually, a really good improvement in MicroPython for tab completion so that it didn't have complete underscore and also tab completed imports.
You do imports based tab and then it lists the tab completes the things you can import.
Some good improvements for sort of fuzzing and sanitization addresses and sort of various subtle bug fixes that have come across.
So it's, yeah, look, it's really great to have an open source project.
And because other people find bugs for you and fix them.
Yeah.
The more we can be in line, the better.
And there are actually other, I mean, there are other people using MicroPython and CircuitPython as we saw with the calculator and Lego.
Yeah.
And I think in the early days I was happy people were using MicroPython and wasn't too concerned about sort of people forking and changing things.
But these days my, I've shifted more towards, well, what can MicroPython do to make it easier for other people to use it without changing it?
So when they're about to think maybe I need to fork this to do this, you're like, well, why are they about to push that button?
What can we do to make it more extensible or whatever it needs to be, right?
Yeah.
We're going to make someone else's life easier so they don't have to fork.
Not that we want to accommodate everybody and we can't, but, you know, does it make sense to talk with these people and then make sure that their needs can be met in a sensible way and maybe it helps everyone else as well.
So, yeah, it just, it helps the community when you have less sort of forking and more cohesion.
Yeah, it absolutely does.
I mean, we've seen the Python 2, Python 3 stuff mostly get resolved by people finally moving all onto the same place where the core devs spend their time.
And I think that that's, it's only been beneficial.
It seems like a lot of projects are taking some of these ideas and picking up speed, whereas there used to be a lot of hesitancy as there's like too many different paths in the road.
Yeah.
Well, I'm just glad I did Python 3 from the beginning with MicroPython.
I bet you are.
I was just playing around with this.
I was able to use like a smiley face emoji as a variable name and it just worked, which kind of blew my mind.
So that's a super credit to Damien for making MicroPython really, really strong, really robust and really Python.
Yeah.
I think, you know, in terms of like CircuitPython and MicroPython, another thing that we can really compliment MicroPython with is like, we can, we're willing to be more experimental.
Damien alluded to this memory allocation thing that he, I pitched to him at one point and he was like, "Ugh."
I was like, "Well, we'll put it in CircuitPython, we'll see how it goes.
And then you can decide whether you want it or not."
So I think that's a benefit that we can have in CircuitPython is that like, because Damien really wants MicroPython to be stable, we can, we can try things out in CircuitPython.
And then he can pick the things that he wants to move into MicroPython.
That's a fantastic way to look at it.
And the fact that you've got these merge differences, these version differences down to such a small gap.
But like, well, that would have worked three years ago.
I'm not sure it works now.
Now you're basically experimenting on what is the real thing.
Yeah, that's helpful for like this tab complete thing where like, somebody added it into CircuitPython and we merged it, but then they also made a pull request to MicroPython and like, making sure that they're starting from a closer baseline will help everybody as well.
Yeah.
I mean, it's, it was, it was really good to hear you do 1.16.
And we're trying hard for MicroPython side to release every two months or so, so that it's easier for everybody to upgrade and thing.
It doesn't take so long for a new release to come out.
Yeah.
And what's the schedule for CircuitPython, Scott?
We don't have a set timeline.
We do try to get in a rhythm of, of doing, we do both stable and pre-release releases.
And we don't have kind of a fixed schedule, but we, we tend to try to have like pretty recent pre-releases out.
If it's been long enough that we're recommending the pre-release over the stable release, we ask ourselves like, okay, why aren't we just calling this a stable release?
Right.
That gives us a forcing function to up the stable release.
We are kind of in this window between major releases.
So we're currently like doing 7.0 stable or pre-releases for that.
That's a chance when we did all these merges, because we get a lot of instability, not because the code we're merging in is bad, but the merge is really hard and it's hard to get correct.
So we're kind of in this like very big state of flux right now with CircuitPython where a lot of things are changing and we're very quickly approaching this.
Like, all right, we got to stop changing things so that we can stabilize because we're no longer recommending the stable release.
We're recommending the pre-release.
Yeah.
Because like when you, somebody introduces a new board and it's like, oh, well, that new board is not supported in the stable release.
You have to use the pre-release.
Like that's a largely a forcing function for us.
Interesting that the hardware is driving the software like that.
Yeah.
And that's a thing from like a number of us are funded by Adafruit to work on it.
So when Adafruit releases new hardware, we have to decide like how we're going to make it available.
Absolutely.
All right.
Let me take one question from the live stream.
This is from Murray.
Hey, Murray.
I don't actually know the details, but I'll read to you.
I'm sure you all do.
Here's a different question.
What's the state of MicroPython dash lib project as regards to the bigger MicroPython project?
That's a good question.
The aim is to switch to, you know, improving MicroPython lib.
It languished a bit because, well, there was just a lot of stuff to do in the main repository.
But now that a lot of the code in the main repository has sort of stabilized and settled down and mature, there's more scope now to go and write everything.
Well, write all the extra bits in Python and put them in MicroPython lib.
So we have recently reorganized that repository to be a bit clearer as to what's in there.
And the aim is to maintain it and keep it running and put lots of libraries in there, improve the CPython standard library support and other things.
There you might have noticed there was AIOBLE, which is a asynchronous Bluetooth library, which is in MicroPython lib and is being used in production.
It's pretty good in terms of stability.
It's very good in terms of features and what it can do.
It's really quite amazing how it makes Bluetooth simple, which is a very asynchronous thing and a very high latency thing.
So having an asynchronous API is really beneficial.
So that's just one example of a library that is written in Python, pure Python, and is in MicroPython lib.
And we aim to continue that trend.
I know that it's a little bit stale some code in there, but we will fix things in the very near future.
Yeah.
Very neat.
Speaking of asynchronous, what are some of the, this question, both of you, what are some of the shiny language features that are new and neat in there?
Like asynchronous awake?
Can I do that with the Bluetooth library or Walrus?
Can I do a Walrus operator?
What's going on?
Like, what can I do?
I think it's a micro async.io, which has, is in its third sort of iteration, third version.
And that's been, I think about a year old now, that version.
And that also has been used in quite a few production systems.
that's also quite stable.
And I think is a really good showcase of using Python on microcontrollers because things on microcontrollers, well, some things take time, like reading a sensor and waiting for a Bluetooth packet to arrive.
And you've got to do lots of things at once, like blink a light to indicate progress.
It'd be great to be able to take them as those events come in, right?
Yeah.
So event based, but also easy to sort of use because I mean, multi threading using, you know, threading in Python, you can do, you can do that on some micro Python ports, but it's heavy weight in the sense that it uses a lot of memory for each stack, a stack of each thread.
And it's slow to switch and respond.
So it's, it's, it's not a great solution.
So cooperative multitasking, which is what asyncio is, is I think a better solution than threading on a microcontroller and even on a desktop.
Yeah.
And it works really well.
When you have something that's well suited to asyncio, it's really, it's a really fun experience to program something that way.
It's aptly named because what it's really well suited to is waiting on things like IO, right?
Right.
Waiting on these devices, these various sensors and stuff to come back and just say, Hey, I've got an input.
I've got a call back or whatever.
Right?
Like that's, it seems like the perfect case.
It's not like, well, we're trying to do all this computational stuff.
Asyncrasy.
Well, that doesn't work as quite well that way.
Yeah.
Like, you know, you may just want to wait for a pin to change from high to low.
So you spawn a task and you do, you know, a weight on the pin.
And then when that, when that statement continues, it means the pin has changed.
That's hard to do in a sort of callback based system.
Um, well, it's not, I mean, it's just a different conceptually and maybe it's harder to reason about things.
So there are, there, yeah, we have support for these fancy features, asyncio and the walrus operator we had in f-strings and not yet, you know, I think circuit Python has f-strings.
Oh, you guys already have the f-strings.
Damien has a higher bar for merging than we do.
Interesting.
So in circuit Python side, we have f-strings merged in, but we haven't done this work on the async stuff that Damien's really done.
Because our audience's beginners are really pushed us not to do async stuff.
Because I think something that beginners don't necessarily understand is like the computer literally does things in order that you want it to do.
Yeah.
So a lot of the examples that I, that would, that we use and that we get to people to doing is just doesn't use async.
So it's not been a focus of ours.
So I think that's a lot of the reasons to merge was to get the newer async stuff in and kind of hope that somebody would come along and turn it on and make sure it's all working.
But kind of, we've had the opposite, opposite approach.
And I think talking about async, one of the things that we've been thinking about is like, async is very networking oriented in terms of Python.
And it's not necessarily clear how that impacts hardware APIs and like waiting for pins and things.
So I think it's really interesting to think about how async await applies to things like spy transactions and I squared C transactions.
And, and what exactly like, like we, I talked about how circuit Python has a different hardware layer than micro Python does.
And like, I don't think either of us have really come up with a, like, what does that look like when you have async await support?
So I'm curious to see what, what Damien comes up with.
Yeah.
I mean, we do, we have recently merged I2S support, which has preliminary asyncio support in it as well.
So you can, yeah, asynchronously send and receive audio buffers.
We also have async support for pins using, well, a small sort of piece of wrapper code.
A thread safe flag is our main sort of interaction between interrupts and asyncio.
So you create a thread safe flag object on the asyncio side, you can wait on the flag and on the IRQ side.
So some event happens like a spy transaction completes and you get an IRQ and then you can set the thread safe flag.
And then that will mean that the task waiting on that can continue.
So, yeah, but I agree, Scott, that it's still early days with API for connecting IRQC and things like that into the async world.
I know one project sort of working on uses asyncio and Bluetooth and thread safe flag with pins, but nothing else is async.
But the things that are async are very important to be async.
And a lot of the time just asyncio.sleep is the thing you want.
And yeah, just wait, wait for a bit of time.
So you're waiting on a PNN sleeping is actually gets you a long way.
So, but I think it's still early days and even asyncio in CPython is sort of still early days in the sense that they're still trying to work through what API is good for streams.
And there's trio as well, which is providing good feedback to see Python on asyncio.
So it's still early days in the whole sort of Python space.
Yeah.
There's my favorite unsync, which is a unification layer on top of threads, multiprocessing and asyncio.
And it's like, I think the whole implementation is 126 lines of Python in one file, but it's, it's glorious.
All right.
One final topic I want to touch on.
There's been a lot of interesting work about making Python regular old server side, desktop side, CPython faster.
There's been a bunch of interesting things coming on.
Pigeon from Microsoft is kind of making a comeback.
I think Anthony Shaw is doing some work on that.
Maybe Brett Cannon as well.
There's Cinder.
The Instagram crew has released with really interesting stuff going on about making a lot of interesting changes in the runtime about making it faster stuff about like immortal instances that are sort of not subject to GC and reference counting and whatnot.
We've got the latest language summit, you know, is talking about interesting things he's doing and focusing on to try to sort of accomplish the same goal.
Like, is any of this stuff influencing what you all are thinking about?
Or is it just not really applicable?
Yeah, this is a really big topic because Python has a long history and it's used in a lot of places for a lot of different things.
And it's built by a community, unlike other languages.
I mean, yeah, lots of languages built by communities, but Python in particular is one of the more popular languages that is really just community run and funded.
You might say it as something like it's built by a very diverse community, technically speaking, as opposed to say JavaScript, which is almost always web.
And then kind of recently, it's been a little node, but like it's astrophysicists, it's embedded, it's data science, it's web.
Like there's a lot of different pressures and areas that Python gets put in.
Yeah.
And, and the focus has not been on performance.
It's been on usability and features and keeping it up to date.
Backwards compatibility.
Yeah.
I mean, it's been, it's such a, it is an old language that has evolved a long way.
Like C is an old language, but C hasn't changed that much.
C++ is an old language.
Well, C++ has changed a lot, but it's got a very big community around it and lots of production.
But Python is sort of, yeah, it's got such an sort of amazing and passionate community who do all this stuff for free.
And performance is something that's sort of always been in the back of people's minds, but it needs a lot of work and it kind of needs a stable Python language to perform.
You know, you can't optimize along the way of adding features.
It's really hard.
But anyway, this is sort of just to say that it's a big topic and lots of people have tried to make Python faster.
Python faster.
And PyPy is an amazing piece of software that makes Python faster.
One of my first big Python projects, we used PyPy because it was really, really good and made things a lot faster, like 10 times faster.
And we didn't have any sort of extension modules that didn't work with PyPy.
They all did work with PyPy and it was, it was really, really good.
So use that if it works for you.
Although PyPy, it's a bit big though.
But it's, what it does, it does really well.
So on the other hand, making CPython faster, just the core CPython, I think is a fantastic goal.
And I think probably the thing I would say is that any interest in Python is good for CircuitPython and MicroPython and the general Python ecosystem.
Just because it's people working on Python and trying to make it better.
Whether or not, you know, there's something that comes out at the end is kind of secondary.
It's that people are interested in hacking on things and having fun and things will come out of it.
Part of it, maybe it's not going to be a very, a super fast CPython at the end, although that would be really great.
And that's what people are really, really working towards now.
But I just think the general interest in Python is the biggest thing that will come to us.
Is that, you know, Python will be in the headlines more and people will be talking about how it's faster now and it's interesting and it will change people's perceptions.
And then people will learn more about MicroPython and through Python and C.
Yeah, we'll start having to deal with all these articles.
People are leaving C and Go because it's so slow now.
And back on the table.
Well, yeah.
Python is such an ergonomic language.
It's so great.
Yeah, it's so lovely.
I think actually the performance side is just so, so many layers, right?
Like it's slow, except for if you use the SciPy libraries, all of a sudden it's really fast and then like, it's just, it's super interesting.
It really depends what you're using it for.
And I don't think you should, slow Python shouldn't be, it should be banished to that concept.
It should be like, use Python and see if it works for you.
Because, and if it doesn't, you know, then use a different language.
But that's the same you say with any language.
It's like use the language if it's going to work for you.
Yeah.
And oftentimes it's just, well, you're not using the right part of the Python ecosystem to address that problem.
Yeah.
Right.
Yeah.
Scott, do you want to maybe weigh in on that real quick before we wrap it up?
We're about out of time.
I generally, I delegate to Damian.
Damian does a lot of work on this core and makes it really fast.
I try not to get sucked into the performance stuff because I'm trying to do the workflow side of things.
But I did want to point out for those folks that are coming from CPython and may not have done embedded Python, is that the boards that we run on, but both MicroPython and CircuitPython, we're very much in Moore's law territory still.
The first board that I supported is 48 megahertz, but the TNT4 runs at 600 megahertz.
So we can get a lot of speed within this domain by paying a few dollars more.
That's important to realize is that like the things that we do for speed may not be the things that you would do in CPython.
Interesting.
Yeah.
There's hardly a make the computer faster answer at the CPython level.
We do kind of have a turbo button if we can just clock the CPU faster.
Yeah.
Awesome.
I thought it had a turbo button.
I loved it.
And it was probably just as fast as what we're running MicroPython and CircuitPython on now.
How interesting.
Yeah, for sure.
All right, you guys.
Well, we could go on and on and on about this.
Maybe we'll have to do another episode, but I think we're probably out of time.
So I'm going to ask you a couple of wrap up questions.
I normally ask the editor and IPI library.
Maybe we'll go ahead and do that, but I want to throw in one more thing as well.
So let's do editor first.
If you're going to write some code that runs on either Circuit or MicroPython devices, what editor do you use?
Vim.
I've used Vim since day one, I think.
Right on.
Scott?
I use Sublime Text.
Cool.
Very good.
Notable PyPI package.
Something out there that's pretty cool.
I've seen a bunch of things going by in the live chat as we're talking.
It's very active today.
So I think HTTP IE is really quite a cool tool for like instead of W get.
I've 100% moved to HTTP IE.
I guess it's like curl or W get, but you get like syntax highlighting for your response.
It's beautiful.
And it's actually a good tool for when you're like working with MicroPython.
If MicroPython actually accepts, you know, HTTP.
It's not just for pretty printing.
It's good for actual workflow as well.
Yeah.
Well, Scott, you got one to recommend?
For the folks in CPython who are getting into hardware, if you have a Raspberry Pi, Blinka
is great.
Blinka.
Okay.
As the foundation, you'll want to find a device that you're interested in using and then
you can use Blinka.
Yeah.
I don't know.
That's a really good one.
The HTTP is a good one.
I'll have to take a look at that.
Yeah.
I've completely switched on all my servers and even on my desktop to just have that for a
testy thing.
It's really, really good.
Okay.
Here's the extra third question that normally we don't get.
So if you're going to work on a project, I have all these ideas of things that I would
love to create and stuff, but I don't ever know really what the right hardware for it
is.
So I guess, Damon, you first, if you're going to work on something and you've got some idea,
you know, what kind of board would you get?
Maybe you have to give us a little background, like the scope of the idea or the context, but
what board would you play with if people are thinking of getting into stuff and playing
with it and so on?
Yeah, that's a good question.
It really depends on the project.
If you want something like the PI board, we started making and selling that like eight
years ago.
That was the first Kickstarter.
And we still sell a lot of these.
The original PI board down a little bit of that page.
Yeah, that one.
And that's just a really good general purpose workhorse with good IO support.
And I use it still today to do things.
And that's really cool.
If you want high performance Wi-Fi Bluetooth, if you just scroll back up over it, then the
new PI board D is what you need.
And that, you know, that has really fast Wi-Fi and really good Bluetooth support.
the Raspberry pypyco, I think is a really another really good option if you want something that
has is relatively cheap and has good functionality.
And this new PI O programable IO stuff that Scott was talking about.
That's also a really cool option.
There's a whole lot of stuff out there.
Yeah, there's a lot of choice.
And it's all really good choice.
Exciting.
Yeah, very exciting.
And not super expensive, as you all were saying, like you can get them and try them.
It's not a huge investment.
Scott, what's your your dream board that you would recommended board you would start with?
I don't think there's any one board.
I see some people trying to make this particular board they have do something that it doesn't
necessarily do very well.
So what I recommend people is actually go to learn.adafruit.com, which is where Adafruit
has all of our tutorials and look there, find a project that is close or exactly what you
want to do.
And then you'll see all of the stuff that you need to do that.
That's where I would start, because not only are you picking the hardware that you that you
could use to do what you want, but you're also getting all the software to do it as well.
You're definitely getting a head start by starting from an existing project.
Yeah, that's an interesting perspective.
Like instead of what board do I want?
Like what project?
What thing do I want to create and solve?
Now what hardware do I need to like facilitate that?
Yeah.
And then the other thing you can do is if you go to circuitpython.org/downloads, you actually
can type different features.
Like you want to see all the BLE boards or the Wi-Fi boards.
It will filter out the boards there for you.
And those are all the boards that circuitpython runs on.
Very neat.
All right, you guys.
Well, thank you for being here and sharing this.
It's really cool to see the two projects working more closely together.
So final call to action.
People want to get started.
One from each of you, I guess.
Like what would you tell people?
Well, go to micropython.org.
Go to forum.micropython.org.
Where our forum is, that's sort of the most active place for discussion.
And then GitHub micropython/micropython is also where all of the development action is.
Scott?
For circuitpython, you can go to circuitpython.org and the /downloads is particularly useful
if you happen to have a device already in hand.
That will get you the file for that particular device.
If you want to hang out with us that are working on circuitpython, we do have an Adafruit
Discord server.
Everybody is welcome to join.
You can go to the URL adafru.it/discord.
That's the short link for it.
And that will get you in there.
You'll see there's a circuitpython dev channel.
That's where we coordinate all the development.
And on GitHub, we're github.com/adafruit/circuitpython.
We're moving more and more to, we have a circuitpython organization as well.
So maybe at some point we'll do, we'll be github.com/circuitpython/circpython.
Right on.
I was also just going to throw out that you do a fair number of live stream Twitch-like
things.
Maybe just tell people about that as well if they want to catch you there.
Yeah.
So I started live streaming kind of like as the pandemic ramped up as just like something
I've wanted to do.
So I started doing it regularly.
I do it at 2:00 PM Pacific on the Adafruit channels.
So you can go to youtube.com/adafruit.
It's called deep dive with Scott.
There's a playlist there.
They tend to be about two hours or more and very casual, no editing, but I answer questions
and show off into the weeds of circuitpython stuff.
And we've gotten a lot of contributors out of that, which has been great.
Yeah.
Fantastic.
So if you want to hang out on a Friday afternoon, everybody's welcome to do that.
And we've talked to Damien about joining that at some point as well.
Cool.
Well, I'll look forward to seeing you both over there as well.
So thanks for being on the show.
Thank you.
Thanks, Michael.
Yeah, you bet.
This has been another episode of Talk Python to Me.
Our guests on this episode were Damien George and Scott Shawcroft.
It's been brought to you by Sentry and Linode and the transcripts are sponsored by Assembly
AI.
Take some stress out of your life.
Get notified immediately about errors in your web applications with Sentry.
Just visit talkpython.fm/sentry and get started for free and use the promo code talkpython2021
when you sign up.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual
machines.
Develop, deploy, and scale your modern applications faster and easier.
Visit talkpython.fm/linode and click the create free account button to get started.
Transcripts for this and all of our episodes are brought to you by Assembly AI.
Do you need a great automatic speech to text API?
Get human level accuracy in just a few lines of code.
Visit talkpython.fm/AssemblyAI.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct
RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure
to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Bye.
you
Thank you.