Adopt Blinka version 7.2.1 or later to fix I2C pin availability for Pico Explorer Base

[barnabear]

trafficstars

Using the uf2 build containing Blinka 6.20.1 to program the Pico Explorer base which uses I2C on pins GP21/GP20 I get an error caused by the following issue ..

https://github.com/adafruit/Adafruit_Blinka/issues/575

The pull request is at https://github.com/adafruit/Adafruit_Blinka/pull/576

The fix is in Blinka release 7.2.1 https://github.com/adafruit/Adafruit_Blinka/releases/tag/7.2.1

Please could the Blinka version used here be updated at least to 7.2.1 to adopt this fix.

[Gadgetoid]

Ooh good catch I was waiting for this to end up in a release, apparently time flies.

Pending in a PR- test build available here: https://github.com/pimoroni/pimoroni-pico/actions/runs/2281363972

[barnabear]

Ooo ... great. Thank you so much. I hope to pick this up sometime this weekend and try it out.

[barnabear]

Unfortunately this doesn't work because I think you either need all or none of Blinka embedded in the .uf2. It looks like you can't have part and put the rest in /lib. I think you can remove the hardware specific bits that aren't RP2040, but you still need the generic bits.

Traceback (most recent call last):
  File "<stdin>", line 12, in <module>
  File "board.py", line 37, in <module>
  File "adafruit_blinka/board/raspberrypi/pico.py", line 6, in <module>
  File "adafruit_blinka/microcontroller/rp2040/pin.py", line 6, in <module>
ImportError: no module named 'adafruit_blinka.microcontroller.generic_micropython'

My main code is adopted from an adafruit example https://github.com/adafruit/Adafruit_CircuitPython_HT16K33/blob/main/examples/ht16k33_segments_simpletest.py

... with line 19 changed to ...

i2c = busio.I2C(board.GP21, board.GP20)

I'm driving an Adafruit 0.56" 4-Digit 7-Segment Display w/I2C Backpack from the I2C on the feature headers (not breakout garden).

[Gadgetoid]

I've tried adding the "generic_micropython" dir to the modules. Right now the code that handles this is awful, but it should copy over just enough of a - stripped down - Blinka install to work:

https://github.com/pimoroni/pimoroni-pico/blob/323d805585b0af179f27ce7f20bb4e2865ea9c55/.github/workflows/micropython-with-blinka.yml#L63-L78

Binary should crop up here when it finishes building: https://github.com/pimoroni/pimoroni-pico/actions/runs/2287449920

[barnabear]

Yes I tested this and it works in Thonny. However copying the code into main.py and replugging the pico meant that Windows was no longer able to see the USB as a valid device so the COM port was unavailable to I lost control of the device.

Also I think the code itself doesn't run successfully either. Looks a bit like the whole thing just collapses in a heap. Such is engineering.

One step forward, two steps back.

Thanks

[Gadgetoid]

I can't see why it would collapse, but it's fair to say that the Blinka/PlatformDetect compatibility layer is a little bit of a gamble so I am not surprised. Let me know if you get anywhere with it- I'm a little tied up to try it myself.

[Gadgetoid]

I have a suspicion that we've just blown the maximum binary size by baking these files into the firmware- so the first thing MicroPython does on launch (or if any files are written to the filesystem) is overwrite itself. Some pretty critical parts of the system are at the tail end of the firmware, so this basically renders it unbootable.

Honestly I think we'll have to drop our Blinka build in favour of directing users to installing it themselves. There is no easy way around this problem, since the Pico only has 2MB flash and MicroPython is configured to use a specific allocation for firmware/user data. On the Pico it looks like about 1.4MB is allocated to file storage.

We can tweak this allocation by adding some hacks in our build process, but that relocates the filesystem so that the firmware will trash the files on any 2MB Pico that's updated. :grimacing:

[barnabear]

Thanks for that. I wonder if this would be possible for the Pimoroni Pico Lipo boards that have 4MB or 16MB flash? That would be really nice to have.

[Gadgetoid]

Closing, since I don't think this is something we can support with auto builds here.

My dir2uf2 project might make it possible to build a filesystem-only uf2 for deploying Blinka though. So I'm tracking this here in case I have a sudden epiphany: https://github.com/Gadgetoid/dir2uf2/issues/6