Runtime detection of Display Pack variant

[Slion]

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.

Apparently it could be doable:
pimoroni/pico-boilerplate#20 (comment)

Display driver ST7789 datasheets.

Looking at the Pimoroni code that RDDID (04h): Read Display ID command has not been implemented.

[peardox]

Looking at the Pimoroni code that RDDID (04h): Read Display ID command has not been implemented.

No, there are a several interesting ST7789 instructions missing including one that does vertical scroll (actually it's more or a vertical rotate but...). Looking at the code it has signs it was specifically written for one of the earlier displays then added to for new LCD sizes which is a little worrying.

Still going thru the datasheet (it's 319 pages) but it also appears we could simulate a text display. OK, not an overly astonishing revelation, but the buffer required would be tiny where you only needed to show N out of M symbols - which is a useful option IMHO

[Slion]

also appears we could simulate a text display.

Another interesting find, I won't bother with it just now though. In the context of stdio it's definitely something that could be used to improve the frame rate.

[Slion]

I tried to implement that RDDID command but I've never used SPI before and sure enough I could not get it working. None of the commands from Pimoroni driver are doing any read operation on SPI.
I tried to use spi_read_blocking without luck so far. All it reads is zeros.

Attempted a bunch of stuff around those lines:

    gpio_put(dc, 0); // command mode
    gpio_put(cs, 0);

    uint8_t commandId = 0x04;

    spi_write_blocking(spi, &commandId, 1);

    sleep_ms(1);

    gpio_put(dc, 1);
    //gpio_put(display.cs, 1);

    int read = spi_read_blocking(spi,0x00,rddid,sizeof(rddid));

    //int read = spi_write_read_blocking(display.spi,&commandId,rddid,1);

    gpio_put(cs, 1);

I found that but it did not help me much: https://github.com/prenticedavid/ST7789_kbv/blob/d5c7c3c18c9b3a37d9ae5891f0316ae1fe253b0f/examples/ST7789_readreg_diag/ST7789_readreg_diag.ino#L123

The truth is I really don't know what I'm doing here 🫣
It could also be that all those bits are just set to 0 on the Display Pack 2.0 I tested.

[peardox]

Oh, rats. Checking the schematic the MISO pin isn't connected so the device is deliberately set up as write only - which, to be fair, was mentioned in the other thread

Same applies to both display packs

Not sure about 2.8 version as there's no schematic yet

Prevents anything read related then - pity, I fancied having a dump screen function but that's not possible with this wiring either.

There's a similar design by Waveshare that also is write-only. Their 3.5" touch (mine's almost here) display, however, does have MISO as does their 2.8 touch. Looks like it's dependant on a whim of the board supplier then...

[Slion]

Too bad that would have been useful. Something for Pimoroni to improve on next time they revise the hardware design, I guess. It's not like there is not enough pin on the Pico.

[peardox]

Turns out it may still be possible....

Datasheet - 7.4.2 Serial Interface Characteristics (3-line serial)

This means it could work with the one data line - something to play with later once I've read some more and actually started writing some code for the thing (text with tiny frame buffer and rom fonts being the goal)

[Slion]

Datasheet - 7.4.2 Serial Interface Characteristics (3-line serial)

Sadly that's not telling me how the code should look like. If you want me to experiment with something and help me translate that diagram into code I'll be happy to give it a try though.

[Gadgetoid]

Too bad that would have been useful. Something for Pimoroni to improve on next time they revise the hardware design, I guess. It's not like there is not enough pin on the Pico.

It is my understanding that, despite what the datasheet for the controller might say, the actual displays do not have these pins broken out on the ribbon cable.

Eg:

[peardox]

Yeah, there's also Half Duplex SPI which only uses MOSI for data

Researching the subject ATM. Wiring illustration here - note it needs a resistor adding

Dunno if it'll work - hence lots of reading + watching before I even think of trying anything (to avoid killing something if possible)

Oops - won't work with a pack.... No way to do resistor - scratch that idea.

[Slion]

Dunno if it'll work - hence lots of reading + watching before I even think of trying anything (to avoid killing something if possible)

I did not know you could do things like that. Usually I try first and depending on the outcome go do some reading. The other day I killed a Display Pack with a heat-gun 😏

[peardox]

I tried to implement that RDDID command but I've never used SPI before and sure enough I could not get it working.

In your test MOSI is set for output
After the command was sent you'd need MOSI to be input until the results had been fetched - then switch it back to output.

The board appears to be set up for bi-directional communication over that pin

i.e. you may have been attempting to read a write pin :)

[Slion]

In your test MOSI is set for output
After the command was sent you'd need MOSI to be input until the results had been fetched - then switch it back to output

How should I do that? Any code sample? I tried a bunch of things including switching to slave mode using spi_set_slave which would just crash and reboot.

The board appears to be set up for bi-directional communication over that pin

That would make a lot of sense since it avoids wasting one pin for some optional and rarely used functionality that only requires sending a few bytes.

[peardox]

I had a bash at it in the early hours but no luck

From examination of the sdk it appears that only 'proper' full duplex mode is supported

The schematics show the settings of the st7789 IM0-2 pins but not IM3. Depending on whether IM3 is low (di-directional) or high (extra data bit) determines if read is possible at all - this info was gleaned from the 2.8 schematic (don't remember it being detailed on the others)

At one point I even hacked spi.c/h but didn't get anything working

Ticket to Pimoroni time to find out what the wiring is that they don't show.

It appears that everyone wires these things up this way. It's annoying as there are some nice things you can do with read access - there's even a vertical blank signal...

Then again VBL wouldn't help an amazing amount. The thruput to the LCD is already on the high side. Given the clocks available your theoretrical limit on a pico1 would be about 50FPS and it already does 30 so about 60% of the time we're just sending data to the screen

[peardox]

Copy of ticket to support for information....

I have all the Pico Display packs and several other devices with displays such as enviro pack and display breakout.

Examining the Scematics for all these boards I am unable to tell how the ST7789s they all use are configured. The nearest I can get is from the display pack 2.0 which labels the states of IM0, IM1 and IM2 - this leaves IM3 unaccounted for. The difference in whether IM3 is low or high alters the workings of a ST7789 (we've got a lengthy discussion on github on exactly this topics) # 1004/1005

Would you kindly inform me of the wiring of IM3 so I can tell if something I'm attempting to do is possible or not in the first place (low = possible, high = impossible)

Also the display pack 2.8 is still marked as schematic coming soon - techie was on holiday (they're obvuisly back now so can we have that schematic pls)