I have been having difficulty with the Inky Frame 5.7 and an SCD41. Scenarios:
SCD41 (Adafruit breakout) + BME688 (Pimoroni breakout), either daisy-chained or on separate Qw/ST ports of the Inky Frame
SCD41 alone on Qw/ST
It seems that the SCD41 works in scenario #1 until/unless I try to load other libraries, such as the Picographics module used to display stuff on the Inky Frame screen. I was successfully able to get sensor data from both environment sensors on a continuous basis when I tried to do that.
However, once I tried to integrate that with Picographics and putting stuff on the screen, I ran into lots of memory errors and/or the SCD41 seems to become unresponsive after 1-2 readings. Removing the BME688 (scenario #2) can sometimes help a little bit in terms of getting the first reading from the SCD41, but ultimately, the Pico goes unresponsive after the second reading.
I had the SCD41 alone working well with a “while” loop on a Tufty 2040.
Both the Inky Frame and the Tufty 2040 were used connected via USB (for setup, programming, and troubleshooting) and also with their included AA/AAA battery packs from the accessory kit. The Inky Frame goes unresponsive even when connected via USB to my MacBook Pro (with or without AC power).
Any thoughts on how I can get the device to keep working, and then run on battery? I’m wondering if there’s a voltage/power problem with the SCD41, as that seems to match up with some other experiences I’ve found.
The Inky Frame is using the Pimoroni Inky Frame MicroPython 1.25. I’m developing/running in Visual Studio Code with MicroPico.
MicroPython v1.25.0, on 2025-05-12; Raspberry Pi Pico W with RP2040
Posting your micro python code might help?
Use the </> “preformated text” option and it will retain the formating, indents etc.
Do you get any error messages when it stops?
I don’t own an inky, but I do display sensor readings with Pico Graphics on my Tufty, and other Pimoroni SPI displays.
Can you post your code and the memory errors you have? You should be aware of the limited amount of RAM of the Pico and the large screen size of the InkyFrame. I am afraid the Tufty is not a good comparison because the driver works different, but that has to be verified.
You could also instrument your code with some calls that print free memory at different stages.
I’ll double-check but I’m pretty sure I’m already using i2c = pimoroni_i2c.PimoroniI2C(sda_pin, scl_pin).
The limited amount of memory has definitely been difficult to work around. I’ve written much more Python than MicroPython and the MP memory management does not come naturally to me. :)
I don’t currently have the code posted anywhere. I’m going to see if I can get a more minimal reproduction case and post that.
I adjusted the example from the issue for pins 4 and 5, which appears to be correct for the Inky Frame 5.7 with Pico W. (Without that, the example in the issue failed to run.)
I’ve been running that code on my Inky Frame 5.7 and it keeps printing out results every 5 seconds.
It is not so much the memory management, as just the amount you have. The Pico-W has 256K, but some is used by the firmware. Another problem is that many objects need contiguous memory, so not only the amount of free memory is important, but also if it is fragmented or not.
That is why I am advocating an InkyFrame with sockets. This would allow an easy upgrade to other microcontrollers. The Pico2-W e.g. has twice the memory, and the Pico2-Plus variants from Pimoroni even more.