Embedded - 295: In the Key of Lime (Repeat)

Episode Date: April 7, 2022

This week we talk about CircuitPython with Adafruit's Kattni Rembor and Scott Shawcroft. The suggested first board is CircuitPlayground Express with LEDs, sensors, and buttons. CircuitPython is also available for many other boards including the BLE Feather (NRF52832). For a basic introduction take a look at What is CircuitPython and see some example scripts. To dig a little deeper, check out the many resources in Awesome CircuitPython. The whole thing is open source so you can see their code. If you are thinking about contributing (or just want some fun chats), get in touch on the CircuitPython channel of the Adafruit Discord server: adafru.it/discord Many of the language’s design choices favor ease-of-use over ready-for-production. Imagine teaching an intro to programming class without worrying what computers will be used or how to get compilers installed on everyone’s machines before time runs out.  One final note: Kattni did a project that gave us the show title: Piano in the Key of Lime. After we finished recording, Chris asked her why she didn’t add a kiwi fruit to her mix… Kattni explained she had limes and they were small. Chris only wanted a different fruit so she could rename it Piano in the Kiwi of Lime. It is always sad when we stop recording too early.

Welcome to Embedded. I am Elysia White. I'm here with Christopher White. You may have noticed that in our wonderful show with Limor Fried, I completely neglected to ask about CircuitPython, one of Adafruit's pretty cool projects. Happily, Katni Rembor and Scott Shawcroft are here from Adafruit to talk entirely about CircuitPython. Hi Katni, hi Scott, thanks for joining us.

Hi, thanks for having us. Thanks for having us. Katni, could you tell us about yourself? Sure. So I'm Katni. I am sponsored by Adafruit to work on CircuitPython. The part of the project that I'm in charge of is more about the libraries and the community. And I do a lot of guide writing as well. So technical writing is part of what I do. I also design hardware and have written libraries myself for the same hardware that I designed, which was a new thing within the last few months. Cool. Scott, what about you? I'm Scott Shawcroft. I am a software person by training. So I was at Google for six years before I left that and did started learning embedded and PCB design. And then about three years ago, I started working for Adafruit on what was then Adafruit MicroPython and became CircuitPython. Oh, we have questions about how that transition happened. Yeah, I'm planning on addressing that.

First, we want to do lightning round where we ask you short questions and we want short answers. Are you ready? Yep. True or false, Python was named for the snake and its ability to eat things whole. False. Correct. It was named for Monty Python, which I didn't know. Part of keeping it fun to use. And so with that in mind, what is your name? Katni Rumbor.

What is your favorite color? Purple. Blue. No, yellow. What is the airspeed velocity of an unladen swallow? Depends on weather. Yeah. It's so sad when everybody knows the answers.

Well, I'm sure we'll have some questions later where we don't have all the answers. Can a python eat a medium-sized American alligator? Don't know the answer to that one. Maybe. Yes, and it is causing problems in the Everglades. Okay, so Adafruit has a series of pictures with snakes doing things. Reading a book, using a computer, being a cupcake. What I really want to know is the one that's cooking, what is it cooking?

Depends on what Blink is interested in at the time, I suppose. Is that its name? Her name, yes. Oh, okay. The snake has a name. His name is Blink? Blinka. Blinka.

Oh, I have questions about Blinka. Wait a minute. I thought that was some sort of software thing. It is also. Yes. Okay. It's both our mascot and our software thing. Okay.

Well, Blinka has many hobbies. I do want to know what some of these are. I suspect that one's Dungeons and Dragons, but it's no good talking about visual things on a radio show. The easy question first, what is CircuitPython? So CircuitPython is a derivative of MicroPython, which is both of them are Python that run on microcontrollers, which are tiny computers. And CircuitPython is aimed more towards beginners and lowering the barrier for entry to programming and electronics. So we put a lot of effort into making it easy to use, easy to understand, and a solid situation for anyone who's

just coming into learning is our goal with that. And that sounds like a good transition to MicroPython versus CircuitPython. Scott, you were part of that. What is the difference and how did it come about? Yeah, so I was the first person Adafruit hired to work on MicroPython. They had been following the project along and seeing how it made microcontroller programming way more accessible. And so they hired me in August of 2016 to port MicroPython as it was to the SAMD21, which is an Atmel chip that was already in a lot of Adafruit products at the time. So I did that as a kind of per project basis and got it working pretty quickly and then just like kept making code and getting things working. And one thing that Adafruit did with Arduino and was planning on

doing with CircuitPython is funding a large library of open source drivers for different things. And one of the key components of that is having the consistent API that all of those drivers can be built upon. And one of the technical differences that I ran into when talking with Damien, the creator of MicroPython, about having a very consistent API was that he really wanted each chip family's version of MicroPython to have control over exactly what the API they presented was. And I disagreed with that approach. And it gets to a more fundamental difference between our philosophies where MicroPython is very power user oriented and wants to have the ability to make the advanced use, like advanced features of a microcontroller available, whereas I was willing to hide the advanced stuff in favor of having consistency. So after we had put a lot of work into our GitHub fork, at some point, we had

to choose whether we would try to get our changes back into upstream micro Python. And we still have discussions with Damien about our relationship and stuff. But at the end of the day, we decided that it was going to be a lot of work. And Damien was still very wary at the time of having a company come in and fund a lot of development, but, you know, may not be committed. He had been burned by another company prior who had come in and added MicroPython support to their stuff, but then kind of pivoted.

They were a startup, they pivoted away from it, and suddenly he was kind of left with the maintenance burden of that. So he was worried to have us upstream, and we were already seeing the philosophical differences between what we were trying to achieve with it and what he was. So at that point, we decided to rename from Adafruit MicroPython, which is what we're calling it, to CircuitPython. And that's really for the betterment of both projects where we can have a separate identity and a separate community and make it clear that the things that we've written for CircuitPython, both guides and libraries, work with our stuff, but not necessarily with MicroPython because MicroPython became more and more different in terms of APIs and workflow.

