Bitmap colours are not mapping corectly

[unawoo]

hi carter and limor,
just got the new clue...and it works.
i knew when the demo ran, the colours of the graphs were much more intense. then i uploaded the arduino ble image transfer program. all the bitmaps on my phone showed true on this clue, and what a fine screen this is, hi-res bright clear colours.
i will power up my old 100 mhz hp scope on the off chance i can see a difference in the boards, will let you know.
but for now i'll just be exploring this great clue

[adafruit_support_carter]

@unawoo Thanks for the follow up info. So, just to be sure, running both CLUE's the exact same way, firmware, libraries, user code, etc. results in one having the washed out images and the other working OK?

[unawoo]

just read what i just sent and realized that the problem is also with the graphing of colour, not just bitmaps.

[unawoo]

the user code is the same and as it's arduino code i believe that the firmware and libraries are use only for circuitpython, correct?
i will try out cp later but as it now works with arduino code i see no reason why it will not work with cp.

[adafruit_support_carter]

OK, yep, let's go back to the original test, which is trying to load and display a BMP file via CircuitPython. Idea is to have both CLUEs running same *everything* software-wise, and then show that one works and one does not.

[kevinjwalters]

BTW, it's not idle mode, that looks similar but distinctly different and as described by the data sheet.

Code: Select all

>>> import board, time
>>> board.DISPLAY.bus.send(0x39, b"") ; time.sleep(2) ; board.DISPLAY.bus.send(0x38, b"")  # a brief visit to idle world

[kevinjwalters]

I can recreate this on a working clue if i zero out some entries in a pair of gamma tables. REPL example on a freshly powered up CLUE:

Code: Select all

Adafruit CircuitPython 5.3.0 on 2020-04-29; Adafruit CLUE nRF52840 Express with nRF52840
>>>
>>> import board, time, displayio
>>> testcard_file = open("/adafruit-testcard-a-240x240.24.bmp", "rb")
>>> testcard_b = displayio.OnDiskBitmap(testcard_file)
>>> tg = displayio.TileGrid(testcard_b, pixel_shader=displayio.ColorConverter())
>>> grp = displayio.Group()
>>> grp.append(tg)
>>> display = board.DISPLAY
>>> display.show(grp)  ### Looks normal
>>>
>>> display.bus.send(0xe0, bytes(14))  ### PVGAMCTRL (E0h): Positive Voltage Gamma Control
>>> display.bus.send(0xe1, bytes(14))  ### NVGAMCTRL (E1h): Negative Voltage Gamma Control
>>> ### Now looks like the bleached out examples in forums

[unawoo]

]both clue1 (original) and clue2 (replacement) are on firmware 5.3.1 and libraries dated 20200723.
the clue_egg_drop project was used, drag and dropped bitmaps and program to the clues then renamed clue_egg_drop.py to code.py.
these are the results.

clue1_2.JPG (107.85 KiB) Viewed 225 times

clue2.JPG (105.6 KiB) Viewed 225 times

[attachment=2]clue1.JPG[/attachment

[adafruit_support_carter]

Thanks. Can you post photo(s) showing the backside of *both* of these CLUEs as well.

[unawoo]

clue2_back.JPG (114 KiB) Viewed 220 times

clue1_back.JPG (113.8 KiB) Viewed 220 times

clue1 is the original, note that i did unplug/re-plug the screen connector twice.

[adafruit_support_carter]

@unawoo Thanks for the photos.

@kevinjwalters Can you also go back the other way? That is, can you then redo the low level writes back to initial values and then recover good display output?

[unawoo]

hi kevinjwalters,
are you using the sitronix st7789v pdf as your reference? and can you tell me how you know the clue uses the st7789v?
thanks.

[kevinjwalters]

@unawoo Yes, I was using a random pdf I found on the WWW, something like https://www.rhydolabz.com/documents/33/ST7789.pdf . That's based on a bit of a guess as these screens seem to be driven either by an ST7735 or ST7789 driver. A lot of these components seem to have poor identification wrt to model numbers that would accurately link them to the relevant data sheet so I can't be sure that's the exact one. I've no real experiene in this area but from a quick browse these screen drivers all seem both very similar and subtly different - I'm sure that's a source of many issues.

@adafruit_support_carter I was power cycling to get it back to normal. I don't think "read line" is connected up so I can't read out the good values to store them and use them later with a restoring send(). I've got some other stuff to do but I might have a go with Pimoroni's values at some point from: https://github.com/pimoroni/st7789-pyth ... #L248-L278 which looks like they are based on some old Adafruit code.

[unawoo]

Thanks for the reply Kevin, at this point i think this may be a defect in the drive chip, maybe a transistor that is fused on or off and cant be controlled.
Ill look into it further but right now I'm playing with my clue, a good screen sure does make a difference.
Ill keep tuning in on your search.

[adafruit_support_carter]

What's still odd is that the other examples seemed to work. That would seem to indicate the hardware is OK. But the examples also did not try to show as many colors as displaying a BMP might. On the guess that this might be related, here's another test UF2 to try. It simply shows a *lot* of colored rectangles.

Try running this on both CLUEs and see what happens.

CLUE_COLOR_RECT.UF2

(165.5 KiB) Downloaded 11 times