Stdio to Pico Display Pack 2.0 in C/C++

[Slion]

Do you guys have examples showing how to display stdio on Pico Display Pack 2.0 in C/C++?

[peardox]

The pico_display_2_demo.cpp example sticks some text on the screen (which looks like what you're after)

[Gadgetoid]

Actual stdio would require a Pico SDK-compatible stdio driver, which doesn't seem too complicated (here's the UART one for example: https://github.com/raspberrypi/pico-sdk/blob/efe2103f9b28458a1615ff096054479743ade236/src/rp2_common/pico_stdio_uart/stdio_uart.c) but not something we've considered attempting!

[Slion]

Thanks guys! I actually got this working weeks ago by implementing a driver as suggested by @Gadgetoid.
It's very convenient for developing when you don't have access to serial or just did not connect it.
It works with both small and large Display Packs.
You can even scroll vertically and horizontally to see the off screen logs using the buttons.
Even has options to adjust backlight and LED brightness.

Unfortunately it's not currently open source and the code is rather ugly but it does the trick for now.
Might even consider open sourcing it at some point, if ever I get the time.

Also I was wondering if it's possible to detect at runtime which Display Pack model is connected? Right now I'm using a compilation option to switch between large and small Display Pack.

[Slion]

It take about 54ms to render one frame on Display Pack 2.0 and 21ms on the small one, depending on the content. I had fun optimizing the frame rate but there is only so much that can be done. I even tried to offload the rendering to core 1 and it was working for a few frames but then crashed. Not sure if it's something you guys ever attempted. Sounds like the right approach though. For now I've given up on that idea though.

[peardox]

Also I was wondering if it's possible to detect at runtime which Display Pack model is connected? Right now I'm using a compilation option to switch between large and small Display Pack.

Good question (I also have)

[Gadgetoid]

Also I was wondering if it's possible to detect at runtime which Display Pack model is connected?

I don't think so, but you could perhaps make it selectable. There's nothing stopping the driver being initialised at runtime with any particular settings for any particular display.

They can't generally be detected because they are write only, so there's nothing to query. But you could try to init one driver at a time and ask the user to "press A if you see a picture." Y'know, like old TV modes on the Xbox or something 😆

Unfortunately it's not currently open source

Sad stdio display driver noises!

Might even consider open sourcing it at some point

That would be cool, it would make a nice little standalone example

It take about 54ms to render one frame on Display Pack 2.0

That feels slow. Is that a whole screen of text? Bitmap fonts I guess?

[peardox]

Also I was wondering if it's possible to detect at runtime which Display Pack model is connected?

I don't think so, but you could perhaps make it selectable.

I just tried running pico_display_2_demo (320x240) on a pico display pack (240x135) to see what happens as they use the same IO.

Result was a full size display thaat was centered - i.e. HELLO WORLD test was off screen. But as the demo uses buttons to move the text around I was able to move it back on frame.

This suggests that if you limited yourself to the smallest size it'd work on any display (not checked - just though of running the test...) - partially useful knowledge if you know that only a ST7789 will be attached (and use same IO). I did actually try the other way around yesterday - pico_display_demo (for the smaller device) on the 2.0 and that resulted in a load of black space around the demo (to be expected)

Sorta makes me wonder if I can plug my HyperPixel 4 into the pico :)

[Slion]

That feels slow. Is that a whole screen of text?

Yes pretty much full of text and off screen text is culled properly too if I recall well.
Most of the render time is the update call which is synchronous too.
For Pico Display Pack 2 RGB565 is the native color depth and the fastest to update at 24ms but take up 150KB out of 246KR RAM. RGB332 is slower to update at 32ms but takes up only 75KB out of 264KB of RAM
For a while I used the native colour depth buffer which is fastest to render but I had to switch back to the smaller buffer as I was OOM. The 54ms frame time I gave above is for RGB332 so it includes 32ms for the update and 22ms of text rendering.

Bitmap fonts I guess

Yes indeed, I did try the Hershey though but settled for bitmap mostly because it looked better if I recall well. Is one faster to render than the other?

[Slion]

So I'll be looking forward for the Pico 2 extra RAM which would allow usage of the faster larger frame buffer even for the Display Pack 2 and my RAM hungry application.

Has anyone tested the Display Packs with Pico 2? Do they work?

[Slion]

But really what we need for faster rendering that's not impacting the app performance so much is to be able to render from core 1. As anyone ever tried that before?

[peardox]

I don't think so, but you could perhaps make it selectable. There's nothing stopping the driver being initialised at runtime with any particular settings for any particular display.

This was regarding detecting display size...

Just been reading the st7789 docs and this is indeed possible albeit with limitations

9.1.3 RDDID (04h): Read Display ID

Reads four values from the ST7789

The 1st parameter is dummy data
The 2nd parameter (ID17 to ID10): LCD module’s manufacturer ID.
The 3rd parameter (ID26 to ID20): LCD module/driver version ID
The 4th parameter (ID37 to UD30): LCD module/driver ID.

Depending on how often they change suppliers these values should be fairly constant.

The Display Pack, 2 and 2.8 should all have differing values as should other displays. Will be checking this...

Interestingly I'm waiting for a 3.5" touch with a different controller (ILI9488) and brief look at that datasheet seems to be a superset of the 7789 so it appears likely that the ubiuquity of the 7789 may make it a lowest common denominator in use by other devices as well

[Slion]

@peardox Most interesting, thanks for sharing.

I think we should open a specific issue for this, then I realized this issue is in https://github.com/pimoroni/pico-boilerplate and I wonder why I created it here rather than in https://github.com/pimoroni/pimoroni-pico
Could be the reason why it has been sitting here for weeks without anyone getting involved.

I opened a new specific issue then: pimoroni/pimoroni-pico#1004