So, yeah, it's for the betterment of both projects that we've renamed that. Does that answer the question? That totally answers the question. And it helps set what's going to happen in the future. MicroPython continues to be focused on staying very small and being as micro as it can be. But CircuitPython doesn't always follow that philosophy.

Yeah, like one of the main differences is that MicroPython is very performance oriented. Their audience, to me, is folks who have done Embedded C and want to move to Python because it's easier, but still want all the mechanics and the capabilities that they've had when they were in C land. So interrupts and concurrency and sleep modes and performance are all things that Damien's worried about with his new Pyboard D hardware series, along with the software to support it. Whereas we are very much willing to trade performance for ease of use and making sure that people can get programming and coding really, really quickly. So we spend a lot of time focused on the first five minute experience.

And one of the key differences that still exists between MicroPython and us is that both systems will, when you plug in a device that has MicroPython or CircuitPython installed, they show up as a mass storage device. So they show up just like a USB thumb key with a main or code.py file on it. But one thing CircuitPython will do is once you've saved that file, it detects the file right and it will auto rerun your code for you, which just shortens that iteration window just a bit more and makes that feedback loop of like, oh, I wrote some code to turn on an LED and you hit save and you see the LED turn on, all that more rewarding. Maybe this is a question for Katni, but for someone coming in new to playing with embedded or playing with microcontrollers, do you feel like maybe this is causing a little bit of confusion? Like, okay, I could go the Arduino route or now I could go the Circuit

Python route. How do you resolve that? Or are they marketed in slightly different ways and targeted in different ways? I think they're definitely marketed and marketed in slightly different ways and targeted in different ways? I think they're definitely marketed and targeted in slightly different ways. You're still dealing. So I actually started with CircuitPython. That is how I got into this. And I was attempting to learn Python before that and found CircuitPython, which seemed serendipitous at the time. But the point was that I was attempting to learn Python, and CircuitPython fit that, except taught me Python

by manipulating the physical world instead of manipulating data. And I think the attraction is that there's always that extra step with Arduino where you need to compile it and load it versus with CircuitPython where it just works. It auto-reloads. It's done. So our first five-minute experience can include a lot more than I would think Arduinos could. And so I really think it's what people are interested in. Arduino obviously has a decade on us in terms of how long they've been around and the amount of work that's gone into it.

So there are still things that CircuitPython can't do that Arduino can. And in that case, Arduino is definitely a better idea. But I would say CircuitPython is a better beginner experience. It's much simpler code. It's much simpler to get going, and it's much simpler to have a result that occurs and you can see it and feel it and know that whatever you're doing is actually affecting something. So what I heard there was, one, manipulating the physical world is much better than data which i completely agree with but two circuit python is a way to get into coding and arduino is a way to get into microcontroller hardware is that more of the target you're looking for i know arduino is also great for learning to code and great for artists and people who don't code. But it sounds like you're

going for the, I don't know how to code. This is where I should start. Well, there's still a huge amount of hardware support in CircuitPython as well. Every piece of hardware that we design that is a breakout, that is a sensor, that sort of thing, we write a CircuitPython library for it, and they all have examples, and they're all very simple examples. So it targets people who are still interested in hardware as well in the sense that you may be a beginner, but you say, okay, I want to design something that knows when my mailbox is full of mail. How do I do that? There are guides that can walk you through what hardware to purchase and what code to write to do that. And it, so it, it brings together both software and hardware, um, at least in the sense of what hardware support there is for circuit Python. And if somebody gets into circuit Python and they enjoy it, but they find it limiting, is there a path for them to go from a hobbyist project to a real product?

No, is the short answer. Which is fine. Not everything needs to lead to production. Right. So there is a pretty easy escape hatch into adding C code that you can call from Python. That's actually my job. Like I write way more C than I write Python. And that's totally doable for somebody who has experience with ARM GCC, for example. That's definitely not in that first five minutes. But there is an escape hatch to adding more performance related stuff if you need it. We are all open source. We are MIT, so you can always do that. But out of the box, it's definitely not product ready.

Doesn't mean it couldn't be, and it doesn't mean that somebody couldn't productionize it so that it was, but it's not our focus. And so we haven't done it. Fair enough. You write in C and Python's usually interpreted. How does an interpreted language work on a microcontroller? I mean, do you end up compiling your circuit Python? bytecode. And this is how CPython works as well. So CPython is like the specific name for the Python, like canonical Python on the desktop. But basically, the micro reads the text file that's on its file system and parses it does like AST things. And then it converts it into a bunch of structs with bytecode instructions in it. Wait, what's an AST thing? An AST thing is an abstract syntax tree. So it's an intermediate data structure that represents your source code,

but is not text. So it's in the process of you read the text in, you typically tokenize it. So figuring out where the words are and the pluses are and things like that. And then you can interpret that into like a hierarchical structure, the abstract syntax tree, which then will be converted into bytecode,

which is kind of like machine assembly, except that it's an intermediate representation. So you still have a loop that's written in C that basically reads those bytecodes and does some C code based on that. So that's like the LLVM thing? We've talked about that. Chris is giving me faces, so...

Not really. More like Java or sort of Java. Okay, sort of just related to Python, there's this pyc file that shows up sometimes when I'm using Python. Is that the bytecode? Yeah, for CPython, that's where they cache the bytecode. And on CircuitPython, where do you cache the bytecode? We only store it in RAM.

