Libraries and examples to support Pimoroni Pico add-ons in C++ and MicroPython.

Pimoroni Pico Libraries and Examples

Welcome to the brave new world of Pico! This repository contains the C/C++ and MicroPython libraries for our range of Raspberry Pi Pico addons.

First of all you need to decide if your project is going to be done in MicroPython or using C/C++ with the Pico SDK. We have instructions for both here:

Software support for our Pico range

It's very early days for Pico and we've been working our little socks off to get everything ready for launch.

Most of our Pico addons have support for both C/C++ and MicroPython but we're still catching up a little bit in places.

The table below shows the current state of compatibly and some notes to set expectations:

Product C/C++ Library MicroPython Library Notes
Pico Explorer Base Yes Yes
Pico RGB Keypad Yes Yes
Pico Unicorn Pack Yes Yes MicroPython support added in v0.0.3 Alpha
Pico Audio Pack Yes No Limited support for MicroPython planned
Pico Scroll Pack Yes Yes
Pico Display Pack Yes Yes

We will keep this information updated as things develop.

Note: It's very early days for Raspberry Pi Pico and it's likely that our libraries will undergo quite a lot of changes over the next couple of weeks as we take in feedback and expand the functionality.

Pimoroni Ltd
We are a company of Makers and educators based in Sheffield, UK.
Pimoroni Ltd
  • ST7789 / PicoGraphics rewrite - Support for 4-bit, 8-bit and 16-bit framebuffers and more.

    ST7789 / PicoGraphics rewrite - Support for 4-bit, 8-bit and 16-bit framebuffers and more.

    :information_source: Latest test builds - (now with MicroPython v1.19, PIO accelerated ST7789 parallel output, performance tweaks, Tufty2040 build, updated 17 Jun, 11:00 GMT)

    A 340x240 16-bit framebuffer uses a whopping 150k of RAM. This is relatively okay in C++ but causes issues in MicroPython where the gc_heap is only 192k.

    This set of changes allow you to use a native 16-bit, smaller 8-bit, or tiny 4-bit framebuffer for most of our SPI displays. This lets you balance memory usage with available colours and display performance.

    This change renames the st7789 module to picographics in MicroPython.


    Here's an example bringup for the 160x80 ST7735 LCD in true-colour RGB565 mode:

    from picographics import PicoGraphics, DISPLAY_LCD_160X80, PEN_RGB565
    display = PicoGraphics(display=DISPLAY_LCD_160X80, pen_type=PEN_RGB565)

    The above uses 25K of RAM and supports 65K colours.

    from picographics import PicoGraphics, DISPLAY_LCD_160X80, PEN_P4
    display = PicoGraphics(display=DISPLAY_LCD_160X80, pen_type=PEN_P4)

    The above uses 6.25K of RAM and supports 8 colours!

    Custom Pins

    You can use your own pins for supported SPI or Parallel displays.

    You must construct an SPIBus or ParallelBus object using the pimoroni_bus module:

    from pimoroni_bus import SPIBus
    from picographics import PicoGraphics, DISPLAY_PICO_EXPLORER, PEN_RGB332
    spibus = SPIBus(cs=17, dc=16, sck=18, mosi=19)
    display = PicoGraphics(display=DISPLAY_PICO_EXPLORER, bus=spibus, pen_type=PEN_RGB332)

    Saving More RAM / Doing Weird Things

    If you need to temporarily claim back RAM from PicoDisplay, or use multiple framebuffers, you can use set_framebuffer to set/clear the region of memory it uses internally.

    :warning: DO NOT attempt to draw when no framebuffer is set. You'll have a bad time!

    from picographics import PicoGraphics, get_buffer_size, DISPLAY_LCD_160X80, PEN_P4
    # Big enough for 160 * 80 at 4-bits per pixel
    buf = bytearray(get_buffer_size(DISPLAY_LCD_160X80, PEN_P4))
    display = PicoGraphics(display=DISPLAY_LCD_160X80, pen_type=PEN_P4,  buffer=buf)
    # Detach the framebuffer from PicoGraphics
    # Set a different framebuffer
    buf2 = bytearray(int(160 * 80 / 2))

    Displaying JPEG files

    Thanks to JPEGDEC - - you can load and display JPEG files via PicoGraphics, like so:

    import picographics
    import jpegdec
    lcd = picographics.PicoGraphics(display=picographics.DISPLAY_PICO_EXPLORER, rotate=0, pen_type=picographics.PEN_RGB565)
    # Create a new JPEG decoder for our PicoGraphics
    j = jpegdec.JPEG(lcd)
    # Open the JPEG file
    # Decode the JPEG
    j.decode(0, 0, 0)
    # Display the result

    The arguments to "decode" are x-offset, y-offset and scale. Value scale values are:


    When you call decode the jpeg decoder makes a best effort to draw into your PicoGraphics surface in a sensible pixel format.


    Pico Graphics has very basic support for 128x128 spritesheets in PEN_RGB332 mode:

    from picographics import PicoGraphics, DISPLAY_TUFTY_2040, PEN_RGB332
    import time
    lcd = PicoGraphics(DISPLAY_TUFTY_2040, pen_type=PEN_RGB332)
    # Reserve a large enough buffer
    sprites = bytearray(128 * 128)
    # Load a spritesheet into the buffer
    open("s4m_ur4i-dingbads.rgb332", "rb").readinto(sprites)
    #open("s4m_ur4i-pirate-characters.rgb332", "rb").readinto(sprites)
    # Tell PicoGraphics to use this new spritesheet
    # Draw a sprite
    lcd.sprite(0, 0, 10, 10, 255)

    The function sprite takes:

    • the X/Y index of a sprite in the spritesheet. These should be between 0-15.
    • the X/Y coordinates to draw the sprite on screen.
    • the colour to treat as transparent

    Supported Displays

    The current list of supported displays is:

    • DISPLAY_LCD_160X80
    • DISPLAY_LCD_240X240
    • DISPLAY_TUFTY_2040

    Supported Pen Types

    • PEN_P4 - 4-bit packed, with an 8 colour palette. This is commonly used for 7/8-colour e-ink displays or driving large displays with few colours.
    • PEN_P8 - 8-bit, with a 256 colour palette. Great balance of memory usage versus available colours. You can replace palette entries on the fly.
    • PEN_RGB332 - 8-bit, with a fixed 256 colour RGB332 palette. Great for quickly porting an RGB565 app to use less RAM. Limits your colour choices, but is easier to grok.
    • PEN_RGB565 - 16-bit, 65K "True Colour." Great for rainbows, gradients and images but comes at the cost of RAM!


    • [ ] Add some new documentation here!
    • [x] Handle a failure to allocate a palette colour (return -1 if we've run out of palette space?)
    • [x] Provide MicroPython bindings for palette put/get methods
    • [x] Provide a way to initialize a specific display type's args automatically, eg: ST7789(display=SPI_LCD_240X240)
    • [x] Update all examples to remove set_pen(r, g, b) since this is meaningless and deprecated
    • [ ] Write a migration guide
    • [ ] Update documentation
    • [x] Remove obsolete functions from Pico Display & Pico Explorer classes- should be header-only defines of pins
    • [ ] Create a C++ "Buzzer" driver to mirror the MicroPython one and replace "pico_explorer.set_tone()"


    • [x] Pico Display 2.0 - All rotations
    • [x] Pico Display - All rotations
    • [x] SPI LCD 240 x 240 - All rotations
    • [x] Pico Explorer - All rotations
  • Graphic glitch introduced by v0.0.7

    Graphic glitch introduced by v0.0.7

    I think either by this commit or this commit some graphic glitch has been introduced regarding the pico display since moving from release v0.0.6 to v0.0.7. The glitch is visible in this video. It works flawlessly when using v.0.0.6. Any ideas as to why?

  • Set pixels as image, add show_bitmap_1d(), show_text()

    Set pixels as image, add show_bitmap_1d(), show_text()


    I don't know how you folks feel about PR's - if this is not your game, I will not be offended if I see a close with no comments.

    Proposed API extensions

    Show images

    Show images using a set_pixels method:

    image = bytearray(0 for j in range(width * height))

    seems convenient for cases where you want to redraw the image from one "frame" to the next, means all of the pixel value copying is done in C not Python/

    Scroll bitmaps

    Scroll bitmaps (one dimensional, e.g. text) using a show_bitmap_1d method:

    bitmap = bytearray(j for j in range 127)
    for offset in range(-17, 127):
        picoscroll.show_bitmap_1d(bitmap, 16, offset)

    Detailed illustration in this gist

    Motivation for second one: pico scroll did not offer a simple method to actually scroll text across the display, and I feel that this is pretty fundamental so decided to offer one. I wondered about adding the code to render the text to a bitmap to the API but decided on balance to keep things simple, as fonts are something people hold strong opinions about.

    End product:

    Will welcome any feedback here, I tried to stick to the "house style"

  • Pico w with picounicorn

    Pico w with picounicorn

    Is there an issue with the pico W micropython firmware? Trying to run a pico unicorn with a new pico w and can't import picounicorn. It works on older firmware but I need network support.

  • Badger2040 Micropython battery improvements

    Badger2040 Micropython battery improvements

    There's been some chat in the Discord about how the Badger2040 eats through the battery when it's not doing anything. I had a look into the Micropython side of things and saw that Badger doesn't halt when running these apps (and it's running at 125MHz), which means it's using 20mA or so instead of almost nothing.

    This is my attempt to start resolving this problem. In summary I have:

    • Exposed versions of halt and pressed to wake to python
    • Set the enable 3v3 pin as early as possible after boot
    • Added functionality in to launch a saved app on wake, by checking a file appstate.txt
    • Modified the badge and image examples to use this mechanism to halt the badger after each screen update. The other apps still all work as they did before (for the moment).

    Exposing halt and pressed to wake

    I've not directly exposed the Badger2040 methods for these, instead implementing them independently in the Micropython module. For halt, this allows Thonny to interrupt even when the Badger is "halted" but connected to USB so the power doesn't go off.

    For pressed to wake, the motivation is to capture the button press as soon as possible. Waiting for python to come up and the Badger2040 instance to be created is way too slow, you have to hold down the button for ages for it to register. Instead, I have a static singleton class and grab the button state in its constructor. This does catch most reasonable length button presses, but it still sometimes misses short ones. This could probably be improved by moving this function into preinit, so that the state was captured even earlier during boot - I might look into that later.

    For pressed to wake, I've exposed the button state as a global function on the badger2040 module, as well as on the Badger2040 object. This allows launcher to quickly check the state without having to instantiate a Badger object it would then immediately destroy.

    Enable 3v3 earlier

    Like capturing the button presses, waiting until the Badger object is instantiated before setting the 3v3 enable line makes it hard to wake the Badger up when it's on battery. Instead, I now set the 3v3 enable pin high in the singleton constructor discussed above.

    Launcher changes - appstate.txt

    In order to give the experience of seamlessly using an app while the badger is actually rebooting between each button press, launcher needs to immediately drop into the app again instead of displaying the menu. I've acheived this by writing a short text file appstate.txt, which contains the name of the app on the first line, and any app specific state can be stored on subsequent lines.

    If this file is present and the first line is a valid app name, then launcher loads that app straight away, unless buttons A and C are pressed. This is my suggestion of a new convention whereby pressing buttons A and C together cause the app to exit, instead of having to use the reset button. Using the reset button doesn't work because on battery pressing only the reset button doesn't wake the Badger.

    There is maybe a question of whether we could wear out the flash with frequent writes - possibly it would be best to at least not to rewrite the file if state hadn't changed. Another possibility might be to reserve some flash in the image and provide API methods to read/write this data instead of using the file system, then the location of that block could be changed on each firmware update at least.

    Note that not all apps have to use this mechanism - more interactive apps or apps that you aren't likely to leave running probably shouldn't use it, though potentially they should time out and halt after a few minutes.

    On my way past I've also added a machine.freq(48000000) to the top of launcher, which ~halves power usage and I haven't seen a noticeable difference in performance. I considered putting a call to reduce the clock into the singleton constructor, but I thought it was useful to users to make clear how the clock was being configured, and running the boot at 125MHz isn't going to do any singificant harm.

    Badge and image examples

    I've changed these in the obvious way - the image example shows how additional state can be stored in the appstate file.

    I haven't changed any more examples yet, but if you'd like to accept these changes then I'm happy to do so.

    With these changes, I can just about run these apps off a single new coin cell, providing I give it a bit of time to rest rather than mashing buttons continuously. One coin cell is unlikely to be able to provide sufficient current past the very early stages of its life though.

  • Pico Display Pack V2 x 2?

    Pico Display Pack V2 x 2?

    I have a need to run two Pico Display Packs side by side, portrait mode if possible. I get that this is a very unusual request, and that its not designed to be used this way. They will be mounted to proto boards so each one can use a different chip select and backlight pin. I'll just mirror what pins are used on the Pico Breakout Garden SPI slots. And ignore the button and LED connections. The stock Pimoroni Micro Python Display Pack driver / module doesn't support alternate pin select so I can't use it. The BreakoutColourLCD240x240 Micro python module does, and does work with the Display Pack, with one exception. It limits me too 240 x 240 pixels. It's already in portraited mode because of the different screen orientation of the display pack but I can't draw to the lower 1/4 of the screen. Even if I specify a height=320 and adjust the display buffer to match.
    I currently have a 1.5' 240x240 LCD Breakout and Display Pack v2 running side by side, so running two displays is possible. What I need is **BreakoutColorLCD240x320 module. I don't have the skills to write my own of know where to even begin to modify the current 240x240 module. I may be asking too much, but I figure it can't hurt to at least ask. @Gadgetoid

    from breakout_colourlcd240x240 import BreakoutColourLCD240x240
    #import picodisplay2 as display2
    display_buffer = bytearray(320 * 240 * 2)  # 2-bytes per pixel (RGB565)
    display1 = BreakoutColourLCD240x240(display_buffer, cs=(22), bl=(21))
    display2 = BreakoutColourLCD240x240(display_buffer, cs=(17), bl=(20))
  • Unable to use VL53L5CX break with Pico or PicoW (via Inventor 2040 W)

    Unable to use VL53L5CX break with Pico or PicoW (via Inventor 2040 W)

    I haven't been able to get a VL53L5CX breakout to work with either a Pico W or Pico using both 1.19.2 or 1.19.1 releases.

    I'm using the MicroPython examples taken from in both cases.

    On the Inventor 2040 W running the example results in the board hanging, I then need to power cycle the board for it to work. on this board I have tried both via a soldered breakout slot and via the QW/ST connectors, both with the same result.

    On a regular Pico 2040 running the example returns the following:

    Starting up sensor...
    Traceback (most recent call last):
      File "<stdin>", line 18, in <module>
    RuntimeError: VL53L5CX: init error

    In both cases I have ensured that the firmware blob is named correctly and is in the root /.

  • Using two optical flow sensors simultaneously

    Using two optical flow sensors simultaneously

    I am really excited that the optical flow sensors (PMW3901 & PAA5100) are now supported on the Pico. I was wondering if it is possible to use two sensors simultaneously? The "normal" PMW3901 library lets you set arguments including slots and ports, which opens the option of having 2 sensors recording simultaneously which I've used before, but it's not clear from the Pico example how to achieve this. I'm not a wiz' in .cpp, but it seems that it might be possible from the source code, but I'm not sure how. Any ideas?

  • ST7789: Create generic display driver

    ST7789: Create generic display driver

    This change introduces an "ST7789" class to C++ and MicroPython. It allows the user to supply supply a width, height and rotation instead of the current ugliness of supplying a properly sized bytearray(). It would also combine all of the (ST7789-based) display product libraries into a single library so we don't have duplicated functionality all over the place (getting progressively worse with every new display product :grimacing:)


    1. [x] Bind ST7789 library + PicoGraphics to MicroPython
    2. [x] Add support for various display orientations to ST7789
    3. [x] Migrate PicoDisplay, and PicoDisplay 2" and all other ST7789-based devices to the generic ST7789
    4. [ ] ~~Add shim modules (written in Python and baked into the firmware) to fake the old PicoDisplay and PicoDisplay2 module functionality~~
    5. [x] Update the examples
    6. [x] Remove Pico Display modules
    7. [ ] Communicate The Old Way as deprecated (update documentation?)

    Phase 1 tests:

    Test builds -

    1. [x] Pico Display
    2. [x] Pico Display 2.0
    3. [x] Pico Explorer


    This would change:

    import picodisplay as display
    width = display.get_width()
    height = display.get_height()
    display_buffer = bytearray(width * height * 2)

    Into something a little more like:

    import st7789
    WIDTH = 320
    HEIGHT = 240
    display = st7789.ST7789(WIDTH, HEIGHT, rotate180=False, slot=BG_SPI_FRONT)

    It might involve breaking changes to the C++ API/SDK.

  • driver-sh1170 for Raspberry Pico (1.12

    driver-sh1170 for Raspberry Pico (1.12" OLED I2C Breakout)

    Needed a display to attach to a Tiny 2040, so I ported one for the OLED 1.12" monochrome I2C Breakout. As before, I found an Arduino driver and modified it to the new breakouts-dev standards and converted from C to C++. I only have the I2C version of the breakout, so I couldn't check the SPI code. As far as I remember, the Python version of the Pi library (luma) has an image display function, but that wasn't in the original code I used. I'm going to have to dig around for that! There is a warning in the demo code about converting a string constant to a char *. I also cast an int to an "enum" type - not sure how to use the enum directly (for black/white colours). I have created this PR against the breakouts-dev branch - I hope that's right! Thanks for setting up all of the breakout templates - made life a lot easier.

  • Can't get Pimoroni i2c breakouts to work with Micro Python Machine i2c?

    Can't get Pimoroni i2c breakouts to work with Micro Python Machine i2c?

    I have a Pimoroni VEML6076 UV sensor breakout that I want to use in Micro Python on a Pi Pico. It's discontinued so there is no Pimoroni Micro Python library. I have found one that does work in Micro Python using machine i2c.

    import machine
    sda=machine.Pin(4) # Explorer 20 Breakout 4
    scl=machine.Pin(5) # Explorer 21 Breakout 5
    i2c=machine.I2C(0,sda=sda, scl=scl, freq=400000)
    import veml6075
    import time
    uv = veml6075.VEML6075(i2c)
    connected = uv.initUV()
    while True:
        UVI, UVIA, UVIB = uv.readUV()
        print (UVI)
        print (UVIA)
        print (UVIB)

    The library file is as follows

    import time
    import ubinascii
    class VEML6075:
    	# Device information
    	VEML6075_ADDR  = 0x10
    	VEML6075_DEVID = 0x26
    	REG_CONF        = 0x00  # Configuration register (options below)
    	REG_UVA         = 0x07  # UVA register
    	REG_UVD	        = 0x08  # Dark current register (NOT DUMMY)
    	REG_UVB         = 0x09  # UVB register
    	REG_UVCOMP1     = 0x0A  # Visible compensation register
    	REG_UVCOMP2     = 0x0B  # IR compensation register
    	REG_DEVID       = 0x0C  # Device ID register
    	CONF_IT_50MS    = 0x00  # Integration time = 50ms (default)
    	CONF_IT_100MS   = 0x10  # Integration time = 100ms
    	CONF_IT_200MS   = 0x20  # Integration time = 200ms
    	CONF_IT_400MS   = 0x30  # Integration time = 400ms
    	CONF_IT_800MS   = 0x40  # Integration time = 800ms
    	CONF_IT_MASK    = 0x8F  # Mask off other config bits
    	CONF_HD_NORM    = 0x00  # Normal dynamic seetting (default)
    	CONF_HD_HIGH    = 0x08  # High dynamic seetting
    	CONF_TRIG       = 0x04  # Trigger measurement, clears by itself
    	CONF_AF_OFF     = 0x00  # Active force mode disabled (default)
    	CONF_AF_ON      = 0x02  # Active force mode enabled (?)
    	CONF_SD_OFF     = 0x00  # Power up
    	CONF_SD_ON      = 0x01  # Power down
    	# To calculate the UV Index, a bunch of empirical/magical coefficients need to
    	# be applied to UVA and UVB readings to get a proper composite index value.
    	UVA_A_COEF = 2.22 
    	UVA_B_COEF = 1.33 
    	UVB_C_COEF = 2.95 
    	UVB_D_COEF = 1.74 
    	# Once the above offsets and crunching is done, there's a last weighting
    	# function to convert the ADC counts into the UV index values. This handles
    	# both the conversion into irradiance (W/m^2) and the skin erythema weighting
    	# by wavelength--UVB is way more dangerous than UVA, due to shorter
    	# wavelengths and thus more energy per photon. These values convert the compensated values 
    	UVA_RESPONSIVITY = 0.0011
    	UVB_RESPONSIVITY = 0.00125
    	def __init__(self, i2c=None):
    		self.i2c = i2c
    		self.address = self.VEML6075_ADDR
    	# initialize device
    	def initUV(self):
    			deviceID = bytearray(2)
    			self.i2c.readfrom_mem_into(self.address, self.REG_DEVID, deviceID)
    			if (deviceID[0] != self.VEML6075_DEVID):
    				return False
    				# Write Dynamic and Integration Time Settings to Sensor
    				conf_data = bytearray(2)
    				conf_data[0] = self.CONF_IT_100MS| \
    						  self.CONF_HD_NORM| \
    				conf_data[1] = 0
    				self.i2c.writeto_mem(self.address, self.REG_CONF, conf_data)  
    				return True
    			return False
    	# Read UV data from device, return UV index
    	def readUV(self):
    		uv_data = bytearray(2)
    		self.i2c.readfrom_mem_into(self.address,self.REG_UVA, uv_data)
    		uva = int.from_bytes(uv_data, 'little')
    		self.i2c.readfrom_mem_into(self.address,self.REG_UVD, uv_data)
    		uvd = int.from_bytes(uv_data, 'little')
    		self.i2c.readfrom_mem_into(self.address,self.REG_UVB, uv_data)
    		uvb = int.from_bytes(uv_data, 'little')
    		self.i2c.readfrom_mem_into(self.address,self.REG_UVCOMP1, uv_data)
    		uvcomp1 = int.from_bytes(uv_data, 'little')
    		self.i2c.readfrom_mem_into(self.address,self.REG_UVCOMP2, uv_data)
    		uvcomp2 = int.from_bytes(uv_data, 'little')
    		uvacomp = (uva-uvd) - (self.UVA_A_COEF * (uvcomp1-uvd)) - (self.UVA_B_COEF * (uvcomp2-uvd))
    		uvbcomp = (uvb-uvd) - (self.UVB_C_COEF * (uvcomp1-uvd)) - (self.UVB_D_COEF * (uvcomp2-uvd))
    # Do not allow negative readings which can occur in no UV light environments e.g. indoors
    		if uvacomp < 0:  
    			uvacomp = 0
    		if uvbcomp < 0:
    			uvbcomp = 0
    		uvai = uvacomp * self.UVA_RESPONSIVITY
    		uvbi = uvbcomp * self.UVB_RESPONSIVITY
    		uvi = (uvai + uvbi) / 2
    		return (uvi, uvai, uvbi)

    The pickle I'm in is the above won't work if I try to use the Pimoroni i2c. If I substitute in the following: from pimoroni_i2c import PimoroniI2C PINS_BREAKOUT_GARDEN = {"sda": 4, "scl": 5} PINS_PICO_EXPLORER = {"sda": 20, "scl": 21} i2c = PimoroniI2C(**PINS_BREAKOUT_GARDEN) I get AttributeError: 'pimoroni_i2c' object has no attribute 'readfrom_mem_into'

    And if I try to use any of the Pimoroni i2c breakouts with machine i2c

    from breakout_bme280 import BreakoutBME280 bme = BreakoutBME280(i2c) I get ValueError: BreakoutBME280: Bad i2C object?

    Any help with this would be greatly appreciated.

  • Graph plotted up-side-down ?

    Graph plotted up-side-down ?

    As angle increases from -360 degrees and 0 degrees sine(angle) should rise. Here it goes negative.

    Line 29 : y = int((sin(radians(angle + offset)) * 24) + 32)

    should possibly be: y = int(32 - (sin(radians(angle + offset)) * 24) ) ??

  • lightsleep does not save power on pimoroni  pico uf2for 1.19.8 1.19.9 or 1.19.10 but does on picow

    lightsleep does not save power on pimoroni pico uf2for 1.19.8 1.19.9 or 1.19.10 but does on picow

    hi, 19/11/22

    About 4 weeks since 1.19.9. pico uf2 1.19.10 appears to say its built against micropython 1.19 as against picow uf2 still appears built against 1.19.1. Put it on the pico, ran the same test and lightsleep still doesn't seem to reduce power consumption on the pico. Obviously don't know what else may not work. Previously reported via support as below but now I have a bit of time to put it on github.

    via pimoroni support 20/10/22

    Very rushed for time at present but noted 1.19.9 of the uf2 was out yesterday. Over 2 weeks since 1.19.8. It still appears to say its built against micropython 1.19 as against picow uf2 still saying built against 1.19.1. Impressive list of commits on github, but put it on the pico, ran the same test and (perhaps not surprisingly) lightsleep still doesn't seem to reduce power consumption on the pico. Obviously don't know what else may not work. Cant see a bug raised for this, forgive me for not doing it myself.


        If I use the current Raspberry pi uf2 it seems to be based on micropython 1.19.1 as does the picow uf2 1.19.8
        rp2-pico-20221006-unstable-v1.19.1-528-gb8982ec5f.uf2 (this is a much clearer way to version it I think).
        The Pimoroni uf2 appears to be based on 1.19.0 (which is not mentioned as a release on the MicroPython site)
        but it is referred to by pimoroni as 1.19.8
        pimoroni-pico-v1.19.8-micropython.uf2 also built on the 6th of october.
        The reason I have looked into this is power consumption in lightsleep. 
        Both uf2s support this without complaining when I do:
        On the Raspberry Pi uf2 or Pimoroni picow uf2 power consumption falls to 1.5 mA drain on the usb, and goes back to
        around 20mA after the sleep ends. 
        However with the Pimoroni pico uf2 it stays around 20mA all the time  The time delay provided by the sleep period seems to
        be correct in both cases.
        with pico uf2 this is on the same pico, just with different uf2s. The picow uf2 was tried on a picow.
        The reason I used the Pimoroni uf2 was because I have a Pico Display Pack 2.0 and the Raspberry Pi uf2 does not support it.
        Test program-
        import time
        import machine
        while True:
  • for Pico Graphics doesn't mention ascii tables for Pico Graphics doesn't mention ascii tables

    The documentation explaining how to print individual characters to the screen doesn't mention that you use the numerical ascii references to choose what to print. It may be obvious to a lot of people but as a beginner with python and hardware it wasn't clear to me at all. I found the deprecated repo by googling the function itself and that's where I came across the info.

    I suggest adding a line explaining that users will need to look up an ascii table to figure out which character to print.

  • Motor2040 encoders intermittently return infinite speed readings in micropython

    Motor2040 encoders intermittently return infinite speed readings in micropython

    In micropython, calling the capture() method on an Encoder can sometimes return an infinite speed in the radians_per_second field. This is obviously a little inconvenient when using it to drive the input of a PID controller. Most readings are sensible, but after normally around 30s of use I get one that comes back as infinity.

    I'd suggest it would be better to either return None and document that this might happen, or return the previous valid value. As it is I've done the latter in my code, but it took a long time to track down!

  • - utc_offset errors - utc_offset errors

    pressing Vol up/down increments the utc_offset by more than one each press. As a result this allows utc_offset values to greater than 24 which then shows times greater than 23:59:59

  • Rounding of brightness values on Galactic Unicorn micropython class

    Rounding of brightness values on Galactic Unicorn micropython class

    Playing with the micropython examples for Galactic unicorn I noticed that brightness values show rounding errors.

    print(f"Brightness set to {gu.get_brightness()}")

    returns: Brightness set to 0.5019608

Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:

sol2 sol2 is a C++ library binding to Lua. It currently supports all Lua versions 5.1+ (LuaJIT 2.0+ and MoonJIT included). sol2 aims to be easy to use

Nov 25, 2022
Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript.

Structy Structy is an irresponsibly dumb and simple struct serialization/deserialization library for C, Python, and vanilla JavaScript. You can think

Sep 13, 2022
A tool for generating cross-language type declarations and interface bindings.

Djinni Djinni is a tool for generating cross-language type declarations and interface bindings. It's designed to connect C++ with either Java or Objec

Nov 19, 2022
Duktape - embeddable Javascript engine with a focus on portability and compact footprint

Duktape ⚠️ Master branch is undergoing incompatible changes for Duktape 3.x. To track Duktape 2.x, follow the v2-maintenance branch. Introduction Dukt

Nov 16, 2022
The missing bridge between Java and native C++

JavaCPP Commercial support: Introduction JavaCPP provides efficient access to native C++ inside Java, not unlike the way some C/C++ compilers interact

Nov 26, 2022
Seamless operability between C++11 and Python
Seamless operability between C++11 and Python

pybind11 — Seamless operability between C++11 and Python Setuptools example • Scikit-build example • CMake example Warning Combining older versions of

Nov 25, 2022
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

SWIG (Simplified Wrapper and Interface Generator) Version: 4.1.0 (in progress) Tagline: SWIG is a compiler that integrates C and C++ with languages

Nov 25, 2022
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Nov 14, 2022
Digital rain animation gif with glow squeezed into a raspberry pi pico and pimoroni pico-display
Digital rain animation gif with glow squeezed into a raspberry pi pico and pimoroni pico-display

pico-display-matrix Digital rain animation gif with glow squeezed into a raspberry pi pico and pimoroni pico-display or how to actually use all Flash

Sep 10, 2022
Tetris on a Raspberry Pi Pico mounted on a Pimoroni Pico Explorer

PicoTetris Classic Tetris game running on a Raspberry Pi Pico microcontroller. Pico C port by Richard Birkby Original JavaScript implementation - Jake

Sep 3, 2022
Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack
Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack

breakout_rpi_pico Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack Prebuilt binary (breakout.uf2) is here. To build your own binary

Oct 15, 2022
I am planning to add a beginner friendly path for my Juniors to Learn DSA and I will try to provide solutions of every problem also. We can add codeChef Challenge solutions also

DSA-Path-And-Important-Questions I am planning to add a beginner friendly path for my Juniors to Learn DSA Are you a Newbie in programming and want to

Oct 31, 2022
About Add any Program in any language you like or add a hello world Program ❣️ if you like give us ⭐

Hello-World About Add any Program in any language you like or add a hello world Program ❣️ if you like give us ⭐ Give this Project a Star ⭐ If you lik

Oct 28, 2022
Video game library manager with support for wide range of 3rd party libraries and game emulation support, providing one unified interface for your games.
Video game library manager with support for wide range of 3rd party libraries and game emulation support, providing one unified interface for your games.

An open source video game library manager and launcher with support for 3rd party libraries like Steam, GOG, Origin, and Uplay. Includes game emulation support, providing one unified interface for your games.

Nov 21, 2022
I add my Pi Pico (RP2040) stuff here.

Pico Stuff I add my Pi Pico (RP2040) stuff here. There are complete apps and libraries for sensors or complicated tasks. Libraries BMP180: Header-only

Nov 18, 2022
MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems
MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems

The MicroPython project This is the MicroPython project, which aims to put an implementation of Python 3.x on microcontrollers and small embedded syst

Nov 24, 2022
MicroPython for M5Camera and OpenMV.
MicroPython for M5Camera and OpenMV.

M5Camera_OpenMV このリポジトリは、M5Camera+OpenMVのMicroPython環境です。 以下リポジトリのソースコードをベースとして環境を構築しています。 This repository is a MicroPython for M5Camera and OpenMV. I

Jul 22, 2022
Raspberry Pi Pico SDK Examples

Raspberry Pi Pico SDK Examples Getting started See Getting Started with the Raspberry Pi Pico and the README in the pico-sdk for information on gettin

Nov 19, 2022
USB to interfaces implementing MicroPython "machine" module functionalities on a computer.
USB to interfaces implementing MicroPython

u2if project u2if(USB to interfaces) is an attempt to implement some of the MicroPython "machine" module functionalities on a computer. The goal is to

Nov 14, 2022