Welcome back to the factory! This week, I have some exciting updates for you. We have a new PiicoDev prototype, a new piece of hardware, and a new platform for PicoDev. We've also made some design for manufacture upgrades in our KiCad workflow. Additionally, we have some very exciting news about Raspberry Pi and PicoDev. Let's dive in!

First up, we have a new part. This week, we are prototyping the PiicoDev pressure sensor. This sensor uses the MS5637 and is specifically designed to measure barometric pressure. It's similar to our atmospheric sensor, but it focuses solely on barometric pressure. You can also infer altitude from the readings. We have tested it with the PiicoDev libraries and now we just need to panelise it, send it off, and create some guides.

We have also expanded the PiicoDev platform to include support for Micro:Bit. Now, you can have a Micro:Bit project on your workbench and easily connect it to your sensors and prototyping circuit. Everything stays connected and stable, even if you put it away and take it out later. The Micro:Bit platform looks quite similar to the Pico platform. To make it compatible with Micro:Bit, we removed the Pico expansion footprint and added a PiicoDev adapter footprint on the left side of the board. The adapter is held in place by two standoffs, and despite initial concerns about stability, we found that the Micro:Bit can be engaged and disengaged without any issues.

Previously, when starting a new PiicoDev hardware project, I would copy an old project and delete the unnecessary hardware. Then, I would add the schematic symbols for the new parts and redesign the board layout while keeping as much of the existing design as possible. However, we have recently made some upgrades to our KiCad workflow to streamline this process.

That's all for this week's updates. Stay tuned for more exciting news and developments in the world of PiicoDev and Raspberry Pi. If you have any questions or need further assistance, feel free to reach out. Happy making!I can, you know, the design decisions around the placement of the holes, the logos, the headers, they can all stay, but it's just really that main part in the middle, and any supporting components that need rework.

To make things a little more scalable, and to prevent things like drifting in spec, you know, if you copy one project and then copy it again and copy it again, you've got this kind of, this chain of decisions that might have been made along the way, and now one project has drifted in intent from another.

So we've made up a PiicoDev KiCad template, and the template just basically captures all those decisions that were already made, you know, the size of the board, the radius of the corners, the placement of the mounting holes, the logos, the headers, the orientation, the placement of the connectors, all of those decisions are just pre-baked into the template, and we can keep that in our own little private repo so that we can make well-considered changes to that if necessary, and then update it, and we won't have that drift that I was talking about before.

And I'm super happy to announce that a bit of a long-term project is drawing to a close. The PiicoDev Unified Library now works with Raspberry Pi, and that's just awesome. What that means is the same sensor with the same example code and the same like.py driver modules all work on either Raspberry Pi Pico, Micro:Bit, and Raspberry Pi single board computers. That's not even MicroPython, that's actual Python.

Now I realize up until this point, the Unified Library, I, you know, I was probably leaking like little bits and pieces here and there, but it was probably a pretty opaque topic. So I've put together this nice little diagram just to help out the PicoDev.Unified Library for Python and MicroPython.

When you connect your dev board to a sensor, all you want to do in your Python code is to call something like sensor.read. You know, this could be like temperature sensor.getDegreesC. And that's the simple experience that you want to have in your user code. You want reading that temperature to be really easy.

What that will call is in the device module, the device module basically handles that device. It handles the temperature sensor. So it will read the data and do any conversions of that raw data. In this case, in my example, I've got something like the read method and setting data equal to read register. Maybe you want to read data out of a specific register and that's meaningful for temperature. And then you want to return, you know, you want to do some math with that data. In this case, I'm just returning data times 100. Maybe that's the scaling that you need to do.

So the device module basically extracts, basically abstracts, accessing the right registers and doing the right conversions. However, there's nothing there that actually says how to drive those I2C pins. You know, how to actually package the commands that you want to send and send them over the bus. And that's what the unified library is for. It handles the hardware part of the equation. You know, I2C hardware is different on, say, a Raspberry Pi Single-Board Computer than it is on a Pico. And so that's where the unified library comes in. It's the part of the equation that basically says when read register is called, it's the part that says if Linux do this and if MicroPython do that.

So what does that actually mean? What do you need to do to make that work? Well, it seems like the wayTo solve the problem, the idea was to make everything, regardless of the development board being used, look like MicroPython. This meant that for the Raspberry Pi, a memory read function was needed because the laser distance sensor appeared as a 16-bit address device, which is uncommon for I2C devices. However, this functionality was necessary and had to be implemented on the Raspberry Pi. The issue was that the SM bus, which is the I2C on the Raspberry Pi, did not have native support for this operation.

After some research and exploration of other open source projects, a.py file from Pimeroni was discovered, which provided a nice abstraction for I2C read and write operations. These functions allowed for the reading and writing of arbitrary length blocks of data, which was exactly what the laser distance sensor required for its configuration. These functions were initially prototyped in the device module to directly drive the bus, and they worked successfully.

With the working calls in place, the next step was to insert them into the appropriate location in the MicroPython read from mem placeholder. This involved putting the read from mem function back into the device module as it was before. In the Unified library, a branching mechanism was implemented to differentiate between Linux and MicroPython devices. Depending on the platform, either the built-in read from mem function or the I2C read function from Pimeroni would be used. This integration of the functions was the final piece of the puzzle for the devices currently being worked on.

In conclusion, it is with great pleasure that we announce the successful implementation of the temperature sensor.The light sensor, the laser distance sensor, they're all working on Raspberry Pi, Micro:bit and Raspberry Pi Pico. By extension, they ought to also work on just other vanilla, normal implementations of MicroPython, say PyCon boards, etc.

And along the way, while all that work was happening, the PiicoDev Unified GitHub repo collected its first pull request from a user called Random Smith. So good on you, Randy. Thank you if you're watching this episode of The Factory.

So this pull request is all about the Unified library's extensibility for using pins that are not the default pins used for a particular development platform.

And last week, I mentioned that we did a design update for the motion sensor, the PiicoDev motion sensor board for the NPU6050. You can see here the design revision with the IC the right way up this time and some legends to show what direction is what.

And finally, what do you think of this style of content? Do you like to see more of the hardware stuff, more of the design and design choices in the electronics side of things? Do you like seeing the work and the decision making that goes into the code base side of things? Let me know your thoughts.

Of course, if there's something you want to see a little closer or if there's something you wish we would cover, just open a thread on the Core Electronics forums.

Until next time, thanks for watching.