So from run to run, from reset to reset, we'll have to do all of that parsing again. We don't cache it over time. We do have a format that we can in for bytecode that makes importing easier called mpy which is kind of the analog to pyc but we don't automatically write those back when after we load a dot py file does that mean i can only write a program that can fit into RAM? Yes. Okay. So no giant programs. Um, cause most of these, uh, microcontrollers, you know, have K's of RAM, not M's of RAM. Correct. Yeah. Yeah. We're definitely, um, we've done some work on making our memory footprint footprint more efficient. Um, but in general, yes, you can't have giant programs that wouldn't fit in

there. What's the reason to parse on device instead of doing it on the host and then pushing down the bytecode? Because it's easy. You don't have to install a tool chain. It's already on the device for you. It's really cool because the source code then goes with the device. So if I'm working on something and I've written the source code, I can hand it to you and you have everything that you need to run it just on the device itself. I suspect for every time we're like, why do you do this thing that doesn't seem efficient to us? The answer is going to be because it's easy for people to use. Right. Like if I give you a device with CircuitPython on it, like you don't need to install anything, right? Like it will show up as a drive with a text file on it.

As long as you can edit a text file, you can use CircuitPython in that case. So the boards, I mean, Adafruit has a whole bunch of boards. And so let's say I buy one of them. Which one should I buy, not knowing anything about what I'm going to do with it? If you are looking to get started, Circuit Playground Express is by far the best place to begin. It is a board that has something like 15 or 20 sensors and LEDs and buttons and switches built into it. So you don't have to add breakouts or wire things up or really understand electronics yet to be able to do a lot of cool projects. It's what I started with and it's what we have a lot of people start with. And it provides an amazing experience because there's an accelerometer built into it, for example, a light sensor, a temperature sensor, that sort of thing. And you can use all of those to make the LEDs change color or that sort of thing. And it means that you aren't having to figure out why your breakout

isn't working because it's all built into one thing. Okay. Now, you know what this looks like, but I had to type it in and look at it. And it's a palm-sized board with big edges, kind of like the sewing ones do. Correct. Right. It's round. And it's round and it's got a bunch of LEDs and this GIF that has me completely hypnotized shows the LEDs going in rainbow colors and I can see the temperature sensor. There's a little music sound

and a little, it must be a microphone because there's a little ear on the board. Yep. And it's 25 bucks and for five bucks I can get an enclosure. And so I get one of these, and it's got all these sensors and stuff to play with. And then I plug it into my computer over USB,

and I just type. There's a file there, so I open it and then I just type away. So in this case, you would actually need to install CircuitPython first, which is you, there's a reset button in the center of the board. You tap it twice. You download the correct version of CircuitPython from circuitpython.org, which is slash downloads, which is a very, you just, it's, it's right there. You just search for it. And then you drag the file that you downloaded to the, when you double tap the board, it shows up as C play boot in all caps. And you just drag that file to the C play boot

drive and it installs circuit Python for you. And at that point you would begin, you'd be able to begin coding by creating a code.py file and saving it to the circuit.py drive that shows up after you drag that file that you downloaded to it. Okay. So it has a bootloader and we are downloading its flash code and then it gets written. And once it's written, then it has the Python. It's weird to call it an interpreter. Is it really an interpreter at that point? Or is it a compiler? I would call it an interpreter. Because it's not going all the way down to machine code. But is there a is there a command line, a REPL thing that I can type at? You can there is is. So you connect to it via serial.

If you are familiar with the command line, you can use, for example, a tool called Screen to connect to it. Ah, Mac users. Yes. You can connect to it. And once you've connected to it, that's where any kind of print statements or error statements would be printed to the serial console that you are now connected to. But if you hit Control-C and then any key at that point, it drops you into a REPL, in which case you now have your standard Python prompt and you can run code line by line at that point. Okay. And then when I type import Matt plot lib, what happens? It raises an import error. What can I import? What libraries do you have? That's a good question. We have a very small subset of the standard C library or the

standard C Python library. And with that subset, we try to keep it identical because we're trying to teach people Python, right? So people start with CircuitPython, they learn Python, and then when they want to grow up to CPython, everything that they've learned for those standard modules applies. It works just the same way. And then on top of that, we've got a bunch of CircuitPython specific library or modules that do all of the hardware abstraction stuff. So we have one called digital IO, and that's the thing that you would use to toggle a pin on and off, for example.

It's hard for me because so many of the things I use in Python, I forget which are packages I installed. And sometimes my packages install other packages. So I don't really know what's the CPython ones unless I go to the Python pages. Right. Well, there's no consequence to trying to import something we don't have on CircuitPython. So you should always just try it and see what you get i don't know it's a i think for lamore lady it was a very different realization for her like she's done arduino for 10 years and the idea that like making a mistake does isn't fatal to the microcontroller where you just get an error on the serial like Katni was talking about, and your chip's still running, your USB's still active, and everything's still okay,

is quite freeing and also very different from the Arduino model of if you really screw it up, you really have to start over. I mean, that's one of the beautiful things about Python being an interpreted language. Sure, I will eventually save a Python file, but initially I'm going to type at it and try what I want and make it work. And then once it works, I'll put it in a script and I'll make it a function or a class, and then I can use it a lot. But that first little experimentation of, oh no, that's not how I do this. Oh no, that's not how I do this. Oh, no, that's not how print even works.

It's really helpful. Okay, so next question, Python 2 or 3? 3. 3. I mean, that's totally the right answer. They tell us that 2020 is when 2 is going to be gone. Yeah, at the start of 2020. All of my code says no. Yeah. Python 3 is great for hardware.

So MicroPython targeted Python 3.4 specifically. 3.4. 3.4, yeah. And one of the really nice things about Python 3 versus 2 is that it has a byte string and a byte array built-in type. Whereas in Python 2, there's a string and a string could either be what you think of as bytes or it could be text that's been encoded in UTF-8, for example. So with Python 3, they explicitly separate those two and that makes it way easier on the hardware side where we're dealing a lot

