PiicoDev confusion

Im wanting to create a few projects using some rgb LEDs and a few other modules that use the qwiic/Stema QT/ piicoDev connection these all use the i2c bus to comunicare but the PiicoDev examples seem to all use a wrapper to basically hide all the I2C Code to attempt to make it easier for first time makers but makeing it more complex to use with other i2c modules also the micropython libraries at least that I have tried (oled & 3x RGB LED MODULE) Examples seem to interfere with non piicoDev libraries using I2c also I’m unsure why there are no Arduino Libraries as all Microcontrolers run Arduino and only a handful of microcontroler chips can run Large Python based code at full speeds without code size limitations being an issue. I doubt that there is no Library for Arduino or a library that can be used in MicroPython using standard i2c functions I will be trying a standard i2c oled library to use the PiicoDev Oled module but As the 3x RGB LED I2c module into doesn’t seem to be a common product made in many places that I can just try other libraries it would likely only be found by searching for the chip that takes the i2c Data and converts it to the data that is read by the RGB LEDs. So having the name of the chip in the downloadable technical specifications would be a least you can do for users who want to use the modules after they hit limitations of MicroPython or the user might want to use the Module with a Board running Circuit Python or any number of languages. That may have libaries for the chips in the Module that will work. If Core Electronics can make a library for Arduino that would be Awesome but to include more info in documantion would be greatly appreciated. If anyone knows of libraries within for Arduino or Micropython that use I2C (not the wrapper) at the project level would be great. :slight_smile: thanks to anyone who can help :slight_smile: Kiera


Hey @Kiera192358 welcome to the forums. You raise some good points!
You are exactly right about the PiicoDev libraries - they are primarily intended to abstract interfacing with hardware so beginners can focus on their project, and experienced makers can get on with playing with cool hardware.

I’ll address each of your points:

Just about every device in the PiicoDev lineup will be compatible with an existing Arduino library. It is, after all the same functional hardware. There should be no trouble connecting many PiicoDev modules to an Arduino-compatible board, installing appropriate libraries and running your own Arduino code. Exceptions would be our so-called ‘smart modules’ like the 3x RGB LED module, for which no equivalent will exist. These cover edge-cases where we want to bring cool, non-I2C hardware onto an I2C bus. For Arduino, you’d just use an existing WS2812B library with regular WS2812B/GlowBit LEDs.

Some additional context:
Python (and by extension, MicroPython) is the fastest growing language in the world! We’re a small team of makers and have to pick our punches carefully when developing new hardware and software. We decided to back Python, and make our projects open source (hint, hint :wink: ). Some PiicoDev modules have already been ported to other more esoteric languages and we’re thrilled with the community response.

This is an unintended, but inevitable side-effect of the PiicoDev Unified library, which initialises the I2C bus every time a new device is added. The payoff is that (in general) a PiicoDev project is portable between all compatible dev-boards. There is perhaps scope to upgrade PiicoDev so the user may pass an I2C object at initialisation. This top-down approach is more common in the wild. We went in the opposite direction, again for beginners to avoid additional technical burden.

The project is fully open-source. You can see the device used in the schematic (linked in the product page). The firmware that runs the ATtiny is also available, if you wish to treat the RGB Module like a generic I2C device and create your own driver code.

It seems like we ought to include the low-level register mapping on the README.md - even though this is present in the source code, perhaps that would make for a more friendly porting experience.

Thanks for your thoughts - I hope this clears up a few uncertainties. What do you think?