295: In the Key of Lime
Transcript from 295: In the Key of Lime with Kattni Rembor, Scott Shawcroft., Elecia White, and Christopher White.
EW (00:00:07):
Welcome to Embedded. I am Elecia 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, Kattni Rembor and Scott Shawcroft are here from Adafruit to talk entirely about CircuitPython.
CW (00:00:32):
Hi, Kattni. Hi, Scott. Thanks for joining us.
SS (00:00:34):
Hi.
KR (00:00:34):
Hello.
SS (00:00:34):
Thanks for having us.
KR (00:00:35):
Thanks for having us.
EW (00:00:36):
Kattni, could you tell us about yourself?
KR (00:00:39):
Sure. So I'm Kattni. 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.
KR (00:00:57):
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.
EW (00:01:08):
Cool. Scott, what about you?
SS (00:01:11):
I'm Scott Shawcroft. I am a software person by training, so I was at Google for six years before I left that and 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.
EW (00:01:30):
Oh, we have questions about how that transition happened.
SS (00:01:34):
Yeah. I'm planning on addressing that.
EW (00:01:36):
First we want to do lightning round, where we ask you short questions, and we want short answers. Are you ready?
KR (00:01:45):
Yep.
CW (00:01:45):
True or false: Python was named for the snake and its ability to eat things whole?
KR (00:01:50):
False.
CW (00:01:52):
Correct. It was named for Monty Python, which I didn't know.
EW (00:01:56):
Part of keeping it fun to use. And so with that in mind, what is your name?
KR (00:02:05):
Kattni Rembor.
CW (00:02:08):
What is your favorite color?
KR (00:02:09):
Purple.
SS (00:02:10):
Blue. No, yellow.
EW (00:02:14):
What is the air speed velocity of an unladen swallow?
KR (00:02:18):
Depends on weather. Yeah.
EW (00:02:23):
It's so sad when everybody knows the answers.
SS (00:02:26):
Well, I'm sure we will have some questions later where we don't have all the answers.
CW (00:02:30):
Can a Python eat a medium-sized American alligator?
KR (00:02:37):
Don't know the answer to that one.
SS (00:02:39):
Maybe.
EW (00:02:40):
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?
KR (00:02:59):
Depends on what Blinka's interested in at the time, I suppose.
EW (00:03:02):
Is that his name?
KR (00:03:04):
Her name. Yes.
EW (00:03:05):
Oh, okay. The snake has a name. It's name is Blink?
SS (00:03:10):
Blinka.
KR (00:03:10):
Blinka.
EW (00:03:11):
Blinka. Oh, I have questions about Blinka. Wait a minute. I thought that was some sort of software thing.
SS (00:03:18):
It is also.
KR (00:03:19):
Yes.
EW (00:03:20):
Okay. We're going to have -
SS (00:03:21):
It's both our mascot and a software thing.
EW (00:03:24):
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?
KR (00:03:41):
So CircuitPython is a derivative of MicroPython...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.
KR (00:04:04):
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.
EW (00:04:19):
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?
SS (00:04:30):
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.
SS (00:04:42):
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 kept making code, and getting things working.
SS (00:05:08):
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 a consistent API that all of those drivers can be built upon.
SS (00:05:29):
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.
SS (00:05:52):
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 features of a microcontroller available, whereas I was willing to hide the advanced stuff in favor of having consistency.
SS (00:06:13):
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 MicroPython, 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.
SS (00:06:35):
And Damien was still very at the time of having a company come in and fund a lot of development, but 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.
SS (00:06:52):
They were a startup. They pivoted away from it, and suddenly he was kind of left with the maintenance burden of that. 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.
SS (00:07:07):
So at that point we decided to rename from Adafruit MicroPython, which is what we were calling it, to CircuitPython.
SS (00:07:15):
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.
SS (00:07:34):
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?
EW (00:07:50):
Yeah, no, 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?
SS (00:08:11):
Yeah. 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.
SS (00:08:31):
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.
SS (00:09:00):
And one of the key differences that still exists between MicroPython and us is that both systems..., when you plug in a device that has MicroPython or CircuitPython unsolved, 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.
SS (00:09:21):
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.
CW (00:09:41):
Maybe this is a question for Kattni, 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?
EW (00:09:55):
Like, "Okay, I could go the Arduino route," or, "Now I could go the CircuitPython route." How do you resolve that, or are they marketed in slightly different ways and targeted in different ways?
KR (00:10:06):
I think they're definitely marketed and targeted in slightly different ways...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.
KR (00:10:24):
But the point was that I was attempting to learn Python and CircuitPython fit that, except it 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 works.
KR (00:10:52):
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.
KR (00:11:12):
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.
KR (00:11:28):
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.
EW (00:11:38):
So what I heard there was one, manipulating the physical world is much better than data, which I completely agree with. But two, CircuitPython 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?
EW (00:11:58):
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?"
KR (00:12:11):
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.
KR (00:12:25):
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?"
KR (00:12:38):
There are guides that can walk you through what hardware to purchase and what code to write to do that. And so it brings together both software and hardware, at least in the sense of what hardware support there is for CircuitPython.
EW (00:12:54):
And if somebody gets into CircuitPython 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?
SS (00:13:08):
No is the short answer, because -
EW (00:13:10):
Which is fine. Not everything needs to lead to production.
SS (00:13:13):
Right. So there is a pretty easy escape hatch into adding C code that you can call from Python. That's actually my job. 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.
SS (00:13:37):
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.
SS (00:13:50):
It doesn't mean it couldn't be, and it doesn't mean that somebody productionize it so that it was, but it's not our focus. And so we haven't done it.
EW (00:14:01):
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 CircuitPython?
SS (00:14:15):
Yeah, to some degree. It is an interpreter, but you compile down to a bytecode. And this is how CPython works as well. So C Python is the specific name for the...canonical Python on the desktop.
SS (00:14:30):
But basically the micro reads the text file that's on its file system and parses it, does AST things. And then it converts it into a bunch of structs with bytecode instructions in it. And that -
EW (00:14:44):
Wait, wait, wait. What's an AST thing?
SS (00:14:47):
An AST thing is an abstract syntax tree. So it's an intermediate data structure that represents your source code but is not text.
EW (00:14:58):
Okay.
SS (00:14:58):
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.
SS (00:15:08):
And then you can interpret that into 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.
EW (00:15:36):
So that's like the LLVM thing? We've talked about that. Chris is giving me faces. So -
SS (00:15:41):
Yeah, it's -
CW (00:15:43):
Not really. More like Java or sort of Java.
EW (00:15:49):
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?
SS (00:15:57):
Yeah. For CPython, that's where they cache the bytecode.
EW (00:16:01):
And on CircuitPython, where do you cache the bytecode?
SS (00:16:06):
We only store 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 distribute for bytecode that makes importing easier called .mpy, which is kind of the analog to .pyc, but we don't automatically write those back after we load a .py file.
EW (00:16:37):
Does that mean I can only write a program that can fit into RAM?
SS (00:16:42):
Yes.
EW (00:16:43):
Okay. So no giant programs, because most of these microcontrollers have Ks of RAM, not Ms of RAM.
SS (00:16:53):
Correct. Yeah. Yeah,...we've done some work on making our memory footprint more efficient. But in general, yes, you can't have giant programs. That wouldn't fit in there.
CW (00:17:10):
What's the reason to parse on device instead of doing it on the host and then pushing down the bytecode?
SS (00:17:17):
Because it's easy. You don't have to install a tool chain. It's already on the device for you.
CW (00:17:21):
Okay.
SS (00:17:22):
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.
EW (00:17:35):
I suspect for every time we're like, "Why do you do this thing that doesn't seem efficient to us, - "
CW (00:17:39):
Because it's easy.
EW (00:17:40):
The answer is going to be, "Because it's easy for people to use."
CW (00:17:43):
Yeah. Yeah.
SS (00:17:43):
Right.
CW (00:17:44):
Which is a good answer.
SS (00:17:45):
If I give you a device with CircuitPython on it,...you don't need to install anything, right? 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.
EW (00:18:00):
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?
KR (00:18:13):
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. 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.
KR (00:18:43):
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, temperature sensor, that sort of thing.
KR (00:18:56):
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.
EW (00:19:10):
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.
KR (00:19:23):
Correct.
SS (00:19:24):
Right. It's round.
EW (00:19:25):
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.
KR (00:19:34):
Yep.
EW (00:19:34):
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.
KR (00:19:42):
Yep.
EW (00:19:42):
And it's 25 bucks. And for 5 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...there's a file there, so I open it and then I just type away?
KR (00:20:06):
So in this case, you would actually need to install CircuitPython first...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/downloads...It's right there. You just search for it.
KR (00:20:26):
...When you double tap the board it shows up as CPLAYBOOT in all caps, and you just drag that file to the CPLAYBOOT drive. And it installs CircuitPython for you.
KR (00:20:39):
And at that point...you'd be able to begin coding by creating a code.py file and saving it to the CIRCUITPY drive that shows up after you drag that file that you downloaded to it.
EW (00:20:51):
Okay. So it has a bootloader, and we are downloading its Flash code.
KR (00:20:57):
Yes.
EW (00:20:57):
And then it gets written. And once it's written, then it has the Python, it's weird to call an interpreter. Is it really interpreter at that point? Or is it a compiler?
SS (00:21:09):
I would call it an interpreter, because it's not going all the way down to machine code.
EW (00:21:16):
But is there a command line, a REPL thing that I can type at?
SS (00:21:22):
You can.
KR (00:21:22):
There 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, and once -
EW (00:21:36):
[Ah], Mac users.
KR (00:21:37):
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.
KR (00:21:50):
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.
EW (00:22:04):
Okay. And then when I type import Matplotlib, what happens?
SS (00:22:09):
It raises an import error. Because we do not have it.
EW (00:22:12):
What can it import? What libraries do you have?
SS (00:22:15):
That's a good question. We have a very small subset of the standard C library or the standard CPython 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.
SS (00:22:31):
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.
SS (00:22:41):
And then on top of that, we've got a bunch of CircuitPython specific...modules that do all of the hardware abstraction stuff. So we have one called digitalio. And that's the thing that you would use to toggle a pin on and off, for example.
EW (00:22:59):
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.
SS (00:23:17):
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.
EW (00:23:27):
Fair enough.
SS (00:23:28):
I think for Limor, Ladyada, it was a very different realization for her. She's done Arduino for 10 years.
SS (00:23:35):
And the idea that making a mistake isn't fatal to the microcontroller, where you just get an error on the serial, like Kattni 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.
EW (00:23:58):
Well, I mean, that's one of the beautiful things about Python being an interpreted language. Sure, I will even really 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.
EW (00:24:15):
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 print even works," it's really helpful. Okay. So next question, Python 2 or 3?
SS (00:24:34):
3.
KR (00:24:37):
3.
EW (00:24:37):
I mean, that's totally the right answer. They tell us that 2020 is when 2 is going to be gone.
SS (00:24:42):
Yeah. At the start of 2020.
EW (00:24:45):
But all of my code says no.
SS (00:24:46):
Yeah. Python 3 is great for hardware. So MicroPython targeted Python 3.4 specifically.
EW (00:24:55):
3.4.
SS (00:24:55):
3.4. Yeah.
EW (00:24:56):
Okay.
SS (00:24:57):
And one of the really nice things about Python 3 versus 2 is that it has a byte string in a byte array built in type. Whereas in Python 2, there is 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.
SS (00:25:17):
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.
EW (00:25:26):
Oh, yes. If you've never gotten to play with the byte in coding in Python 2, you really haven't learned.
SS (00:25:32):
Yeah.
EW (00:25:32):
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?
SS (00:25:51):
So we don't support interrupts from Python.
EW (00:25:55):
Oh.
SS (00:25:55):
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.
SS (00:26:12):
...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.
EW (00:26:25):
So you do have interrupts. You just don't let you users who are stuck in Python use them.
SS (00:26:31):
Correct. So behind the scenes, a lot of interrupts are happening...USB incoming stuff is all interrupt based as well, which is...one of the reasons we can't make promises about the timing of the Python code itself.
SS (00:26:44):
Because we have interrupts that we're doing, and then we also have some maintenance sort of tasks around writing to the file system for USB and things like that that can cause your Python code itself to run with different timing.
SS (00:27:03):
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.
EW (00:27:13):
With the variable timing, the lack of a certain latency, deterministic, a lack of determinism, -
SS (00:27:24):
Right.
EW (00:27:24):
- do you have people complaining about that?...I mean, that's part of Python. I mean, CPython does garbage collection whenever it feels like it.
SS (00:27:37):
Right. Yeah. 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, "We got this. We got you covered."
SS (00:27:58):
Here's the thing that does pulse timing measurement, for example, on your behalf, in the background, and that C that I've written, or Dan's written, or some of our community members have written, we actually try to offload that off the CPU straight away as well.
SS (00:28:13):
So if we can use DMA to do those timing sensitive things or the peripherals, we will, which is good for CircuitPython in general, to get it off the CPU.
EW (00:28:24):
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.
SS (00:28:34):
Right. And...as I was more and more willing to work away from the hardware API that MicroPython was trying to establish, theirs was very referral centric, right?
SS (00:28:47):
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.
EW (00:29:08):
Oh, so much.
SS (00:29:10):
Right. So I was like, "...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 pulse IO where it has pulse in, so that's infrared timing and DHT sensor stuff. And then we have PWMOut, which is PWM out. Of course.
SS (00:29:32):
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.
EW (00:29:53):
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.
SS (00:30:12):
Well, you don't have to accept that because it's all open source. You can always dig into the C code and see exactly how we're doing it.
EW (00:30:19):
Well, 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 you have great interfaces. So if I end up, anyway, blah, blah, blah.
SS (00:30:33):
That's the goal.
EW (00:30:34):
Yes.
SS (00:30:35):
The goal is to have good interfaces.
EW (00:30:37):
You do support other pieces of hardware. They aren't shields. What are they, snake skins?...What do you call them?
KR (00:30:47):
So we actually do support some shields...We don't have a name for CircuitPython specific hardware. We support -
EW (00:30:54):
We should come up with one.
KR (00:30:55):
Right. We support sensors in different form factors. So breakouts, shields, pyHATs -
SS (00:31:02):
FeatherWings.
KR (00:31:02):
FeatherWings, that sort of thing. And so it just depends on the form factor, what it's called.
EW (00:31:10):
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 -
KR (00:31:23):
No.
EW (00:31:23):
- Scott has been saying. No. No?
KR (00:31:25):
So there are libraries in C that are built into CircuitPython. However, for the hardware, we're actually writing Python libraries.
EW (00:31:33):
That seems inefficient. And you're using my RAM, which I didn't have that much to start with.
SS (00:31:38):
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.
SS (00:32:02):
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.
SS (00:32:21):
But we need that core C for timing sensitive and interfacing directly with the hardware. Besides that it should be in Python.
EW (00:32:30):
Okay. I know there's a FeatherWing that has a nice display on it...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?
SS (00:32:54):
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 late '80s hardware works.
SS (00:33:07):
So the Game Boy, and specifically where, from Python, you define the objects that you want on the screen and the bit maps that make up those objects, rather than -
EW (00:33:17):
Sprites.
SS (00:33:17):
- just having a frame buffer. Exactly. So it's sprite-based. And then 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.
EW (00:33:41):
...Is there a layer? I mean, I want to say C subterfuge, but that's not the right word, sublayer, to support hardware. I mean, Python doesn't come with -
SS (00:33:56):
It's true. Yeah.
EW (00:33:57):
- a display subsystem.
SS (00:33:59):
Right. Yeah. I mean, this is where CircuitPython...starts to become an OS.
EW (00:34:06):
Yeah, that's the thing.
SS (00:34:08):
We manage file system mounting, that sort of stuff where we have what I've dubbed the supervisor layer, which is the layer of C that runs from startup all the way to the end when you turn it off.
SS (00:34:21):
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.
SS (00:34:32):
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.
SS (00:34:43):
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.
EW (00:34:58):
Yes. So much.
SS (00:34:58):
Because people sometimes have trouble connecting to the serial -
EW (00:35:02):
Yes.
SS (00:35:02):
- link and that's where your stack traces and your exceptions go. So by being smart enough to say, "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.
EW (00:35:20):
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 ten of them for my family." Even if I'm not going to production -
SS (00:35:36):
Right.
EW (00:35:37):
- there's still some level of making it robust. How robust is it? I mean,...there were mentions in things about memory error. How stable is both the code and the system as it runs?
SS (00:36:02):
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 PyPortal, which, the goal is to have a screen that sits and can wirelessly communicate, and pull data down, and display it.
SS (00:36:20):
And occasionally we hear about people where...they left it overnight, and it doesn't work, or you wake up the next morning, and it's crashed. But we try to replicate it, and we can't manage to replicate it. So it's pretty tricky.
EW (00:36:35):
Yes.
SS (00:36:35):
Memory errors are a fact of life, especially on the SAMD21, which has 32 kilobytes of RAM total, but -
EW (00:36:48):
Which is what I'm running my code in as well as what I'm using -
SS (00:36:52):
Correct.
EW (00:36:52):
- as part of my code, plus Python needs some of it.
SS (00:36:56):
Yes. Yep. Yeah. It's quite the challenge, -
EW (00:36:59):
That's not much.
SS (00:36:59):
- and 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.
EW (00:37:13):
Yeah.
SS (00:37:13):
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 forevermore that your code is running.
SS (00:37:35):
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.
SS (00:37:48):
So we're still experimenting with it. The SAMD51, which all of our M4 boards have, has 192 kilobytes of RAM, which is awesome.
EW (00:38:00):
Yeah.
SS (00:38:00):
You can still fill it up. We have some folks working on a mechanical keyboard controller, and they were asking about memory errors. But then the other thing is that this low cost microcontroller range is still growing kind of at Moore's Law rate.
SS (00:38:17):
...I've been looking at the i.MX RT series, and they have 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.
EW (00:38:34):
Wait a year.
SS (00:38:35):
Or wait a year. Yeah. So it's interesting, and fun to deal with.
EW (00:38:42):
You have a bunch of boards you support,...almost all of which seem to be Adafruit boards. If I want to support a different board, how do I either get to do it, or how do I port it?
KR (00:38:59):
So...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 it would be much easier to point them to a single place.
KR (00:39:13):
...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,...I think it's when Travis runs, it builds the firmware for that particular board.
KR (00:39:43):
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, is it a cron job, Scott?
SS (00:40:07):
We do have a cron job, but Travis just runs every time we make a commit to the repository.
KR (00:40:12):
I wasn't sure if that was also doing it.
SS (00:40:13):
Yeah.
KR (00:40:13):
So every time Travis runs, it builds the firmware that we have a list of 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.
KR (00:40:30):
But at that point it's actually done automatically. And then it shows up as an asset available for download.
SS (00:40:40):
Right. So 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.
SS (00:40:57):
But we're always happy to help people do that. If you have a SAMD21, 51, or an NRF52840 based board already, the process is, as Kattni was saying, it's very easy.
SS (00:41:10):
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.
CW (00:41:23):
Who's this Travis dude?
KR (00:41:27):
Travis is a continuous integration tool.
CW (00:41:30):
Oh, so Jenkins' cousin.
KR (00:41:32):
Yes.
SS (00:41:33):
Yeah. And they have an open source tier where you can have five concurrent jobs running at once -
CW (00:41:40):
That's not bad.
SS (00:41:40):
- which is not bad except we're building -
CW (00:41:44):
Yeah, well.
SS (00:41:44):
- 700 plus assets every commit now. Because not only are we building one per board, but we now support 11 human languages. So all of the error messages are translatable.
SS (00:41:59):
So we have French, German, Italian, Tagalog, 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.
KR (00:42:14):
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.
EW (00:42:26):
You mentioned NRF52 based-boards, those -
SS (00:42:30):
The 840 specifically. Yeah.
EW (00:42:33):
Those are Bluetooth ports. Do you support Bluetooth?
SS (00:42:36):
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. So expect to see more BLE stuff coming. He just got central mode working, I know.
SS (00:42:53):
So yeah, more and more, we're supporting Bluetooth. And I'm very interested in working on the same sort of workflow of edit a file, but over Bluetooth as well, which is going to be really fun.
EW (00:43:06):
Yeah.
KR (00:43:07):
At the moment, there is an app available for mobile that allows you to send packets to the NF52840 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.
EW (00:43:28):
Alright. I'm not going to ask about GATT design and wander down the BLE hole. Instead -
SS (00:43:36):
Well, the gist of that is that it's just Nordic's UART server under the hood.
EW (00:43:40):
[Ah], okay. Well, that's useful.
SS (00:43:43):
That's where we started.
EW (00:43:45):
Yeah, no, except -
SS (00:43:46):
But we're adding more.
EW (00:43:48):
Another rabbit hole we could wander down that you probably don't want to, could you -
SS (00:43:53):
I love rabbit holes.
EW (00:43:55):
- explain Python's global interpreter lock?
CW (00:43:58):
I thought you were going to say, "Can you explain Python?"
SS (00:44:02):
Not very well. I don't actually know a whole lot of the details about it. As far as I know, we don't have a global lock within MicroPython/CircuitPython. But we do have a lock on the heap. So concurrency is a little bit tricky because of that.
EW (00:44:23):
I mean, that's what the interpreter lock is for, is 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.
SS (00:44:38):
Right.
EW (00:44:38):
It just runs one thing at a time.
SS (00:44:40):
Right.
EW (00:44:40):
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 need 100 of them? No, sorry. That's not the question. What is Blinka? And is it only for Linux systems?
KR (00:45:05):
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.
SS (00:45:22):
In C Python.
KR (00:45:23):
In C Python.
EW (00:45:25):
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?"
SS (00:45:36):
So...there is a Unix port of MicroPython that is used a lot for tests that still does work in CircuitPython. So you can run that locally, but we recommend just using CPython if you have a full Linux system.
EW (00:45:51):
Well,...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.
SS (00:46:07):
Right.
EW (00:46:07):
And so I want to be able to test it in a simulator. I can't -
SS (00:46:12):
Why not just test it on hardware?
EW (00:46:15):
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.
EW (00:46:28):
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 from multiple platforms, then having a simulator, lets me have the first level of assurance.
CW (00:46:47):
Could I suggest that you don't want to be using CircuitPython if you're doing something like that?
EW (00:46:51):
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.
SS (00:46:57):
I'm pushing you on that 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 to make it really quick and easy to do that.
EW (00:47:16):
Simulators have the advantage that they are often easier to debug. So I understand your point, and...I mean, for the situation you're describing where you're teaching people to code, I should stop arguing.
SS (00:47:29):
No, I think it's a good point. I think the other thing to realize is that boards are easy to support in CircuitPython if they have the right chip set, because the reality is that most of it's all the same between boards, right? There's really not that much different from board to boards.
SS (00:47:46):
So if you had to start on something like a Metro, which is 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.
EW (00:48:01):
Well, that makes sense. I mean, you have the hardware abstraction layer, and it does doesn't really matter what's above it.
SS (00:48:12):
Yeah. Right. It changes a lot more from chip family to chip family. The implementation does.
EW (00:48:18):
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.
KR (00:48:28):
CircuitPython libraries. So...you have a breakout, for example, a sensor, you have this light sensor you want to use with your Raspberry Pi.
KR (00:48:40):
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.
SS (00:49:00):
So for example, I was talking about two of our different modules that we exposed from C land and CircuitPython. One was digitalio, which you would do import digitaio. And that's what you use for toggling pins on and off. There's also pulse IO, which does PWM out sorts of stuff.
SS (00:49:18):
So Blinka is a CPython library that exposes those same modules in CPython. 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 the Python libraries are built on that CircuitPython also exposes.
EW (00:49:41):
Okay. I'm understanding now. I'm good. Good, good.
SS (00:49:45):
Awesome.
EW (00:49:47):
Okay. Now I'm giving a presentation soon about profiling Python and optimizing it. And there are tools for finding bottlenecks...I mean, with CPython, the normal command line Python, you can type in -m cProfile or whatever it is, and you get statistics out.
EW (00:50:14):
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?
SS (00:50:26):
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.
SS (00:50:43):
But in general, our goal is to model ourselves after what CPython does. So we would try to provide a subset of the tooling that you would use from CPython. But right now we're not there by any means.
EW (00:50:59):
Just import profile.
SS (00:51:03):
One thing I was thinking about was being able to basically tell the GC, "Oh, between here and here, I don't want to allocate anything."
CW (00:51:11):
Right.
SS (00:51:12):
And then have it raise an exception if you end up doing it, which is weird. It's weird to write Python and worry about memory allocations. But it is worth thinking about, especially because one of our main challenges is fragmentation. The more allocations you're doing, the more fragmented you'll end up being.
CW (00:51:30):
Or even just having a periodic here's the state of memory kind of printout, which might be disruptive to your program.
SS (00:51:38):
Yeah, I've actually done some instrumentation where I just use a J-Link to dump memory every allocation and every free(). And then I've made pretty graphs of what's allocated where over time.
KR (00:51:53):
They're mesmerizing.
SS (00:51:55):
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.
CW (00:52:06):
Yes. The advantage of 32K RAM, you can count every byte. Okay, well, Kattni you work with PyCon.
KR (00:52:17):
Yes.
EW (00:52:18):
What do you do for them?
KR (00:52:20):
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 year with the help of Digi-Key.
KR (00:52:38):
And the thing that I put a lot of effort into was, we did Open Spaces, which we could have just thrown together, but worked so much better with planning ahead.
KR (00:52:52):
Having peripheral hardware available for people to connect to their Circuit Playground Express if they wanted to add something to it, having a worksheet ready, being prepared with a number of examples available on a GitHub repo.
KR (00:53:04):
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.
KR (00:53:21):
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.
KR (00:53:31):
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. Because we found that last year we blew through a lot of the easier issues real quickly and kind of ran out things for people to do.
KR (00:53:55):
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.
KR (00:54:15):
And because we had all the hardware, I was able to...provide them with the 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.
EW (00:54:31):
And it sounds like the response was pretty good. When I think of PyCon, I always think of the big libraries, the NumPys, and the TensorFlow, and Jupyter. And I mean, how was the response? Did most people think, "Oh, this is awesome," or were people like, "Yeah, this is too small."
KR (00:54:51):
There were a couple people, which I think, out of the number of people there, is a fairly standard representation of how often we get that sort of feedback, who obviously said, "Why are you doing it this way," many of the questions that you've asked us today.
KR (00:55:08):
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.
KR (00:55:24):
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.
KR (00:55:39):
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 for weeks, and getting all kinds of stuff done. And they all responded incredibly positively, reporting that they learned a lot. They felt welcome.
KR (00:55:58):
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. 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?"
KR (00:56:16):
If it's something we can facilitate through CircuitPython, we will. And it happened exactly like we wanted it to. The sprints normally,...the amount of attendance cuts in half each day. And that really didn't happen. 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.
KR (00:56:35):
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.
EW (00:56:49):
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 Kattni wrote instructions on how to contribute to CircuitPython, and they were sensible instructions. So many times contributing to open source things is a little scary.
EW (00:57:14):
But you have your Discord server where you talk to people. And it's social, and everybody's very nice. You can ask questions, and nobody says, "That's a stupid question."
EW (00:57:27):
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 CircuitPython, especially for getting people interested. And I like the physicality of it.
EW (00:57:45):
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.
SS (00:58:00):
Building our community, it 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.
EW (00:58:22):
Okay. Now I have a couple personal questions for you. What's it like working at Adafruit?
KR (00:58:28):
It's been an amazing experience for me. I started as a member of the community...., that within the first couple weeks of starting a program, working on a project that I wanted to share and asked to write a guide for it, and was accepted.
KR (00:58:50):
...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.
KR (00:59:10):
I could do it, and and insisted that that working with me was a priority for him. And so I went from not knowing how to program, to writing what is now basically the library that we use for this premier board that we sell. And so it took three months, because I continually broke my code.
KR (00:59:29):
But at the end of that, I asked to come on part-time and was accepted, 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.
EW (00:59:53):
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?
KR (01:00:18):
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.
KR (01:00:47):
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.
KR (01:00:59):
But I also I 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.
EW (01:01:21):
Okay, Scott, same questions. Well, one back. What's it like working for Adafruit?
SS (01:01:26):
So I think we should say explicitly that we both actually work remotely, which is interesting...It's very different. So my background is, I was at Google for six years. And coming from a place where I was six levels deep between me and the CEO to working regularly with Limor who owns Adafruit is just awesome.
SS (01:01:50):
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 she also trusts my judgment on a lot of things which I really appreciate as well. So it's just very fortunate. I was on Ask an Engineer, which is our weekly live show, and I was in New York I think.
SS (01:02:16):
And somebody said in the chat, "Congrats, you found a job better than Google." And I do feel that way, because I get to work with the people who make the decisions every day and work on open source codes so that you can see what I worked on all week, for example. It's not this black hole of talent like Google can be.
EW (01:02:38):
Yeah. I mean, that's why I worked 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's carefully not saying anything. It's hilarious.
KR (01:03:00):
I would say that's something that very rarely happens here. What we do is always what is actually going on.
EW (01:03:10):
Yeah. And as Scott said, you see your progress in GitHub. You see your progress on Discord with people engaging. That's pretty cool. So one more question for you both.
EW (01:03:22):
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,...most interesting builds?
SS (01:03:37):
I think for me,...the thing that gets me most excited is not the complexity of the projects that people make...So at PyCon, the Open Space is, you put up on a board that you're going to be in a room for an hour. And if people want to come and check CircuitPython out, they can.
SS (01:04:00):
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."
SS (01:04:14):
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.
SS (01:04:37):
That's my personal inspiration, I guess.
EW (01:04:42):
So Scott's saying that every time he lights a spark in somebody, that's his most interesting build.
SS (01:04:48):
Yeah, I think so. And the challenge is doing that for as many people as possible.
EW (01:04:53):
Becomes like a drug.
KR (01:04:56):
And I think it's the same for me...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 touched the fruit and made noise.
SS (01:05:16):
What kind of fruit?
KR (01:05:17):
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.
KR (01:05:43):
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 in their own space.
KR (01:05:58):
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.
KR (01:06:07):
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.
CW (01:06:24):
Hey.
EW (01:06:25):
"Just show me the code."
KR (01:06:27):
Exactly. So I kept having to walk her back through the steps that were covered earlier in the guide, like, "Hey, you still have to do this step." But it was an amazing experience.
KR (01:06:36):
And then she and her dad ended up taking it, and expanding on it, and turning into something else. And then came on our Show and Tell stream, which we have every week as well, where people can come on and show projects that they're working on.
KR (01:06:50):
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.
KR (01:07:04):
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.
EW (01:07:27):
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?
SS (01:07:33):
Yeah. 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.
SS (01:07:48):
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.
EW (01:08:04):
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. Kattni, what about you? Do you have any thoughts to leave us with?
KR (01:08:22):
Well, Scott kind of covered some of it. I would say the other thing is, check out our community.
KR (01:08:28):
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.
KR (01:08:51):
And obviously we're there to answer questions that anyone who is using CircuitPython is having. But so is the rest of our community.
KR (01:08:59):
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.
EW (01:09:15):
Cool. Our guests have been Scott Shawcroft and Kattni Rembor from Adafruit. Check out circuitpython.org. It may lead you to many interesting things.
CW (01:09:30):
Thanks, Kattni and Scott.
KR (01:09:31):
Thanks for having us.
SS (01:09:33):
Yeah. Thank you.
EW (01:09:35):
Thank you to Chris Greenley, 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, less than 1%, much less than 1%. But we are having it.
CW (01:09:56):
What? Alright.
EW (01:09:56):
So those of you who can come, it's Saturday, September 7th, in Aptos, California. The evites, 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.
EW (01:10:21):
You can always contact us at show@embedded.fm, or hit the contact link on embedded.fm. And now a joke to leave you with it. It would've been nice if I read these jokes ahead of time so that I knew that they were safe, but let's just go ahead.
EW (01:10:38):
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."
EW (01:11:04):
Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California.
EW (01:11:14):
If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.