with byte arrays and byte strings. Oh, yes. If you've never gotten to play with the byte encoding in Python 2, you really haven't learned. And if you really want to do that, then you should start working on time too. Okay, so back to things that I know the answer to is going to be something about ease of use. You don't support interrupts. How can you have a microcontroller thing that doesn't support interrupts? So we don't support interrupts from Python because concurrency is hard. And so any time there's a function or something that you need to be able to do that would benefit from interrupts, we do it in the C under the hood for you instead. For example, for audio playback, we have a way to say, play this sample, and it returns immediately.

And then in the background, it worries about filling up the DMA buffer, for example. So you do have interrupts. You just don't let users who are stuck in Python use them. Correct. So behind the scenes, a lot of interrupts are happening. For, you know, USB incoming stuff is all interrupt-based as well, which is why we can't make promises. One of the reasons we can't make promises about the timing of the Python code itself

because we have interrupts that we're doing in, and then we also have some like, uh, maintenance sort of tasks around writing to the file system for USB and things like that, that can cause your, your Python code itself to run with different timing. So our goal is to provide C implemented modules that do all the timing sensitive stuff for you. So you don't have to worry about it. With the variable timing, the lack of a certain latency deterministic, a lack of determinism.

Right. Do you have people complaining about that? Or is that just something, I mean, that's part of Python. I mean, see Python does garbage collection whenever it feels like it. Right. Yeah, I, in general, no, I think a lot of the feedback that we get is people coming from Arduino land where interrupts are the way that you would do things. And it's just a matter of us teaching people the different philosophy of, you know, we got this, we got you covered. Here's the thing

that does pulse timing measurement, for example, on your behalf in the background and and that c that that i've written or dan written or some of our community members have written like we actually try to offload that off the cpu straight away as well so like if we can use dma to do those timing sensitive things or the peripherals we will um which is good for circuit python in general to get it off the cpu so you're really trying to make it an expressive language where the goal is not to tell the processor what to do. The goal is to tell the interpreter what it is you want to get done. Right.

And that was one of the, as I was more and more willing to work away from the hardware API that MicroPython was trying to establish. Theirs was very peripheral-centric, right? So they have a class that is timer, and it's supposed to have all the knobs to be generically a timer for all of these different chip families. Whereas as I was working on the CircuitPython hardware API, I realized that that was really going to be difficult because timers vary between chip families a lot. So much. Right. So I was like, you know, what we need is we don't need

a timer class. We need classes for the things that you do with timers, right? So we have a module called PulseIO where it has pulse in, so that's like infrared timing and DHT sensor stuff. And then we have PWM out, which is PWM out, of course. And whether that uses a timer or something else is not something you need to worry about. You just say, hey, do PWM out on this pin. If you're unable to do it on that pin, it will raise an exception and you don't have to worry about what the underlying implementation of that is. It figures it out for you.

I think that's such a hard thing for me as a programmer to have accepted in some of the higher level development I've done in the last few years, that I have to let it go. I have to accept that someone else has implemented this satisfactorily. Well, you don't, you don't have to accept that because it's all open source. You can always dig into this C code and see exactly how we're doing it. That is true. And for Adafruit, I have actually rewritten some of your drivers which is totally fine that's why they're open source but i you know you have great interfaces so if i end up anyway blah blah blah that's the goal yes the goal is to have good interfaces you do support other pieces of hardware um they aren't shields are they what are they snake skins i don't know what do you call them

so we actually do support some shields there are not we don't have a name for circuit python specific hardware um we should come up with one right we support sensors in different form factors so breakouts shields pie hats um feather wings feather wings, that sort of thing. And so it just depends on the form factor, what it's called. Oh, I see. There's no simple. Okay, that's fine. And then you write libraries for those in C, but interface them to Python.

Is that right? That's what I think Scott has been saying. No, no. There are libraries in C that are built into CircuitPython. However, for the hardware, we're actually writing Python libraries. That seems inefficient. And you're using my RAM, which I didn't have that much to start with. Well, that is one challenge. But the thing with C libraries is that they're shipped for everyone, right? So we're using Flash space for whatever functionality it is. But if there's something specific to an I2C device, that can be in Python.

You can load that into RAM dynamically when you need it and only when you need it, versus if it's in C, it's in Flash, and it's always in Flash. So our goal with C modules is to be able to do the timing sensitive stuff. Maybe not in the most friendliest API, we can always put Python on top of it to make it friendlier. But we need that core C for timing sensitive and interfacing directly with the hardware. Besides that, it should be in Python. Okay, you have, I know there's a feather wing that has a nice display on it. How do I put, how do I run a, it's got a touch controller too. How do I run a whole display in CircuitPython

if my images and my Python library have to be in Python? Right. So I've done a lot of work with displays recently. I have E-Inks and OLEDs and all sorts of stuff on my desk currently. But I've been really inspired by the way that like, late 80s hardware works. So the Game Boy and specifically, where from Python, you define the objects that you want on the screen and the bitmaps that make up those objects, rather than just having a frame buffer. Exactly. So it's sprite based. And then in on the C side, we do partial rectangle tracking and things like that so that

you don't need to refresh the entire display all the time. We just keep track of how the sprites move and just do the damaged areas instead of everything else. And we do that for you. You do have some C... Is there a layer? I mean, I want to say C subterfuge, but that's not the right word. A sublayer for hardware to support hardware. I mean, Python doesn't come with a display subsystem. Right. Yeah, I mean, this is where CircuitPython starts to become an OS.

Yeah, that's the thing. We manage file system mounting, that sort of stuff. We have what I've dubbed the supervisor layer, which is the layer of C that runs from startup all the way until the end when you turn it off. And it does the management of what Python code is running and what happens when it's finished and how the USB interacts with that as well. That's all kind of supervisor level stuff.

