Closed tannewt closed 3 years ago
Can I help folks (@gadgetoid, @nseidle, @mbanzi) do board defines for your boards? We'll need a USB PID for each, the pin names on silkscreen and the flash chip used.
Cytron have a Maker Pi Pico which looks like it's the Raspberry Pi Pico soldered to a larger peripheral board.
@tannewt are you looking for a VID/PID combination specific to CircuitPython? I think we can supply those.
I'll try and gather the other information when I can. Everything is still chaos :laughing:
@tannewt are you looking for a VID/PID combination specific to CircuitPython? I think we can supply those.
I'll try and gather the other information when I can. Everything is still chaos laughing
Yes please! Are your boards currently available? If you point me to schematics I can add defs but not test them. Thanks!
For your gaming system the display chipset would be useful too so we can auto-init it.
@tannewt the PicoSystem display is based on the ST7798V and we run it in the 12bit mode with RGB subpixel ordering - the LCD is 240x240.
Our full init sequence is:
st7789_command(st7789::SWRESET);
sleep_ms(150);
st7789_command(st7789::MADCTL, 1, "\x04");
st7789_command(st7789::TEON, 1, "\x00");
st7789_command(st7789::FRMCTR2, 5, "\x0C\x0C\x00\x33\x33");
st7789_command(st7789::COLMOD, 1, "\x03");
st7789_command(st7789::GCTRL, 1, "\x14");
st7789_command(st7789::VCOMS, 1, "\x37");
st7789_command(st7789::LCMCTRL, 1, "\x2C");
st7789_command(st7789::VDVVRHEN, 1, "\x01");
st7789_command(st7789::VRHS, 1, "\x12");
st7789_command(st7789::VDVS, 1, "\x20");
st7789_command(st7789::PWRCTRL1, 2, "\xA4\xA1");
st7789_command(st7789::FRCTRL2, 1, "\x0F");
st7789_command(st7789::GMCTRP1, 14, "\xD0\x04\x0D\x11\x13\x2B\x3F\x54\x4C\x18\x0D\x0B\x1F\x23");
st7789_command(st7789::GMCTRN1, 14, "\xD0\x04\x0C\x11\x13\x2C\x3F\x44\x51\x2F\x1F\x1F\x20\x23");
st7789_command(st7789::INVON);
st7789_command(st7789::SLPOUT);
st7789_command(st7789::DISPON);
sleep_ms(100);
st7789_command(st7789::CASET, 4, "\x00\x00\x00\xef");
st7789_command(st7789::RASET, 4, "\x00\x00\x00\xef");
st7789_command(st7789::RAMWR);
But if I can provide that to you in a more helpful format just ask!
We rely on the fact that the ST7789 only requires you to issue RAMWR
once and will automatically wrap back round to the start once you've written the entire framebuffer. This allows us to just put the display into data mode once initialised and hand over control of those pins to the PIO which actually performs the screen updates on PicoSystem. That may not be relevant to your concerns though!
@tannewt are you looking for a VID/PID combination specific to CircuitPython? I think we can supply those. I'll try and gather the other information when I can. Everything is still chaos laughing
Yes please! Are your boards currently available? If you point me to schematics I can add defs but not test them. Thanks!
We'll be building our final (hopefully :D) production samples of TinyUSB and PicoSystem next week. If physical samples are useful to you then please drop me a line (jon@pimoroni.com) and I'll make sure we post some out!
Full list of boards that we're launching with RP2040 in (i guess...?) early February:
We'll allocate VID/PID for each next week too and get that over to you.
@lowfatcode for the pico lipo - please add a qwiic/stemma QT (JST SH) connector? they're only a few cents and available in vertical or horizontal. people will like the board even more and we'd sell lots :) for lipo monitor you can use the LC709203, we have library code for it, works well enough.
Thanks for having Maker Pi Pico in the list. We're testing it with CircuitPython. So far the only issue is GP15, as described here.
@tannewt - We're jumping in and are going to take you up on the offer to help the port to our rp2040 boards. I'll follow-up via email with contacts/logistics on our end.
hi @kirk-sfe please do not email, stick to github, you an open a new issue!
Hi @ladyada - cool. Our sw team will coordinate with Scott/this repo on the logistics to get this moving.
We rely on the fact that the ST7789 only requires you to issue
RAMWR
once and will automatically wrap back round to the start once you've written the entire framebuffer. This allows us to just put the display into data mode once initialised and hand over control of those pins to the PIO which actually performs the screen updates on PicoSystem. That may not be relevant to your concerns though!
Ah! We probably won't use that mode in CircuitPython because displayio
tracks dirty areas and only updates the relevant portions. Are you connected to the display over 8 bit parallel? We'd need to implement displayio.ParallelBus for that (should be easy with PIO.)
We'll be building our final (hopefully :D) production samples of TinyUSB and PicoSystem next week. If physical samples are useful to you then please drop me a line (jon@pimoroni.com) and I'll make sure we post some out!
No need to send me stuff! I'm hoping you all will test CircuitPython on the boards. (I'm a bad tester anyway.) I'll update this issue shortly with helpful links for adding a board.
Full list of boards that we're launching with RP2040 in (i guess...?) early February:
Great! I've added them to the TODO list above.
Thanks for having Maker Pi Pico in the list. We're testing it with CircuitPython. So far the only issue is GP15, as described here.
No problem! I'm happy to track who to reach out to. :-) The GP15 thing should be fixed today with #4063
@lowfatcode Here is an example of how we init a display internally: https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/boards/pygamer_advance/board.c#L40 I believe it's for an ST7789.
The CircuitPython driver is here: https://github.com/adafruit/Adafruit_CircuitPython_ST7789/blob/master/adafruit_st7789.py
Ah! We probably won't use that mode in CircuitPython because
displayio
tracks dirty areas and only updates the relevant portions. Are you connected to the display over 8 bit parallel? We'd need to implement displayio.ParallelBus for that (should be easy with PIO.)
No we're only talking to it via SPI so it should work fine with your current setup. :-)
No need to send me stuff! I'm hoping you all will test CircuitPython on the boards. (I'm a bad tester anyway.) I'll update this issue shortly with helpful links for adding a board.
Roger that!
TOTAL_FLASH_SIZE has been refactored into board settings to handle different flash sizes.
@zodiusinfuser want to add the remaining pimoroni board too?
Thanks Scott. We'll stick with the boards I've already added for now, as the other's still need more dev work if I recall correctly. Also we need to look more seriously into the USB PID situation as we only had a few spare.
I've been having a lot of fun and success with the Maker Pi Pico but ran into this strange issue with CIRCUITPY
disappearing yesterday #4282
We've got the bulk of boards added. Closing this.
Adding a board to CircuitPython is very easy! It's primarily mapping the names of pins on the silkscreen to the internal GPIO names. We have a thorough Learn guide on adding a board here. This is the same process for all of our ports. If you are unfamiliar with git and github, then this guide should get you going. You end up making a pull request to this repo with your changes for the
ports/raspberrypi/boards
directory. Once the board is checked into this repo you can also add it to circuitpython.org with these instructions.We ask that you only call CircuitPython by its name when the board support has been merged into the
main
branch here. That ensures a consistent experience from the get-go and also ensures the latest versions of CircuitPython are available for your board. (We move fast and things improve rapidly.)Need help? Feel free to reply here with questions or ask them on the Adafruit Discord server in the #circuitpython channel, which we use for development. If no one responds, then feel free to mention me (@tannewt).
Many were announced and will likely be available in the next few months.