I am using openmv cam H7 plus with attached lcd shield which says “LCD shield rev.2”. About a year ago I had this setup run fine when testing with default example and some drawing.
Yesterday after a long break I updated IDE and firmware. That is when strange things started to happen.
Opening the lcd example yesterday did not work -at all- because for some reason open mv wanted to add some display.py script to the file sytem which seemed to use touch function and failed with some import gt911 or so…
Today I installed the latest develop firmware using extra/install latest firmware. Although it says it might be unstable I can now run the builtin lcd example without messing things up with this display.py script like yesterday.
However colors are broken. It looks as if color depth or Pixel format are broken.
Are any known issues with lcd shield support? I mean if the builtin examples won’t work, what else to trust.
Second part of my question is: check lcd — lcd driver — MicroPython 1.20 documentation
i noticed that in the example (see code below) we see import display. import lcd is not even possible with this firmware. But when ich hover over lcd in the line lcd = display.SPIDisplay() # Initialize the lcd screen.
help shows me code from an (old?) example which corresponds to the information given in th micropython docs.
So what is going on there? Is it some inconsistency in the firmware? What is the difference between import display in the latest example and import lcd from the wiki and many older examples? At the moment I feel lost.
fyi the code that shows after opening the example is as following
# LCD Example
# Note: To run this example you will need a LCD Shield for your OpenMV Cam.
# The LCD Shield allows you to view your OpenMV Cam's frame buffer on the go.
sensor.reset() # Initialize the camera sensor.
sensor.set_pixformat(sensor.RGB565) # or sensor.GRAYSCALE
sensor.set_framesize(sensor.QQVGA2) # Special 128x160 framesize for LCD Shield.
lcd = display.SPIDisplay() # Initialize the lcd screen.
lcd.write(sensor.snapshot()) # Take a picture and display the image.
I had access to an other computer with IDE 4.03 ( I not update as suggested of course). After downgrading the firmware to 4.4.3 I tried the example for the shield and with IDE 4.03 I have lcd imported in the example.
Just as described in the micropython api and sample sources. In that configuration I cannot (as expected import display).
Everything works, colors are ok.
Hi, we shipped a few LCD displays that had the wrong byte format. There are two new arguments to the SPIDisplay().
Set them to True to byte reverse the pixels on the screen or bgr to true to reverse red/blue.
The docs need to be updated. I will have that done within the next few days.
If you can post a picture of your display I can point out the issue.
Hi, new resources and IDE have been released. The problem with things being out of sync should have been solved.
As for the image quality. Please a picture of your lcd screen and I can advise which option you should use to fix it.
Thanks for this blazing fast response.
Taking a picture of my lcd might take some days because I am not at home for some time.
Attached you see a picture of my lcd shield plus the result running the current demo.
Given that using old firmware the results were ok so far, see above post, a hardware defect or generel incompatability seems unlikely to me.
I have tried lcd.init( bgr=True|False, swap_bytes=True|False) in all combinations.
Are there any ideas or suggestions?
Hi, the output is byte reversed. The arg is not called swap bytes. You need to pass what is in the documentation. Then it will work.
Thanks for the answer.
I think I tried byte_reverse and named it swap in the post, but of course I am not sure. Optimistic to get it work
The arg is now called
byte_swap. Please use the latest firmware and the updated scripts and it should work, it should be initialized like this:
lcd = display.SPIDisplay(..., byte_swap=True)
The documentation has been updated too:
EDIT: Actually with our LCD shield I don’t think you need to change any defaults, the default args should work, unless there’s a bug or something.
Will try that later.
I was used to have the display work out of the box with older firmware. After updating and using the display class from the latest firmware the problems showed up. Former firmware using lcd class did indeed work out of the box as you expected.
You’re right I just tested it, and it is broken indeed, but it’s not related to byte_swap/BGR, seems to be an issue with the buffering. If you pass
triple_buffer=False for now it will look normal. We’ll fix this and it will work with the defaults with no special args. Note you should still use the latest firmware and latest scripts.
EDIT I see the problem, it’s just the arguments are parsed in the wrong order. Will have a fix and a stable release very soon.
If you install latest development release now, this issue should be fixed.
Wow great job! Works perfectly again. Thanks