So one of the things I did with the display work that definitely made it more complicated, but I actually wanted the supervisor to be able to use the display if user code wasn't. So if you connect up a display or you buy a board that has a display on it, the serial output actually shows on the display once it's configured and initialized, which is towards that goal of ease of use because people sometimes have trouble connecting to the serial link. And that's where your stack traces and your exceptions go. So by being smart enough to say like, oh, we have a display, let's use it to show what's going on is super helpful. And the feedback we've gotten since we've had that feature has been really, really positive. I can totally see this, but now that I want to play with it more, I want to have a better way to get from, I did this once to I want to make 10 of them for my family.

Even if I'm not going to production. Right. There's still some level of making it robust. How robust is it? I mean, there were notions, there were mentions in things about memory error. How stable is this, is the both the code and the system as it runs? I think it's hard to measure. We definitely have reports of it running for days at a time. And we have a product called Pi Portal, which the goal is to have a screen that sits and can wirelessly communicate and pull data down and display it. And occasionally we hear about

people where it's like they left it overnight and it doesn't work. Uh, or like you wake up the next morning and it's crashed, but, uh, we try to replicate it and we can't manage to replicate it. So it's pretty tricky. Um, memory errors are a fact of life, especially on the Sam D 21, which has had, which has 32 kilobytes of RAM total. Which is what I'm running my code in as well as what I'm using as part of my code, plus Python needs some of it. Yes, yep. Yeah, it's quite the challenge. It's very fun as a computer science-y sort of person

to really get into the weeds on how that all works. Typically, it's memory fragmentation that kills you. It's not that you're actually using the whole area, it's that you've fragmented it. One of the things that I've done in CircuitPython that Damien's aware of for MicroPython, but he was rightfully wary of it, is that when you import a module, for example, we'll recognize that that's going to last forever more that your code is running. And so what we'll do is we'll actually allocate it in a different spot in the heap with the hope that that spot in the heap is densely allocated for the rest of the time. And it does help with fragmentation, but it doesn't solve the problem.

So we're still experimenting with it. The SAMD51, which all of our M4 boards have, has 192 kilobytes of RAM, which is awesome. And you can still fill it up. We have some folks working on mechanical keyboard controller and they were asking about memory errors. But then the other thing is that like this low cost microcontroller range is still growing kind of at Moore's law rate.

So it's only a matter of time before the like, I've been looking at the IMX RT series and, you know, they have lots, lots more RAM and lots more CPU speed to deal with. So there's a couple ways to handle RAM. One is just buy a bigger chip. Wait a year. Or wait a year, yeah. So it's interesting and fun to deal with.

You have a bunch of boards you support, all of which seem to be Adafruit boards, almost all of which seem to be adafruit boards almost all of which seem to be adafruit boards if i want to support a different board how do i either get you to do it or how do i how do i port it so we have uh we're actually writing a guide i'm writing a guide about it right now because we have been sending the same pieces of information to people on how to do this repeatedly and would have be much easier to point them to a single place. There is a, in CircuitPython, there is a set of files which identify the board, identify the pins on the board, identify the flash chip crystal configuration, all of that information. And from there, CircuitPython, when Travis runs, it builds the firmware for that particular board. And so to add support to it, you would make the changes to

those files to match your board configuration and then add your board to one file that tells Travis, hey, this board exists, please look in this directory and find these files and build me some firmware. And then at that point, every time Travis runs the, is it a cron job, Scott? We do have a cron job, but this, Travis just runs every time we'd make a commit to the repository. I wasn't sure if that was also doing it. So every time Travis runs, it builds the firmware that we have a list of in that, in that file. And then at that point, the firmware is built for your board and you have it. So you could do that manually as well to build your own firmware if you, for whatever reason, didn't want

it done automatically. But at that point, it's actually done automatically. And then it shows up as an asset available for download. Right. So the first and foremost, if somebody wants to get CircuitPython running on their board, they should always reach out to us. We're happy to help people even if it's not Adafruit hardware. It's harder for us to justify supporting non-Adafruit hardware ourselves and doing that work ourselves, but we're always happy to help people do that. if you have a samd 2151 or an nrf 52840 based board already the process is as katni was saying and it's very easy if you're not using one of those kind of three chips it's going to be a lot more work because we don't have the foundation to build on but that doesn't mean it's not possible it just means it's going to be a bit more work. Who's this Travis dude? Travis is a continuous integration tool. Oh, so Jenkins is cousin. Yes. Yeah. And they, they have, uh, an open source tier where you can have five concurrent jobs running at once. Um, which is not bad, except we're yeah well we're building 700 plus assets every

commit now um because not only are we building one per board but we now support 11 human languages um so all of the error messages are translatable so we have like french german italian tagalog like all sorts of different translations as well. And we build one copy of CircuitPython for every board for every language. So it takes a little time to run. And every time we do a PR for a library, it also runs on the same Travis jobs. So inevitably, we would always get caught behind a CircuitPython build. You mentioned NRF52-based boards.

The 840 specifically, yeah. Those are Bluetooth boards. Do you support Bluetooth? They are. Bluetooth support's getting better and better by the day. Dan Halbert, who works on the core with me for Adafruit as well, has been doing a lot of really awesome work um so expect to see more ble stuff coming um he just got central mode working i know so um yeah more and more we're supporting bluetooth and uh i'm very interested in working on that like same sort of workflow of edit a file, but over Bluetooth as well, which is going to be really

fun. At the moment, you can actually, there is an app available for mobile that allows you to send packets to the NRF52840 board. So you could, for example, hook up some LEDs and there's a color picker in the app and you can change the color of the LEDs from your phone. So that is already supported. All right. I'm not going to ask about GAT design and wander down the BLE hole instead. Well, the gist of that is that it's the just Nordics UART server under the head. Okay. Well, that's useful. That's where we started. Yeah. But we that's useful. That's where we started. Yeah, no.

