Welcome back to The Factory. This week, we do some arts and crafts to make sure that our GlowBit 8x8 matrix tiling scheme is working, and we shrink Python scripts to make them take up less flash on MicroPython devices. Let's do it.

And picking up where we left off last week, we were talking about the Glowbit matrix, the 8x8 Glowbit matrix with a tileable design. And I'm very pleased to announce that we have another prototype in the works. And this one is just so much more mature than our first prototype. There's a lot of good ideas baked into this.

The front should look pretty familiar. It's just 8x8 LEDs. You'll note that there are four through holes on each side, just for easy soldering. And on the back, this is where a lot of the thought has gone into. If I turn off through hole CAD, you can see that each edge is this pattern of surface mount pads. And those are both load bearing pads and power and signal distribution.

We took some design cues from the Adafruit NeoPixel matrix that has these large load bearing tabs all around the perimeter. And these are all just ground tabs. They're really just good for load bearing. On our tileable matrix, though, every edge has at least one VCC ground, D in and D out. And you'll notice something very special about the pattern here. From left to right, it's VCC, D in, D out, ground. And if we rotate it, VCC, D out, D in, ground. So this will actually be a tileable design without any air wiring whatsoever.

Now, 64 GlowBit LEDs are capable of drawing a monster amount of current. So we've also added these very large power distribution pads. The idea being that if you were gonna tile, say, a 3x3 of these matrices, you need a fair bit of current. And so that you only needTo drop it at one point in the matrix, we've added these large pads that you can solder to. So we can surface mount solder a cable to the VCC pad. And if desired, we can also loop out from the second pad, and likewise with ground.

So if you have a 3x3 matrix, you can just deliver power to, say, the center panel, and it would fan out from there. I have here printed four scale models of this design. This is just the back silk and back paste layers. So we can take a look at the tiling and how these connections will interact.

Here we've got a two by two tiling where we'll inject power and ground in the top left. So we've flipped it over, so this would be the top left unit. We inject power and ground here, and our data signal comes in in this input. Then when we solder this together, we just decide where the signal path goes by which tabs we solder.

So over on this D out tab, we would solder D out to D in to go to the next unit, but we wouldn't solder these D outs or these D ins here. Then the signal path can come around, D out to D in to come down to unit number three, and then finally D out to D in to wrap to unit number four. So that takes care of the signal path. You just solder the tabs in the direction you want that signal to go, and then connect all the powers and grounds as you see fit.

Now, of course, each matrix forms like a cell in this larger tiling matrix. And so each matrix addressing is basically in rows, which means that you don't get one contiguous row sequentially across the panel. To actually address a specific pixel in the panel then, it just comes down to basically a whole lot of modular arithmetic.

So this design was in last week. We're already waiting for this new prototype to come in.We've actually panelized this a little just so we can place it with the pick and place machine so we can very quickly assemble that prototype and also keep things looking very nice and consistent. Really looking forward to tiling, say, 3x3 of these and seeing what kind of power we have, what kind of heat dissipation we have at full brightness, what full brightness even looks like. I imagine nine times 64 LEDs running full brightness is gonna be pretty intense. We might have to bust the IR camera out and have a look at how things are traveling with the heat dissipation.

In any case, I'm very excited for those to come in and to assemble them.

Now let's talk for a moment about MicroPython. MicroPython is, well, Python is great because it's very close to human English. It's very friendly and easy to understand for beginners. However, Python is an interpreted language and so MicroPython running on devices like the Micro:bit are not compiled. The whole raw text code is stored in Flash on the device and the Python interpreter or the MicroPython interpreter passes that file and executes the commands.

Because it's not a compiled language, that means that the length of your code really has a very linear relationship with how big that file is, which is a big deal on devices like the Micro:bit that have very limited Flash. The length of your variable names, the white space, the comments, all of that contributes to how big the file is in Flash on the device.

We've talked a lot about PiicoDev in the factory and if you're not familiar, PiicoDev is our family of sensors and MicroPython libraries that are unified across different MicroPython devices. What that means is the lowest common denominator for these libraries isThe Micro:bit and that actually starts to get a little bit challenging as you start to drive more devices. Every module that you import takes up more size in Flash, leaving less room for user code.

