Welcome back to another episode of The Factory. This week, we have some drooly assembly footage from the SMT assembly line. We will also be discussing the future of PiicoDev, and as always, we have another prototype show and tell. Let's get started.

Another week, another prototype. This week, I have for you the PiicoDev touch sensor prototype. On the front, you can see three touch pads labelled one, two, and three. There's also an indicator LED. Keep in mind that this is just a prototype, so we have soldered a five millimetre LED there. However, in the final version, we plan to use a rear mounting surface mount LED. This way, when we place all the parts on the back, the LED can still shine through a hole in the board at the front.

Now, let's take a look at the back of the touch sensor prototype. It has the familiar PiicoDev connections. We have used the CAP1203 three-channel capacitive touch sensor for this prototype. It is the regular breakout, but we have also added some crocodile clip connections on one side. This allows you to connect the touch sensor to anything you want to turn into a capacitive touch sensor. Additionally, there is a 0.1 inch or 2.54 millimetre breakout for the same connections. So, there are quite a few options available.

It's worth mentioning that this touch sensor prototype is the first electronic PiicoDev module that spans two units of a PiicoDev array. As you can see, the other modules are the standard 25.4 millimetre size, but this one fits over two modules.

Now, let's take it for a spin. If I touch pad one, you can see on the plot that the blue line for S1 jumps up. The same goes for S2 and S3. You may also notice the interrupt light flashing on the front.

In other news, this week we set up our first production run of the PiicoDev motion sensor. Just to catch you up, this motion sensor is a 6-axis IMU with a 3-axis accelerometer and gyro. It is based on the MPU6050 which is a bit of a darling in the maker community. It's been around a while, it's pretty capable and it's pretty affordable.

The nice thing with developing a family of modules like this is that there's a lot of parts reuse. You know the connectors, the decoupling capacitors, I2C pull-up resistors, LED etc they all get reused. Per board usually you know you just only have to set up the unique sensor itself and maybe the oddball supporting component.

In the case of the motion sensor I had to set up and align the motion sensor IC and just the charge pump capacitor. Turns out that the micro electromechanical machine that's inside this device needs a significantly higher voltage than the standard 3.3 volt supply and so it does that boosting internally.

So I got those components loaded, aligned, did a dry placement to make sure that everything went down okay and then began the assembly. And with the assembly underway I got started writing a test script.

So to test this device there's actually a self-test the device can execute where it stimulates each of the axes and then you perform a check to see if that falls within factory tolerance. And as a belt and braces approach I also included a check to make sure that the device is experiencing 1g for a consecutive number of samples because you know in a static test the device should experience 1g or 9.8 meters per second squared roughly and of course that should be regardless of the orientation of the device.

So those devices are assembled and tested the guides are underway just need to make some labels, bag them and you should expect to see them on Core Electronics very soon.

Let's talk for a moment about some future projects for PiicoDev. There's only so far that purpose-builtI2C devices, such as touch sensors or temperature sensors, can be integrated into PiicoDev. But what about non-I2C native devices like GlowBits? How can we bring them into the PiicoDev system? For example, if you want to interact with electromechanical buttons or drive a buzzer using PiicoDev as an output device, how can you achieve that?

Since PiicoDev is an I2C bus system, we need to build our own microcontroller-based PiicoDev modules. Instead of having a temperature sensor on a PiicoDev module, we would have a microcontroller acting as an I2C responder device connected to a buzzer. This way, you can control the microcontroller as if it were a purpose-built I2C device. The microcontroller can present registers and control interfaces, allowing you to pass commands to it. For example, you could pass the tone and duration of a certain pitch for the buzzer to play. The microcontroller interprets these commands on the bus and drives the device accordingly.

By creating our own I2C devices and using a microcontroller's firmware as a bridge between non-I2C enabled sensors or output devices, we can expand the functionality of PiicoDev. We can incorporate buttons, buzzers, bar graph displays, and more. Although for bar graph displays, you might consider using an I/O expander instead. The possibilities are vast.

I have already done some preliminary work on this. I used an ATtiny development platform and the wiring library to create a basic I2C responder device. This device can be addressed, and if the right data is written to the right register, it produces the desired behavior.Little hello world example. I'm writing to some device. I'm writing to the register led1 and writing three bytes as if I'm going to write say some red green blue data to drive an onboard Glowbit, a WS2812 addressable LED or you know a string of them.

In any case, it's a matter of selecting the right part for the job and I think a requirement for the project is that it ought to use something that exists as an Arduino core. Why? Because everything works with Arduino. There's already libraries for just about everything and they're almost all open source and licensable to use. So definitely needs to be something with an Arduino core.

Needs to have a fair bit of flash to accommodate holding user libraries. You know the wiring library is several kilobytes. That's the Arduino library that handles I2C communications. That's a few kilobytes. You throw in then a device library to drive say a Glowbit and there's you know easily another kilobyte there.

Needs to have a fair few pins just to give us room to breathe, you know. If you want to control several LEDs, if you want to have like a address you know solder jumpers to set many different addresses, it helps to have a few GPIO accessible for that.

And it needs to be small, you know. It needs to be in the QFN kind of scale so maybe like a 20 pin QFN package would be appropriate.

And it's more than likely that with those conditions met, you know, of course it needs things like it needs an I2C bus for one. You don't want to be bit banging I2C in firmware if you can help it and of course SPI because you may want to interface to an SPI device, you know, to act as a SPI I2C bridge between those two buses. Of course UART. Of course an analog to digital converter. Absolutely.So we're looking for a capable little chip and of course it has to be pretty cheap. So I'm going to spend some time in the parametric search and we'll see what we can find. In any case that'll be a bit of a longer term project but expect to hear about some movements in that area very soon.

What kind of devices would you want to include in the PiicoDev ecosystem now that if we open up the possibilities to expanding to non-I2C sensors, buttons etc. I think buttons are a pretty good place to start. It's you know the PiicoDev ecosystem as it stands doesn't have a great deal of opportunity for like direct user input. So a button would be great. I think a buzzer would be great. The first output device. A rotary encoder. Oh a rotary encoder. Absolutely. Gotta have a potentiometer in there. I wonder if that gives the audience the idea. Probably true. We just sit around going what can we make.