But we're adding more. Another rabbit hole we could wander down that you probably don't want to. I love rabbit holes. Could you explain Python's global interpreter law? I thought you were going to say, can you explain Python? Not very well. I don't actually know a whole lot of the details about it. Um, as far as I know, we don't have a global lock, uh, within micropython slash circuit python. Uh, but we do have a lock on the heap. Uh, so we concurrency is, is a little bit tricky

because of that. I mean, that's what the interpreter lock is for. Python says they have threads. They have these things called threads. But you can't actually run more than one thing at a time because it isn't memory safe between the threads. It just runs one thing at a time. And that's the global interpreter lock, and it's a source of much angst for those of us who need many threads.

Okay, so going on from there. Blinka, I have discovered that you have Blinka tattoos. How do I get those if I, you know, need a hundred of them? Now, sorry, that's not the question. What is Blinka, and is it only for Linux systems? So, yes. Blinka is a wrapper library that exposes all of the APIs that CircuitPython uses, and then makes it so that you can run CircuitPython libraries on Linux-based single-board computers. In CPython.

In CPython. Oh, that kind of actually answers a different question, which is, is there an interpreter I can run locally so that I can test out my CircuitPython things without going to a board? So you can actually run, there is a Unix port of MicroPython that is used a lot for tests

that still does work in CircuitPython. So you can run it locally, but we recommend just using CPython if you have a full Linux system. It's one of these things where I want to be able to verify my code before putting it on the microcontroller. And because I could just use CPython, I might be using libraries that aren't available. And so I want to be able to test it in a simulator.

Why not just test it on hardware? Well, for one thing, if I have a good simulator, then I don't care as much about which hardware I have. I can choose the hardware later. And I can test things if it's going to run on different processors, kind of like what you have to do, where you have to compile for so many different platforms. If I need to compile for multiple platforms, then having a simulator lets me have the first level of assurance. Could I suggest that you don't want to be using CircuitPython

if you're doing something like that? That is true. I mean, yes, now I'm back to let's just ship a million of something, and that's probably not what you need. I'm pushing you that on a little bit because our goal is to make it really easy to get code on a device. And I think the simulators have more of a place in cases where it's hard to get code on a device, but our goal is to make it really quick and easy to do that.

Simulators have the advantage that they are often easier to debug. So I understand your point. And it totally, I mean, for the situation you're describing where you're teaching people to code, I understand your point. And it totally, I mean, for the situation you're describing where you're teaching people to code, I should stop arguing. No, I think it's a good point. I think the other thing to realize is that like boards are easy to support in CircuitPython if they have the right chipset, because the reality is, is that most of it's all the same between boards, right? Like there's really not that much different from board to board.

So if you had to start on something like a Metro, which is like Arduino Uno shaped, it's very easy to go to the Circuit Playground Express or to a Feather Form Factor thing. There's not much actual difference between those things. No, that makes sense. I mean, you have the hardware abstraction layer, and it doesn't really matter what's above it.

Yeah, right. It changes a lot more from chip family to chip family. The implementation does. Okay, so back to Blinka. Maybe I didn't understand what it was. It allows you to run your CircuitPython on single board computers like Raspberry Pi. CircuitPython libraries. So the idea is that you can pip install a library. So you have a breakout, for example, a sensor, you have this

light sensor you want to use with your Raspberry Pi. You wire it up to your Raspberry Pi and instead of using or finding Python code to use with it, you would pip install the library that goes with that breakout. And then you can run the same example that exists for CircuitPython using CPython, and it just works. So, for example, I was talking about two of our different modules that we exposed from CLan and CircuitPython. One was digital IO, which you would do import digital IO, and that's what you use for toggling pins on and off. There's also PulseIO, which does PWM out sorts of stuff. Python library that exposes those same modules in C Python. So it's interfacing with the Linux kernel in order to twiddle pins on and off for you and exposes the same API that all of the Python libraries are built on that CircuitPython also exposes. Okay. I'm understanding now. Good. Awesome.

Okay, now I'm giving a presentation soon about profiling Python and optimizing it. And there are tools for finding bottlenecks. There's the built-in, I mean, with CPython, the normal command line Python, you can type in dash mcprofile or whatever it is, and you get statistics out. Are you supporting any of the tools that would help people figure out why they're running out of RAM and cycles? Or is that just not part of ease of use? I would love to, but yeah, it's not really something you run into in the very first five minutes. Yeah, so it's something that I'm interested in and I'm interested to see your talk because I actually don't know CPython tooling that well. But in general, our goal is to model ourselves after what c python does so we would try to be provide like a subset of the tooling that would you would use

from c python um but right now we're not not there by any means just import profile one thing i was thinking about was like being able to basically tell the tell the gc like oh i between here and here i don't want to allocate anything right and then have it raise an exception if you if you end up doing it which is weird it's weird to write python and worry about memory allocations uh but it is worth thinking about especially because uh one of our main challenges is fragmentation the more allocations you're doing the more fragmented you'll end up being or even just having a periodic here's the state of memory kind of print out which might be disruptive to your program but yeah i did i i've actually done some some uh instrumentation where i just use a Jlink to dump memory every allocation and every free.

And then I've made pretty graphs of what's allocated where over time. They're mesmerizing. Yeah. That's the advantage of having 32K RAM is that with your laptop or your desktop, you can just capture it every time and then go back and look at it later. Yes, the advantage of 32k RAM, you can count every byte. Okay, well, Katni, you work with PyCon. Yes. What do you do for them?