Take this guy for instance, this is the PiicoDev motion sensor that uses an MPU6050 initial measurement unit and this is the Python module or the PiicoDev unified library that will drive this device. We can see straight away at the top of the file, this is 7.6 kilobytes, which on a Raspberry Pi Pico, no big deal at all. That's totally fine. On a Micro:bit though, from memory, I think you've only got about 20 kilobytes of user programmable Flash. So for all your code, all the modules that you import that aren't already compiled into MicroPython, you've only got 20.

So this one module uses up a significant amount of the memory on your device. And when you take a scroll through, it's not really any surprise why. You know, we have these long descriptive variable names. We've got these long indents. Each of the, an indent in Python is actually four spaces. That's four characters, not just a tab. So every bit of white space here is just chewing up the available memory on the micro bit. We've got a bunch of comments to keep things human readable and you really couldn't do it any other way. You wouldn't want this to be stripped down and very hostile looking just to save Flash. You want your open source projects to be friendly for people to work on, to encourage people to join you in making something cool.

So what do you do? How do you solve a problem like the Flash size on a micro bit? Well, thankfully, a lot of people in the MicroPython community have been working on minifying scripts. Simply a minifying scripts takes a big longWinded script like what we have here and compresses the variable names, especially things like reuse strings or reuse names, get compressed into another variable, like a single letter variable that can be reaccessed again and again.

So basically it takes this very human readable code and I guess like kind of compiles it into what is still Python. It's just more obfuscated, but much denser.

Let's do a before and after. This is the motion sensor module starting off at 7.61 kilobytes. And here is the minified script coming in at 4.35 kilobytes. That is a significant saving.

And this is what it looks like. We can see that a lot of the code gets compressed into single lines. Here we have say a function definition and the whole thing is compressed onto a single line just to save the amount of white space that would be required to define that function. Every line inside a function needs indenting. And so this is just compressing it into a single line. Curiously, the one below it does not do that. So I wonder if there's perhaps a more aggressive script that we can look into using.

You can see at the top of the script here, we just have a few constant definitions, say true being stored in underscore G, the string Z, Y, X, which gets used all the time in this module, each being stored into one of these F, E, and D variables. And you're only saving one character there when you invoke this, but it's the number of times that it's invoked, it's still a net saving.

And so we've seen the case for minifying Python scripts, at least for the micro bit. You know, on a Raspberry Pi Pico, you wouldn't even bother. There's so much flash on the thing that it's totally unnecessary. But here we've saved nearly half the amount of flash just.By running that minify script. And so how do we do this sustainably? You know, PiicoDev is growing with more and more modules and that means that there's gonna be more and more repositories to maintain with these minified options in case people wanna use it on devices with smaller flash.

And that is where we enter GitHub automations. This is what it takes to make that work. In this main.yaml file, we specify triggers and actions. So here the trigger would be, if there is a push to the main branch of a certain file, in this case, the Python module we want to minify, then we run the job to minify it.

And so in that job, we specify the kind of virtual machine we want the script to run on. In this case, it's a Ubuntu machine. We check out the repo on that machine and we even install a few packages. There's already a Python minifier that's available in the Python package manager pip. So when that virtual machine spins up, we install the minifier and then we run the command to minify the input file, which is our module. And then we save the result in the min directory. And then finally we make the commit and push it to the repo.

And this is a huge deal because it means that we can just work on the code that matters and not get bogged down with making sure that the minified file is like it's at the same version as the original file. We just work on the code that matters, which is the original file and let the actions, the GitHub automations take care of the rest.

For the open source project aficionados and GitHub veterans out there, I'm sure this is nothing new, but if you haven't come across this idea before, super powerful and it's just a really nice tool to have in the belt for something like this. And of course I couldn'tLet a factory episode slide by without showing a jig. Here we have the PiicoDev RGB LED module. We've seen bits and pieces of this before, but we haven't yet seen it assembled. So here it is.

We have a PicoT4 that will do the UPDI programming. There's a pogo pin poking the back of the device under test in this jig. So the programming is handled by the PicoT4 and then we just have a test pattern running from the Raspberry Pi Pico.

In any case, that's all I have for you today. If you have any questions or if you'd like to see something a little bit closer, head over to the Core Electronics forums and we'll see you there. Until next time, thanks for watching.