Raspberry Pi released a new microcontroller in August. this one comes with up to 48 GPIOs, making it look tantalizingly feasible to drive full 24-bit color to the LCD directly from the microcontroller.
so, I spun a new board, with a minimalist architecture of Just A Microcontroller, Pretty Much.
RP2350B chips don’t appear to be produced yet in the volume required for them to be available as bare components at all, only in end-user products, and at the time I sent this board to the fab (late August), the Pimoroni PGA2350 was the only product on the Raspberry Pi web site that contained a RP2350B with all the GPIOs broken out to pins. as a new product, no Pimoroni resellers in the US were stocking the PGA2350, so I took the risk of ordering a few of them from Pimoroni directly. unfortunately, they got lost somewhere in the mail, and I didn’t pay for tracking1. I also registered with Raspberry Pi for developer samples, but I haven’t heard anything about them since signing up.
however, at the end of September, I did eventually manage to track down a few PGA2350s at the Canadian branch of PiShop, so out of desperation I paid for (tracked, this time!) shipping down to the states.
regrettably, actually driving the screen directly from the RP2350 wasn’t actually feasible — at least, not with my current level of firmware programming skill. I only tried for a few hours, but I only got the display to refresh at about 20Hz (according to my oscilloscope), too slow for the LCD to sync properly, and the microcontroller spent its entire time servicing DMA requests.
however, the rest of the peripherals seemed to work fine, and I was actually able to get Bluetooth “working,” in the sense that it would accept an association request from my Bluetooth keyboard and then immediately crash the RP2350 with an assertion failure. but at least that’s close enough to working that it feels like there’s a point to starting to dedicate time to working on firmware while Rev D is at the fab, instead of sitting on my hands.
mistakes made and lessons learned
- the raw SRAM-to-SRAM DMA bandwidth of the RP2350 is about 490MB/sec, with 32-bit transfers.
- you only need to send about 55.2MB/sec of data over the wire to get a 640x480x24 framebuffer from place to place at 60fps.
- unfortunately, even though there’s enough GPIOs to push 24-bit color data out to the display, and theoretically you can move the data from place to place in real time, the work of generating 18 megapixels per second from a palettized color buffer (giving you about 8 system clock cycles per pixel, at 150MHz) is still slow enough that it’s still not fast enough to actually keep up with the work of refreshing the screen.
- people say online that you can overclock the RP2350 to 600MHz, which should make it possible, but nobody online actually seems to describe the process of overclocking RP2 microcontrollers, and I don’t really want to spend the time figuring it out from first principles just to barely get the LCD interface to cooperate while the chip is running way out of spec and also needs to be doing three or four other things anyway.
- I mentioned in the last post that I learned from Cosplay Light and Sound the value of designing LEDs into your boards. this proved itself to me on this hardware revision, where it came in very handy for debugging multiprocessing problems, like seeing at a glance whether PIO state machines were running or not, as well as whether FreeRTOS tasks were getting scheduled.
- the I2C I/O expander from the Rev A board (the Diodes Incorporated PI4IOE5V6416) was also very helpful for driving 8 LEDs while only dedicating 2 GPIOs, and also not having to place current-limiting resistors for them.
- unfortunately, even at the I/O expander’s lowest drive strength (2.5mA), the LEDs are still obnoxiously bright in the cave-like atmosphere of my desk at night. nothing that a little Scotch tape and Sharpie couldn’t solve, though.
- Bluetooth is a nightmare. even after designing this board around a real full-fat ESP32 module and fixing all the known hardware issues, it took me 3 or 4 8-hour days to get btstack compiling, running, and to kitbash together a couple thousand lines of example code into something that allowed me to prove to myself that the Bluetooth stack on it was actually working well enough that I could spin a Rev D board without having to patch any other hardware flaws.
- if you’re trying to get btstack working on FreeRTOS, make sure to #define HAVE_FREERTOS_TASK_NOTIFICATIONS. this is explained exactly nowhere. except that google groups thread, I guess.
looking forward to Rev. D
most of this board worked out of the box. I had to apply a couple bodges — I didn’t realize that when you’re connecting UARTs between two chips on a board, RTS and CTS should be crossed over between the chips the same way TX and RX are — but that was a 10-minute task.
in Rev. D, in order to reduce the amount of data that needs to be DMAed out to GPIOs and the number of indirect memory accesses the processor needs to do, palettized color is coming back from Rev. A: this time, thanks to the additional GPIOs on the RP2350B, with a 256-color palette and no I2C I/O expander required. (okay, on the actual board there is an I/O expander, but it’s used for debugging LEDs as well as switching between 16 different palettes stored in different regions of RAM. I’m not sure if that functionality will be in the final board, but it was basically free to wire up for the time being.)
- my British partner tells me that in the UK, something getting lost in the mail entitles you to a refund, which is both extremely common-sense and, as an American, also bordering on unbelievable. Pimoroni seems to have run through their whole inventory of RP2350Bs, though — the PGA2350 is on backorder, and has been for weeks — so it doesn’t really matter anyway for the time being. ↩︎
Leave a Reply