Right, it's going to be a quick Factor episode this week because we've got a few deadlines to meet but I did promise you a Python programming video just to catch you up.

We have the Pioneers platform for Raspberry Pi Pico and we have a few PiicoDev modules stacked up on it. In the other end, I've also got a Micro:bit coming in with the adapter, the PiicoDev adapter for micro bit.

So in this video, we're going to get the same driver file, the same Python module to drive this temperature sensor off both of these different pieces of hardware. The Python implementation, the MicroPython implementation is a little different on these devices but it'd just be great for PiicoDev to work with just one file that works for both.

Let's start off by driving the temperature sensor from the micro bit. Plug the Micro:bit in and this is what we're working with. We're in Thonny and I'll open up my main file, my main.py and the tmp package, the tmp module, and we'll just make sure that it works from the start.

So I'll connect to my micro bit. Yeah Micro:Bit, you can see there's no files on the Micro:bit at the moment. I'll just drag that, I'll just upload that library. Really simple script, we just import our package and read the temperature and then print the temperature. I can give it a run.

We can see that we're running on Micro:bit and we have the temperature streaming in. If I put my finger on the sensor as well, that should begin to climb very suddenly. This responds very quickly. Great, we can work on micro bit.

Now to jump over to the Raspberry Pi Pico, I'll plug that chain of devices in and transfer my USB lead to the Pico. Within Thonny, just staying in the same directory, I'll just change the interpreter to Raspberry Pi Pico.Sure, here is the closed-captions transcript formatted into paragraphs:

"away it goes. I'd already uploaded the library to this one, so it's already running the right code, but here you can see me change the temperature. And you know what? In fact, just to show there's no tricky business, I'll upload that to the device again. I forgot that I left that package there. And of course, it's away and running. Importantly, the message has changed now to running on RP2.

All right, the big reveal. How is this working? So when the module is imported, it imports the OS module and then it checks the system name. In this case, it's checking for Micro:bit because it's really the edge case. Other implementations of MicroPython stick to using the machine module, but it's Micro:bit that doesn't really bother. In fact, then all we do is import Micro:bit and that brings in the I2C functionality. Otherwise, let's just assume we're working on Raspberry Pi Pico because I'm just considering those two. Otherwise, we need to do a little bit more. We can't just import micro bit. We have to import from machine the I2C module. Micro:bit already has a module called lowercase I2C. So here, after we import I2C, the I2C module from machine, we then create that I2C object. And for this device, for this expansion board, we're always working with I2C bus number zero. So I just initialize it straight away as I2C zero. Suffice to say, different I2C bus functionality for different pieces of hardware.

Okay, so now we get to the class for the temperature sensor. We're working with a TMP117 temperature sensor. And the way that we initialize it will be different depending on the bus that we use, depending on the I2C module that we're using. So again, we check if we're working on a micro bit. And if so, then we can take in the"I2C bus that's passed in. And that's common between both conditions. We're always bringing in the I2C bus and we're always bringing in the address.

By default, this board has an address of hex 48. This is where the magic happens. Within this object, I create a kind of like a wrapper function. So we have this handle, this handle I2C write in camel cats. And for Micro:Bit, we use the Micro:bit syntax. For the Raspberry Pi Pico, we use the machine module syntax. I really should have done this at the start.

This is all motivated because here in the documentation for machine, you can see if we search for I2C, the I2C class uses the syntax I2C write to. But in the Micro:bit implementation of I2C, the syntax is just I2C write. And that's why at the start of this module, when the object is initialized, it selects between I2C write and I2C write to. It just takes those functions, slaps a label on them, which is this label and this label. And then the package just runs as usual.

But instead of using like the default names like I2C write and I2C write to, it uses these special handles that I've given them, which is the camel cats versions. And so then just like any other package, it's this function that is invoked every time you do something like read the temperature.

Let's step through how that works. The first thing we need to do is use this like this unified function to write to the device address and write the register that temperature and degree C lives in. And that's just address zero. So we use that unified I2C write function to write zero to the device address. And then we just perform a read. We read in from that address, two bytes, and then just do a bunch of conversion to arrive at degree C.

For the few people thatStuck around to see how this is coming together, thank you. And you're probably the right person to ask for advice. Does this implementation make sense to you? Is this a good or a bad way to do something like this? Is this scalable for other implementations of MicroPython?

I think it might be because, I mean, by default, we're just handling edge cases, right? The default case is if we're just using machine. And since we only have to take care of edge cases, it's kind of implicit that there shouldn't be that many edge cases to take care of. So if some other piece of hardware comes out and it's got some subtly different implementation of MicroPython, then we can include another condition here to take care of that edge case.

I realize, I mean, now that I look at it, I can kind of see I'm doing a little bit of duplication here. I really should bring this guy up here. Oh, yeah. Someone's probably screaming at their screen about that. And now we have a little bit less code duplication because we always want to set the I2C bus and the address. Oh, beautiful. Anyway, I'm getting distracted.

If some other piece of hardware comes out, maybe there's, I don't know, if OS username, maybe I'll release a sweet piece of silicon with its own MicroPython implementation. And it's the super cool board. Maybe we need some other set of I2C read and write functions to accommodate just that board. I mean, in the end, it really was only a couple of if conditions, but I haven't seen this done anywhere else. So I don't know. Is it a good new idea or is it a terrible idea? And that's why no one else has done it.

I'm asking you, dear viewer, to come in with maybe some red hot MicroPython programming skills and set me on the right path. I knowLast week, I promised that I would be writing a module from scratch. However, it's becoming a bit unwieldy and would make for a very long factory episode. Perhaps when the laser sensor prototype arrives, we can dive into the data sheet and figure out how to drive it with MicroPython. In any case, I wanted to quickly show you the more or less finished product because we will be needing it very soon. Thank you for watching, and I'll see you in the next factory episode.