Ceci est une ancienne révision du document !
I’m BAAAAAACCKKKKK Glenn Frey of the Eagles once said “For the record, we never broke up, we just took a 14-year vacation.” I’m certainly not as famous as Glen Frey or the Eagles, but let’s just consider that last 8 months a vacation from Micro This Micro That. However, I’m back at least for this month. Hopefully, life will be generous enough that I can continue to do this series of articles for a number of months again. There has been a lot of movement in the Micropython/MicroController world. A few weeks ago (April 2023) an announcement came out that “MicroPython 1.20 released with Raspberry Pi Pico W support, mip package manager, smaller footprint”. That was the reason for me scraping to make room to write this updated special MTMT. Yes, the Raspberry Pi Pico-W did get its own page in the Micropython.org downloads page. And YES, there are many new things in it.
The last version of Micropython for the Pico-W was 1.19 and it did provide network support on the Pico-W, and it did work pretty well. Micropython 1.20 also is supposed to provide a native Neopixel driver (WS2812) that replaces the need for the older versions. According to the documentation, you should just be able to use from neopixel import NeoPixel for the “normal” Neopixel devices and from apa106 import APA106 for dotstar devices. I tried it and yes, you can use it; however, everything you already have that works with the older drivers WILL NOT WORK with the new one. The new driver is really limited. Here is a quick snippet of how to use the neopixel driver
That’s all you get. Define the R,G,B color and write it to a specific pixel. It doesn’t look like the new driver will support the newer RGBW devices, since there are only three values in the parameter. The bottom line here is don’t expect to use any of your cool LED Strip lighting effects like “fireflys” or “color wave” or “smooth rainbow” using the new integrated driver for MicroPython 1.20 anytime soon. The other major disappointment seems to be in the I2C driver for both the RPi Pico and the RPi Pico-W. There is an issue with the nightly build v1.20.0-50-g786013d46 released on 2023-05-04. A little bit of history is needed here to understand the reason for the frustration that is to come.
Back in January of 2021, when the RPi Pico first came out, the Raspberry Pi group released the Pico Python SDK document which was a great boon to anyone trying to get up to speed in learning MicroPython – especially for the brand new RPi Pico board. In section 3.6, it talks about how programs should talk to devices on the two I2C buses. The examples showed for Bus 0 you should use: i2c = I2C(0, scl=Pin(9), sda=Pin(8), freq=100000) or for Bus #1: i2c = I2C(1, scl=Pin(7), sda=Pin(6), freq=100000) They went on to say that the defaults would be for I2C(0) SDA is on Pin 8 (GPIO) and SCL is on Pin 9 and for I2C(1) SDA is on Pin 6 and SCL is on Pin 7.
There is also a warning that says “There may be some bugs reading/writing to device addresses that do not respond, the hardware seems to lock up in some cases.” So when I started programming for the Pico, I stuck with the defaults of pins 8 and 9 for Bus(0) and that’s what I used in my demo programs that I published here. Well, time passes, as we all know, and new versions of the MicroPython for RPi Pico came out and they all stuck to those standards. That is until MicroPython 1.20. If you try to run a program that was working under MP 1.19 using the default I2C pins (8 and 9 for I2C(0) or 6 and 7 for I2C(1) wouldn’t work and an error message would be thrown saying that shown top right.
If you tried the i2cscan program that we’ve used many times, nothing would show up. Even running the program on an old RPi Pico without the wireless would fail. Yet if you flashed the MicroPython version back to 1.19, everything worked just as you remember. I modified my “regular” i2cscan program to include a print line that includes the configuration information, like this (bottom right). Returning to my original I2C program that used a temperature sensor and an OLED display, it worked just like before. Not knowing how long it might take for the MicroPython group to get things working correctly, here is a small table showing the GPIO and Physical pin assignments for both I2C(0) and I2C(1) (see table below).
Once the MicroPython group gets things straightened out, the following table should provide you with a quick reference for which GPIO and Physical pins you can use for either bus (see table next page, top right). So is it worth upgrading the MicroPython version from 1.19 to 1.20? At first glance, the answer is no. There are enough problems between the I2C issue and the fairly dumbed down NeoPixel driver that I’m really not willing to consider staying at 1.20 for “production and testing”. I will monitor the MicroPython download page (https://micropython.org/download/rp2-pico-w/) for new nightly builds every few days, but I’m not really holding my breath on a great all-supporting release any time soon. I’m going to try to leave on a positive note and say that, as time allows, I’ll be working on more projects using the Pico and Pico-W and will try to provide more articles in the near future. And yes, that DOES include the Compass program.
LATE ADDITION: As I was sitting back with a cold glass of water resting from making over 1.7 litres of (not) refried beans, I realized that even if I have the time to update things next month, it will be the end of June before any of you will see the updates. So, I’m going to try to make sure that I update things on my blog at http://thedesignatedgeek.xyz so you can always get any updates. I hope to have a project for using the new NeoPixel in a realistic way and any updates to the I2C issue I raised in the article above. If you do visit, PLEASE drop me an email and let me know what you think. There is an easy email handler at the bottom of the main page. Until then, as always; stay safe, healthy, positive and creative!