pimoroni-pico VS BME280_SensorAPI

It takes some time to decode, but I can grab- for example- this 259k JPEG: http://placekitten.com/3840/2160

And display it from the microSD card with this code: https://gist.github.com/Gadgetoid/0b8e352e377135d743338c9483...

As more or less demonstrated by this example: https://github.com/pimoroni/pimoroni-pico/blob/main/micropyt...

Decoding is done via Larry Bank's JPEGDEC: https://github.com/bitbank2/JPEGDEC

It uses roughly 20k RAM to provide the necessary buffers both for decoding JPEGs into blocks which are passed to a drawing routine that handles copying the data into the display RAM buffer (on our larger Inky display this is backed by PSRAM). I don't believe there's a hard limit to the size of the JPEGs you can display. The main bottlenecks are decoding time and the relatively limited scaling options: FULL, HALF, QUARTER, EIGHTH.

This aside, the authors solution is actually quite elegant. As long as you have control over the image pipeline there's no real reason to encumber the device with handling large (both in bytes and pixel dimensions) files. You'll also get much better dithering results writing your own routine to convert files from JPG to the raw 4-bits per pixel format for the display. Our built-in dithering is just a plain ordered dither matrix and, while quaint and retro, it leaves much to be desired visually.

If you're trying to use a public API you can also make GitHub actions automate the whole image conversion process and publish the results to GitHub pages. This works great for, for example, the daily XKCD, serving both to reformat the strip for the display, credit the author, extract the "alt" text and avoid excess requests to the origin. Eg: https://pimoroni.github.io/feed2image/xkcd-800x480-daily.jpg. Though the astute will notice I still opted for jpeg in this case.

I've done a lot of programmable LED projects (keyword Neopixel or WS2812) and by far my favorite hardware has been this little raspberry pi pico board that takes care of the power requirements for you, a USB-C cable can supply 3 amps, powering one or two hundred LEDs with ease. There's lot of Arduino boards that let you program a few neopixels, but supplying power for lots of them is usually the annoying part.

https://shop.pimoroni.com/en-us/products/plasma-2040

https://github.com/pimoroni/pimoroni-pico/tree/main/micropyt...

https://shop.pimoroni.com/collections/pico is the pi version of that.

I'm still not sure why the BBC went down the route of making its own platform when adapting the arduino world would have been simpler and more effective. Still its good to see that the BBC is doing computing again.

I have a problem with an I2C connection to a SCD41 sensor (Pimoroni Breakout). The strange thing is: The example provided by Pimoroni works perfectly fine.

But I'm using the https://github.com/pimoroni/pimoroni-pico firmware with the PicoGraphics module. There doesn't seem to much documentation about compiling their version (except the c version?)

I used the Pimoroni Micropython and the clock.py here.

However you'll find that the file you have linked includes breakout_sgp30.hpp which in turn includes drivers/sgp30/sgp30.hpp which you can find here: https://github.com/pimoroni/pimoroni-pico/tree/main/drivers/sgp30

Check out this BME280 libs' header file, especially the *_MSK and *_POS macros. Quite common, huh? Then, have a firmware to implement communication with multiple sensors like that. This is prone to human error, and this is what I want to help fellow developers to avoid.

That's unlikely since we submodule in Bosch Sensortec's own BME280 library from - https://github.com/BoschSensortec/BME280_driver

I actually love bosch. Ad they write really good platform independent drivers for their products. Although I totally agree that sometimes the documentation can be a pain. For the bme driver https://github.com/BoschSensortec/BME280_driver check this out.