So I don't work directly with PyCon itself. The organization that I did this year was entirely surrounding our presence as Adafruit at PyCon. In terms of official presence, Adafruit sponsored the swag bag with hardware. We gave everyone Circuit Playground Expresses this wanted to add something to it, having a worksheet ready, being prepared with a number of examples available on a GitHub repo, and just having a curriculum almost for people to come in who had no idea what they were doing and wanted to get started. As well, we did sprints after the official conference was over. And the thing about CircuitPython is that a lot of what is done with CircuitPython is done with the libraries. And you can't really work on the libraries without the hardware. So I ended up putting together two of literally every piece of hardware that we support, which ended up in a six-hour marathon soldering session with someone else as well.

And had all that put together. And because we found that last year we blew through a lot of the easier issues real quickly and kind of ran out of things for people to do because it left only core issues, which the core is written in C and not everyone at PyCon knows C. So we ended up having a ton of Python work for people to do and had an amazing response to it. People were really into it, wanted to help out, wanted to learn how to help out. And because we had all the hardware, I was able to either provide them with that hardware to work with the libraries. And in a lot of cases, I actually sent people home with the stuff that they were working on so they could continue to work on it at home if they chose

to. And it sounds like the response was pretty good. When I think of PyCon, I always think of the big libraries, the NumPy's and the TensorFlow and Jupyter. how was the response? Did most people think, oh, this is awesome? Or were people like, yeah, this is too small? There were a couple people, which I think is out of the number of people there is a fairly standard representation of how often we get that sort of feedback, who obviously said, you know, why are you, you know, doing it this way? Why don't you? Many of the questions that you've asked us today. But for the most part, people were fascinated by it and wanted to be a part of it. We had a group of high schoolers who joined us because we had one of them join us in sprints

last year. And they all talked about it and wanted a place where they thought they would feel welcome and that they could learn. And the one who had spent time with us last year immediately said that they should go and sprint with us. And they did. And the amount of work they got done was unbelievable. They were incredibly into it. And there were some of them that were brand new.

So we helped them with their new Circuit Playground Expresses and others of them who were beyond my knowledge level, who were fixing bugs that we had been fighting with for weeks and getting all kinds of stuff done. And they all responded incredibly positively reporting that they learned a lot. They felt welcome. They felt like they could be themselves and felt like we provided them an amazing environment. And that was really what we were going for. Like that was the exact thing. We wanted the sprint to be like, what is it that you want to do with CircuitPython or really with anything in general, if it's something we can facilitate through CircuitPython, we will. And it happened exactly like we wanted it to. The sprints normally cut the amount of attendance cuts in half each day. And that really didn't happen.

The three days in, we still had the same amount of people that we had the day before, which did make it a little bit difficult because the number of us that were there was dwindling each day. But it was absolutely worth it to just see how many people were interested in things and working on their own projects and working on our projects and just contributing or learning. And I have been a skeptic because this board is not for me. It is not in the directions I go. And yet I find it really interesting. And I did see, Katni wrote instructions on how to contribute to CircuitPython and they were sensible instructions. So, so many times contributing to open source things is a little scary, but you have your discord server where you talk to people and it's social and

everybody's very nice and you can ask questions and nobody says that's a stupid question it's just yeah i can totally see why even as some people are like yeah that's too small or that's not for me there's a lot of goodness with the circuit python especially for getting people interested and i like the physicality of it because, yeah, just pushing data around. It's fun to make pretty pictures for a little while, but when you can actually build something you can touch, of course I think that's better. Building our community has been an explicit goal of ours.

It's worth it. For anyone who runs an open source project, it is time and it is work. But having a code of conduct and supporting your new contributors is well worth the effort in the long run. So we always prioritize getting people ramped up over everything else.

Okay, now I have a couple personal questions for you. What's it like working at Adafruit? It's been an amazing experience for me. I started as a member of the community working on a project that within the first couple of weeks of starting the program, working on a project that I wanted to share, and asked to write a guide for it and was accepted. And then proceeded to spend three months. Scott basically said to me within a couple weeks of me getting started that there was a library that he had started for the Circuit Playground Express. And he wanted me to finish it, which sounded ridiculous. However, he made it clear that he was going to help me. I could do it. And he, you know, and insisted that working with me was a priority for him. And so I went from not knowing how to program to writing what is now

the basically the library that we use for this, you know, premier board that we sell. And so it took three months cause I continually broke my code. Um, but at the end of that, I asked to come on part-time and was accepted, uh, two months later asked to come on full-time. And so for me, it went from a passion and a dream that I didn't know I had to working for this company. So it's been an amazing experience for me. Absolutely. Do you have to do much besides the open source code? I mean, you mentioned traveling to PyCon, which is partially advertisement for the company that pays you. But how much time do you spend selling Adafruit things versus doing work that goes out into the public that Adafruit doesn't necessarily get paid for?

So that's a good question. A lot of what I do, I think, ends with Adafruit getting paid. But representing Adafruit at PyCon, while it does result in sales and so on, bringing people into the community and bringing people into CircuitPython and teaching people to code is really the more important part of it for me. You know, to be able to watch someone go through the same first five minutes that I went through is an amazing experience. A lot of what I do definitely affects the bottom line. But I also provide an experience to people who are trying to learn, who are trying to join the STEM world. And having gone through that not that long ago, it's still a major goal of mine to make sure that that experience is available to others. Okay, Scott, same questions. Well, one back, what's it like working for Adafruit? So I think we should say explicitly that we both actually work remotely, which is interesting. That's been, it's very different. So my background is like, I was at Google for six years and

coming from a place where I was like six levels deep between me and the CEO to working regularly with Lamore, who owns Adafruit is just awesome. Um, it's amazing to see all the hard work that she puts into everything that's engineered for Adafruit and how the buck stops with her. And then, um, she also trusts my judgment on a lot of things, which I really appreciate as well. So it's very, just very fortunate. Somebody, I was on Ask an Engineer, which is our, our weekly live show. And I was in New York, I think. And somebody said in the chat, like, congrats, you found a job better than Google.

