Hi, I see the new Tiny FX has been released, it looks very cool. In looking at the examples I see that they’re all ways of making the device flash lights and make sounds, i.e., it operating as a controller on its own. Do you have any plans or could you provide an example on how to hook the Tiny FX up to another processor (say, a Raspberry Pi or another MPU) so that it can be used to express sounds or lighting effects as directed by a different (perhaps more complicated) system?
That would make it very handy indeed. Thanks!
You can use the pins of the Stemma/Qt connector also for UART. So if you don’t want to connect a sensor, that should work. Of course you will have to make sure that no part of the software claims the pins for I2C.
You could also additionally repurpose GP26 and connect an ESP-01S to UART+GP26 (connect with RST-pin of the ESP). This way, you can even use WIFI to control the system. The pico then would control the ESP using standard AT-commands. Or you would write a little web-server for the ESP and let the ESP drive the Pico.
So many, many options :-)
I think for my project I’d require a wired connection rather than a WiFi or networked option, so it’d have to be a UART. The downside of that is that as you know there’s no common UART communications protocol, you always have to DIY, and I’ve never found that to be as reliable as say, an I2C connection. And there’s only a few UARTs even on a Pi 4 or 5, which then requires using those USB-to-UART dongles, which take up a lot of space and create more complexity. But yes, doable.
This is similar to a question I had about the Yukon product line. I would love it if someone came up with an I2C-to-RP2040 bridge solution, then people could plug the Tiny FX or the Yukon controller or any of these RP2040-based products directly into a Raspberry Pi (or MPU) over I2C, without the limitations of UARTs.
Thanks!
To make this more explicit, I understand that for a product to be designed, built and marketed, Pimoroni needs to believe it can be a profitable exercise. I’m advocating for a general purpose I2C-to-RP2040 bridge, a small board that would connect to the I2C bus (with typical solder bridge alterations to alter the address, or perhaps implementing it with the Nuvoton MS51 so its I2C could be programmed), which would attach to an RP2040 product (like the Yukon controller), and be supported with a MicroPython library.
This would open up all of Pimoroni’s RP2040 product line as peripherals to existing systems rather than rely on them being the master controller in an application, which is (to my mind) rather limiting. I for one would be a customer, as I’d like to use the Yukon line on a Raspberry Pi based robot and was disappointed to hear that the only way to connect it by wire was via UART.
To give you an idea of how useful that would be, consider that on that robot I’ve currently got two IO Expanders, a Digital Encoder and two Digital Potentiometers, all using that same MS51 processor. I’m advocating for a similar board to bridge between any I2C-capable processor and an RP2040, avoiding the issues with UARTs. It would be extremely handy.
Thanks in any case for your consideration.
Would it be possible to repurpose GP26 simply as an on-off switch (a Pin input in MicroPython)? Then I could just devote a Raspberry Pi GPIO pin to controlling that.
Yes. It is defined as “sensor-pin”, but that has no effect on the function. And the pinout in the shop also shows that it can be used for all kinds of things (ADC, GP, PWM).
It is a pity that most of the Pimoroni boards are not hackable. The RP2040 has so many GPIOs, it would have been better to add some pads on the back of this board instead of a large logo.
I’m a big fan of Pimoroni products, as well as (generally) how they develop and market them. There’s been no attempt to create proprietary forks like CircuitPython, and their support libraries are generally good. But I do agree that for almost zero cost, it would be almost trivial to add hackability to their playlist. Adding pads in free space on PCBs, providing hooks in hardware and software to promote extension, all would benefit both Pimoroni and hobbyists.
Another example would be the IO Expander. I’m using two of them on my robot, and it’s somewhat an example of a failed opportunity: even a small change to the board would permit its MS51 processor to be reprogrammed. Once could conceive of the IO Expander then being used to create micro-robots, all the hardware and software would almost be there. I note that Adafruit recently released a Qt form factor board with an 8051 on it.
And as with the RP2040-based products like Yukon, it would be great if people using Raspberry Pis could use the Yukon controller as a subprocessor without resorting to UARTs, which are hardly easy to set up for most people and their number extremely limited compared to I2C. I’ve asked about the Yukon before and there doesn’t seem to be any interest in that at all within Pimoroni, despite opening up another avenue for the entire line to be used (hacked).
I don’t mean to make this sound like a complaint. I just think there’s an opportunity here for some kind of I2C bridge product that would permit people to easily connect RP2040s (and now RP2350s) to a Pi. That would be a huge win, and while it’d be beyond me to develop such a product it would be to my understanding almost trivial for Pimoroni’s engineers.
I think there is a misunderstanding: the fork of MicroPython done by Pimoroni is proprietary: it runs only on the MCUs that Pimoroni sells. CircuitPython in contrast runs on 400+ boards and on many different architectures. Only a fraction of them are from Adafruit.
In addition, Pimoroni provides drivers only baked into their MP port. If you want to use their hardware with some other devices and non-proprietary MicroPython, you have to rely on third party drivers. Compare this with Adafruit: they write drivers that work on any board (as long as it runs CircuitPython). They even created a shim-library that lets you use Adafruit breakouts with their drivers directly on MicroPython.
I realise this topic has been discussed ad nauseum on various forums. This is probably not the place to re-litigate those arguments, but since you bring it up I will respond: There is no misunderstanding, just an informed disagreement. Regardless of the number of boards it may run on, “CircuitPython” is branded, proprietary IP owned by Adafruit, just as Windows runs on thousands of different computers and only a fraction of them are by Microsoft. I don’t find that a compelling point.
My robot OS is written in CPython and MicroPython. I have no desire to add a third language, so I find that I’ve stopped buying Adafruit products that require CircuitPython or installation of their company-branded omni-libraries. Sometimes I find an Adafruit product I might like to purchase and if it only has a CircuitPython support library I don’t buy it, which is rather irritating. CircuitPython might even be hurting Adafruit’s sales for people like me who are using MicroPython.
Everything I’ve purchased from Pimoroni so far has had a MicroPython support library. I’ve purchased hundreds of Pimoroni products over the years and if there is a proprietary fork of MicroPython by Pimoroni I’ve not run into it. I’ve been successfully using builds of MicroPython I download from micropython.org.
I happen to believe that had Adafruit contributed to the MicroPython project rather than creating CircuitPython we’d all have been better off with a single language. If an “entry level” Python was needed it could have been done as a profile within the MicroPython project. And yes, I have heard their rationale before. They’re a private company and they clearly can and will do whatever they like. They chose not to do that and forked the language. I just happen to think that was a bad choice.
Over the past day or so I’ve been trying to write a CPython I2C Master and MicroPython Slave, the latter running on an RP2040. I just had my first success: the slave no longer took down the Raspberry Pi’s I2C bus, the device showed up at 0x44 as planned, and I was able to have the slave acknowledge the master’s message, though I’ve still got a long way to go to both understand and work out the communications between them. So progress! Once I’ve got this worked out I’ll transfer it over to the Tiny FX, which I’ve just ordered online.