pimoroni-pico

pimoroni-pico copied to clipboard

Trying out v1.19.0? Found a bug? Need some help migrating your code? Ask away here.

Think some of the micropython examples for PicoDisplay need updating (renaming the st7789 import to picodisplay). Happy to help with this.

Hi, I have just tested v1.19.0 on a 16Mb Pimoroni Lipo Pico with a pico display 2 and the rotate function does not work.

I have tried the text, line , box and circle functions and they work well. I don't like the pen color assignment process but what can you do.

Also, there is a spelling error in the text explaining how rotations works. The word rotate is missing a "t"

I look forward to the buttons working and some code to help out with that.

I like v1.19.0 because the earlier PROD release had problems using the Stemma QT connector and I2C

For the buttons and LED you do this.

from pimoroni import Button
from pimoroni import RGBLED

button_a = Button(12)
button_b = Button(13)
button_x = Button(14)
button_y = Button(15)

led = RGBLED(6, 7, 8)
This should work for the buttons. I haven't tested it myself just yet. 
[https://github.com/pimoroni/pimoroni-pico/blob/main/micropython/examples/pico_display/buttons.py](url)
I have got the LED working.
I can post the code for that if you want?

Rotate is working OK for me on my Display Pack V2.

display = PicoGraphics(display=DISPLAY_PICO_DISPLAY_2, rotate=270, bus=spibus, pen_type=PEN_RGB332)
display2 = PicoGraphics(display=DISPLAY_PICO_DISPLAY_2, rotate= 270, bus=spibus2, pen_type=PEN_RGB332)

Also working OK on my Display Pack. display = PicoGraphics(display=DISPLAY_PICO_DISPLAY, rotate=270 ,pen_type=PEN_RGB332)

Hi,

The rotate worked - many thanks - but it does not like the bus=spibus declaration - not sure why. I used "from picographics import *" Am I doing something wrong?

Also I would like to see some code with the LED and buttons working. Thanks again !!!

I should have cleaned up what I posted. You don't need the bus=spibus stuff for a single display setup. You can likely leave out the pen_type code too. display = PicoGraphics(display=DISPLAY_PICO_DISPLAY_2, rotate=270)

I just went back to the page with the examples and realised that the code there is wrong.

The example states ... display = PicoGraphics(display=PICO_DISPLAY, roation=90)

besides the spelling mistake it uses "rotation" instead of "rotate"

If someone can fix it it will save some frustration...

Thank you !!!

What I left out that was needed for a dual SPI display setup is

import pimoroni_bus from pimoroni_bus import SPIBus import picographics from picographics import PicoGraphics, DISPLAY_PICO_DISPLAY_2, PEN_RGB332

spibus = SPIBus(cs=17, dc=16, sck=18, mosi=19, bl=20) spibus2 = SPIBus(cs=22, dc=16, sck=18, mosi=19, bl=21 )

display = PicoGraphics(display=DISPLAY_PICO_DISPLAY_2, rotate=270, bus=spibus, pen_type=PEN_RGB332) display2 = PicoGraphics(display=DISPLAY_PICO_DISPLAY_2, rotate= 270, bus=spibus2, pen_type=PEN_RGB332)

There is a contact Pimoroni support link on the shop page. Thats the quickest way to get it fixed. https://shop.pimoroni.com/pages/contact-us

I wasn't using the examples, which is why it didn't catch me out. I was editing my old working code for the new Pico Graphics. I was also doing some testing for the new release on the way.

In 1.19 I'm having to select the port manually. "try to detect port automatically" doesn't seem to work? This is with a stock Pico, Pico Lipo and Tiny. Latest Thonny running on a Windows 10 PC. Once I set the port Thonny reports the board that's connected Ok.

ulab does not seem to be included in pimoroni-pico-v1.19.0-micropython.uf2. Was that forgotton or not meant to be included in this firmware version? Thanks!

ulab does not seem to be included in pimoroni-pico-v1.19.0-micropython.uf2. Was that forgotton or not meant to be included in this firmware version? Thanks!

ulab had to be removed, since we were butting up against the 640Kb firmware size limit for the 2MB Pico. That can- in theory- be adjusted, but not without trashing users' filesystems. It's still available in 4MB, 8MB and 16MB builds all of which allocate 1MB to firmware.

It may return in an alternate build.

ulab had to be removed, since we were butting up against the 640Kb firmware size limit for the 2MB Pico. That can- in theory- be adjusted, but not without trashing users' filesystems. It's still available in 4MB, 8MB and 16MB builds all of which allocate 1MB to firmware.

It may return in an alternate build.

I see. Still, I think ulab is interesting for the servo2040 board, where one may want to run complicated movement calculations

I see. Still, I think ulab is interesting for the servo2040 board, where one may want to run complicated movement calculations

@teuler agreed- there's currently no custom build for Servo 2040 so when I get some time I'll rig one up with ulab included and more flash allocated to MicroPython itself. The same probably applies to Motor 2040. Just need some very loud "back up your files" warnings to go with those.

Running two SPI display's doesn't seem to work in C++.

ST7789 st7789_2( SCREEN_WIDTH, SCREEN_HEIGHT, ROTATE_0, false, get_spi_pins(BG_SPI_BACK)); ST7789 st7789_1( SCREEN_WIDTH, SCREEN_HEIGHT, ROTATE_0, false, get_spi_pins(BG_SPI_FRONT));

Individually no issue in either front or back, but when you have two which ever is created second appears to work, but the first doesn't work.

is there support for the pico scroll? just uploaded the latest version and the module does not seem to be included..

is there support for the pico scroll? just uploaded the latest version and the module does not seem to be included..

It has been temporarily removed, needs some updates to work with W. It currently renders W MicroPython unbootable.

Are there any other people having issues with the Pimoroni brand Micropython using a MacMini with M1 SoC. I have the latest stable Thonny installed on macOS 12.4.

Using the official Raspberry Pi Micropython, there are no issues. The Pico W shows up as /dev/tty.usbmodem101. When I flashed the Pimoroni brand Micropython, either version 1.19.1 or 1.19.2, the Pico W doesn't show up anymore as serial device and is not accessible from Thonny. In the kernel log (dmesg) I found the following error message:

[  843.308332]: 000843.308327 usb-drd0-port-hs@00100000: AppleUSBHostPort::createDevice: failed to create device (0xe00002bc)
[  844.437193]: 000844.437191 IOUSBHostDevice@00100000: IOUSBHostDevice::start_block_invoke: device descriptor fragment is invalid
[  844.438101]: 000844.438100 IOUSBHostFamily::validateEndpointMaxPacketSize: USB 2.0 5.[5-8].3: endpoint 0x00 invalid wMaxPacketSize 0x0000
[  844.438271]: 000844.438269 usb-drd0-port-hs@00100000: AppleUSBHostPort::enumerateDeviceComplete_block_invoke: enumeration failed
[  844.438289]: 000844.438288 usb-drd0-port-hs@00100000: AppleUSBHostPort::terminateDevice: destroying 0x0000/0000/0000 (IOUSBHostDevice): enumeration failure
[  844.438335]: 000844.438334 IOUSBHostDevice@00100000: IOUSBHostDevice::start_block_invoke: device will not be registered for matching
[  844.714525]: arm64e_plugin_host: running binary "sudo" in keys-off mode due to entitlement: com.apple.private.security.clear-library-validatio

On a Windows 10 laptop at work, using the same USB cable, I encounter no problem at all.

@SebasZH do you see these same issues with the official Pico Wireless build, without our baked in libraries?

You can grab it here - https://micropython.org/download/rp2-pico-w/rp2-pico-w-latest.uf2

Are there any other people having issues with the Pimoroni brand Micropython using a MacMini with M1 SoC. I have the latest stable Thonny installed on macOS 12.4.

Using the official Raspberry Pi Micropython, there are no issues. The Pico W shows up as /dev/tty.usbmodem101. When I flashed the Pimoroni brand Micropython, either version 1.19.1 or 1.19.2, the Pico W doesn't show up anymore as serial device and is not accessible from Thonny. In the kernel log (dmesg) I found the following error message:

[  843.308332]: 000843.308327 usb-drd0-port-hs@00100000: AppleUSBHostPort::createDevice: failed to create device (0xe00002bc)
[  844.437193]: 000844.437191 IOUSBHostDevice@00100000: IOUSBHostDevice::start_block_invoke: device descriptor fragment is invalid
[  844.438101]: 000844.438100 IOUSBHostFamily::validateEndpointMaxPacketSize: USB 2.0 5.[5-8].3: endpoint 0x00 invalid wMaxPacketSize 0x0000
[  844.438271]: 000844.438269 usb-drd0-port-hs@00100000: AppleUSBHostPort::enumerateDeviceComplete_block_invoke: enumeration failed
[  844.438289]: 000844.438288 usb-drd0-port-hs@00100000: AppleUSBHostPort::terminateDevice: destroying 0x0000/0000/0000 (IOUSBHostDevice): enumeration failure
[  844.438335]: 000844.438334 IOUSBHostDevice@00100000: IOUSBHostDevice::start_block_invoke: device will not be registered for matching
[  844.714525]: arm64e_plugin_host: running binary "sudo" in keys-off mode due to entitlement: com.apple.private.security.clear-library-validatio

On a Windows 10 laptop at work, using the same USB cable, I encounter no problem at all.

I am having exactly the same issue on my Macbook Air M1

https://micropython.org/download/rp2-pico-w/rp2-pico-w-latest.uf2

Hi Phil, After flashing rp2-pico-w-20220712-unstable-v1.19.1-127-g74794d42b.uf2, at first, I got the same error as with the Pimoroni branded Micropython. After some attempts to unplug en reconnect the PicoW, I got only once the expected two serial devices listed: /dev/cu.usbmodem101 and /dev/tty.usbmodem101. Dmesg shows the following information on successful connection:

[336369.236620]: 336369.236607 usb-drd0-port-hs@00100000: AppleUSBHostPort::terminateDevice: destroying 0x2e8a/0005/0100 (Board in FS mode): connect change interrupt
[336373.837770]: 336373.837765 usb-drd0-port-hs@00100000: AppleUSBHostPort::enumerateDeviceComplete_block_invoke: enumerated 0x2e8a/0005/0100 (Board in FS mode) at 12 Mbps
[336373.886917]: DK: AppleUserECMData-0x1000047f4::start(IOUSBHostInterface-0x1000047f1) fail

Weirdly enough, the Inventor2040W preloaded with the RGB LED demo was recognised every time I connected it to my Mac. After installing rp2-pico-w-20220712-unstable-v1.19.1-127-g74794d42b.uf2 on the inventor2040w, it is still recognised every time I plug it in (but the demo didn't work of course). Could there be something in the main.py preventing it from being recognised correctly on the Mac? I changed the main.py into print("hello world") using a Windows 10 laptop and the Pimoroni branded Micropython now works again on the Mac.

The following webserver demo code was in the main.py file causing trouble on Mac (device descriptor fragment is invalid), but not on Windows 10:

Edit: After again installing the file below as main.py, on Windows 10 the program starts and the onboard LED flashes twice every 5 seconds. After plugging it in on Mac, the onboard LED doesn't even flash so it seems that the rp2040 crashed (?) somehow and it is not executing main.py.

# https://gist.github.com/aallan/3d45a062f26bc425b22a17ec9c81e3b6

import network
import socket
import time

from machine import Pin
import uasyncio as asyncio

led = Pin(15, Pin.OUT)
onboard = Pin("LED", Pin.OUT, value=0)

ssid = 'replace'
password = 'replace'

html = """<!DOCTYPE html>
<html>
    <head> <title>Pico W</title> </head>
    <body> <h1>Pico W</h1>
        <p>%s</p>
    </body>
</html>
"""

wlan = network.WLAN(network.STA_IF)

def connect_to_network():
    wlan.active(True)
    wlan.config(pm = 0xa11140)  # Disable power-save mode
    wlan.connect(ssid, password)

    max_wait = 10
    while max_wait > 0:
        if wlan.status() < 0 or wlan.status() >= 3:
            break
        max_wait -= 1
        print('waiting for connection...')
        time.sleep(1)

    if wlan.status() != 3:
        raise RuntimeError('network connection failed')
    else:
        print('connected')
        status = wlan.ifconfig()
        print('ip = ' + status[0])

async def serve_client(reader, writer):
    print("Client connected")
    request_line = await reader.readline()
    print("Request:", request_line)
    # We are not interested in HTTP request headers, skip them
    while await reader.readline() != b"\r\n":
        pass

    request = str(request_line)
    led_on = request.find('/light/on')
    led_off = request.find('/light/off')
    print( 'led on = ' + str(led_on))
    print( 'led off = ' + str(led_off))

    stateis = ""
    if led_on == 6:
        print("led on")
        led.value(1)
        stateis = "LED is ON"
    
    if led_off == 6:
        print("led off")
        led.value(0)
        stateis = "LED is OFF"
        
    response = html % stateis
    writer.write('HTTP/1.0 200 OK\r\nContent-type: text/html\r\n\r\n')
    writer.write(response)

    await writer.drain()
    await writer.wait_closed()
    print("Client disconnected")

async def main():
    print('Connecting to Network...')
    connect_to_network()

    print('Setting up webserver...')
    asyncio.create_task(asyncio.start_server(serve_client, "0.0.0.0", 80))
    while True:
        print("heartbeat")
        
        onboard.on()
        await asyncio.sleep(0.1)
        onboard.off()
        await asyncio.sleep(0.2)
        onboard.on()
        await asyncio.sleep(0.1)
        onboard.off()
        await asyncio.sleep(5)
        
try:
    asyncio.run(main())
finally:
    asyncio.new_event_loop()

I can recreate this issue (M1 Macbook Air) with a very simple script:

import time
from machine import Pin

onboard = Pin("LED", Pin.OUT, value=0)

for i in range(0, 40000):
  onboard.on()
  time.sleep(0.025)
  onboard.off()
  time.sleep(0.025)

If that is saved as main.py then when the Pico starts up it will run for perhaps 20-30 iterations of the loop and then lock up hard every single time. This occurs both with the official MicroPython build (currently rp2-pico-w-20220712-unstable-v1.19.1-127-g74794d42b.uf2) and also our build (pimoroni-picow-v1.19.2-micropython.uf2).

Weirdly if I remotely execute the script using the mpremote tool then it runs flawlessly every time. @Gadgetoid sees similar issues from Linux but he reckons it isn't so consistently failing there.

I'm pretty sure something is causing the USB stack to fall over on the Pico W which is then causing it to hang.

I've reported the issue here: https://github.com/micropython/micropython/issues/8904

Should this include the picounicorn module? I see other pimoroni related modules so I'm sure I flashed successfully.

>>> help('modules')
__main__          breakout_paa5100  motor             ucollections
_boot             breakout_pmw3901  neopixel          ucryptolib
_boot_fat         breakout_potentiometer              network           uctypes
_onewire          breakout_rgbmatrix5x5               onewire           uerrno
_rp2              breakout_rtc      pcf85063a         uhashlib
_thread           breakout_scd41    picographics      uheapq
_uasyncio         breakout_sgp30    picokeypad        uio
adcfft            breakout_trackball                  pimoroni          ujson
automation        breakout_vl53l5cx pimoroni_bus      umachine
breakout_as7262   builtins          pimoroni_i2c      uos
breakout_bh1745   cmath             plasma            upip
breakout_bme280   dht               qrcode            upip_utarfile
breakout_bme68x   ds18x20           rp2               urandom
breakout_bmp280   encoder           servo             ure
breakout_dotmatrix                  framebuf          uarray            uselect
breakout_encoder  gc                uasyncio/__init__ usocket
breakout_icp10125 hub75             uasyncio/core     ussl
breakout_ioexpander                 inventor          uasyncio/event    ustruct
breakout_ltr559   jpegdec           uasyncio/funcs    usys
breakout_matrix11x7                 lwip              uasyncio/lock     utime
breakout_mics6814 math              uasyncio/stream   uzlib
breakout_msa301   micropython       ubinascii
Plus any modules on the filesystem
>>> import picounicorn
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: no module named 'picounicorn'

EDIT - Sorry, I just found #434

@SebasZH the fix has made it into MicroPython upstream so I'm prepping a release. Does this build work for you? - https://github.com/pimoroni/pimoroni-pico/suites/7510762818/artifacts/308952836

@Gadgetoid I am sorry to tell you that the firmware version you mentioned above (pimoroni-picow-8cbac4e4968bd0cdfca27e4c5a90d96d0436b63c-micropython.uf2) and also the Pimoroni branded Micropython 1.19.5 for PicoW, doesn't work. Same issue and error message as before on MacOS.

However, the firmware you mentioned here: firmware-picow-wifi-race-fix.zip does work. (MicroPython v1.19.1-170-g16726c750-dirty on 2022-07-18; Raspberry Pi Pico W with RP2040)

Addition: @Gadgetoid The sample code provided by @lowfatcode does work on MacOS with the Pimoroni branded Micorpython 1.19.5, however that code doesn't use networking/WiFi. My code which creates a webserver still locks up the rp2040 with both the firmware provided by MicroPython as well as the Pimoroni branded version. Did also mention in https://github.com/micropython/micropython/issues/8904 .

@SebasZH looks like upstream sniffed out the problem and found a fix, which I've bumped us to pending a PR merge. Test build here:- https://github.com/pimoroni/pimoroni-pico/suites/7539789418/artifacts/310923513

@Gadgetoid Yes, this new build works on MacOS with both the simple script and the webserver example. Thanks!

I see. Still, I think ulab is interesting for the servo2040 board, where one may want to run complicated movement calculations

@teuler agreed- there's currently no custom build for Servo 2040 so when I get some time I'll rig one up with ulab included and more flash allocated to MicroPython itself. The same probably applies to Motor 2040. Just need some very loud "back up your files" warnings to go with those.

Any chance of a Galactic Unicorn build with ulab? Or any pointers as to how I could do this if it's possible? :D