And I, I, I do feel that way, uh, because I get to work with the people who make the decisions every day and work on open source code so that like you can see what I worked on all week, for example. It's not this like black hole of talent like Google can be. Yeah, I mean, that's why I work for little companies, because at the end of the day, if I didn't show up, it made a difference. And sometimes with the big companies, you can feel like, well, at the end of the day, they didn't use my code. I could have just gone on vacation. Christopher is carefully not saying anything. It's hilarious.

I would say that's something that very rarely happens here. What we do is always what is is actually going on yeah and and as scott said you you see your progress in github you see your progress on discord with people engaging that's pretty cool uh so one more question for you both. Do you have projects that have been built with CircuitPython that you have just found to be beyond what you thought could be done and are cool? What projects do you, most interesting builds? I think for me, it's not, the thing that gets me most excited is not the complexity of the projects that people make.

It was the first time. the thing that gets me most excited is not the complexity of the projects that people make. It was the like first time. So at PyCon, the open space is you put up on a board that you're going to be in some, in a room for an hour. And if people want to come and check CircuitPython out, they can. The first open space we did, not this last PyCon, but the previous one, I was worried that the room was full and we would have to kick everybody out because they were all early. And then I realized, like, no, these people are here for CircuitPython. And being in that room full of people who are software people by training and learning that they can poke something and write software for something that reacts to their touch.

Being in a room full of people doing that first five minutes is way more inspiring to me than the other end of the spectrum of people doing very complex things. That's my personal inspiration, I guess. So Scott's saying that every time he lights a spark in somebody, that's his most interesting build. Yeah, I think so. And the challenge is, you know, doing that for as many people as possible. Becomes like a drug.

And I think it's the same for me. I remember, so my first project was a light-up tone piano that played a different tone and lit up a different color for every touchpad that you touched on the Circuit Playground Express. And then I added fruit to it so that you touch the fruit and made noise. What kind of fruit? It was key limes. And the project was called Piano in the Key of Lime. So not long after, maybe a couple months after I published it, there was someone on Discord who came on and said that they wanted their eight-year-old to be able to ask questions on Discord. And it turns out she was going through my project.

And that was an incredible feeling because you write a guide and sure it has views and maybe people are doing something with it, but you never know that they're doing anything with it because you're just putting it out there and people are absorbing it on their own time and their own space. And this was the first time that I'd ever helped someone walking through knowing that they were actually doing this project that I had put so much effort into. And that was a really amazing experience for me to be able to help this girl who was running into issues with my project, which most of her issues were the fact that she was impatient and was not actually reading any of the beginning of the guide. She went straight to the end. Hey, just show me the code. Exactly. Um, so I kept having

to walk her back through like the steps that were covered earlier in the guide. Like, Hey, you still have to do this step. Um, but it was an amazing experience. And then she ended up with, she and her dad ended up taking it and expanding on it and turning into something else. And then came on, uh, our show Intel stream, which we have every week as well, where people can come on and show projects that they're working on. And I got to see this thing that I had designed turned into something else by someone else, which is kind of the whole point of open source. And it was an amazing experience. And so just watching people learning and going through the same beginning experience I had is incredible. And I would agree, probably far more amazing than

the most complex of projects. There are still some fascinating complex projects, but for the most part, it's really what people are passionate about. Seeing passion is better. Now, I feel like this part's going to be a bit redundant. Scott, do you have any thoughts you'd like to leave us with? Yeah, the thoughts I try it. I know that your audience can be more professional embedded engineers. And even though we've spent the whole hour saying that you're not our audience, I would encourage you to try CircuitPython anyway. Even if you don't end up using CircuitPython

itself, you may pick up on things that are interesting and easier and better for the projects that you are doing going forward. So I would encourage everyone to try it. Don't be scared of it. Just give it a go. And don't be a snob. And I totally agree with that because I tried Arduino and it's really cool. It's got its place. And I'll try CircuitPython now that I know what to expect. Okay, Katni, what about you? Do you have any thoughts to leave us with? Scott kind of covered some of it. I would say the other thing is check out our community. If nothing else, the amount of passion and interest and engagement that exists there can be very exhilarating and can perhaps excite you about something that you may not otherwise have been

excited about and bring another level to your CircuitPython experience. And obviously, we're there to answer questions that anyone who is using CircuitPython is having, but so is the rest of our community. And you can see what they're working on as they work on it and iterate on it and so on. And you may see a different aspect of it that you hadn't considered. And that may change your outlook on the whole thing and how you might actually use it yourself. Cool. Our guests have been Scott Shawcroft and Katni Rembor from Adafruit. Check out circuitpython.org. It may lead you to many interesting things.

Thanks, Katni and Scott. Thanks for having us. Yeah, thank you. Thank you to Chris Greenlee, Alex, and SPE for adding to my outline about CircuitPython. I announced it last week and forgot to announce it at the top, but don't forget we're having a party. None of you will be able to come, like less than 1%, much less than 1%. But we are having it. So those of you who can come,

all right. It's Saturday, September 7th in Aptos, California. The invites or Eventbrite or whatever the thing is will be out August 1st. Okay, with that all said, I should also thank Christopher for producing and co-hosting. And thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. And now a joke to leave you with. It would have been nice if I read these jokes ahead of time so that I knew that they were safe. But let's just go ahead. It's called a cute wabbit. How can it be bad? A little girl goes into a pet show and asks for a wabbit. The shopkeeper looks down at

her smiles and says, would you like a lovely fluffy little white wabbit or a cutesy wootsy little brown rabbit? Actually, says the little girl, I don't think my python would notice. Embedded is an independently produced radio show that focuses on the many aspects of engineering. Thank you.