-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ILI9486 (Waveshare 3.5-inch (B)) support #136
Conversation
Nice! Out of interest, have you tried the Linux framebuffer driver with this display? To get this PR through we ought add some simple regression tests and update the documentation |
... and probably convert the CI from Travis to GitHub actions (in another PR) beforehand |
See #137 |
Yes, I first tried out the display via the repository that Waveshare provides: https://github.com/waveshare/LCD-show.git I didn't use their shell scripts, but inspected what overlay they make use of and loaded it myself. The dtoverlay uses a
in addition to an array of (The relationship between that github repository and Waveshare's is unclear to me.) The luma.examples work fine via linux_framebuffer, with bounce achieving >20 fps when using the diff algorithm. The combination of luma.core's diff algorithm with whatever approach the device driver is taking for updates leads to a fair amount of tearing. Using full_frame, bounce gets 6.2 fps through the framebuffer. Using luma.lcd directly at 50 MHz (a frequency that is certainly questionable for this display), bounce is achieving 5.3 fps with full_frame and 19 to 23 fps with diff. There's much less tearing, though! :)
I'll take a look at what the tests require. Since the tests presumably run without actual display hardware, are they just performing some sanity checks? The ili9486 addition mimics the structure of the ili9341 support identically. My chief concern is that other ili9486 displays may not have the 16-bit registers of the particular Waveshare that I have. Looking around github at other (open license) implementations for ili9486 support, the byte padding only gets mentioned in conjunction with Waveshare. That would seem straightforward to support -- use a conditional to control whether padding gets added or not -- but that conditional would be unique to the ili9486. I also have no means of HW testing it. |
Any hints on how one runs tests? I'm still relatively new to Python development, and the amount of infrastructure around Python projects is impressive. That said, I don't know how to run much! |
@mattblovell from repo checkout directory: make sure to install tox, pytest etc first using:
then run tests:
or py38 or whatever version you're using. also run:
to check for any lint errors. |
I tend to develop luma code & run tests on a Mac or desktop Linux machine rather than on an RPi. It was often painfully slow - certainly on RPi 2B, but might be better now on 4B |
Also, I can help out with the tests. We can mostly do a cut’n’paste job from ili9341 |
That would be most appreciated! I'll see if I can free up some time tonight to try out |
I double-checked that the padding zeros are indeed needed for the Column Address Set (0x2A) and Page Address Set (0x2B) commands within "Armed" with that information, I thought I would reexamine the positive and negative gamma settings for ili9486 in both juh/fbcp-ili9341 and ImpulseAdventure/Waveshare_ILI9486. Adding the commands with byte pads just yields terrible colors -- blues and purples end up with really bad saturation. Dumping the initialization bytes from the dtoverlay that Waveshare makes available and pulling the gamma correction from those, colors seem fine but don't appear noticeably different than what the display uses without any gamma controls specified. The Waveshare overlay is using 18-bit colors, which matches the initialization I'm trying (via Memory Access Control, 0x36). The other two repositories are only set up for 16-bit colors. Perhaps that explains the difference. Anyway, just thought I'd explore the gamma settings a bit further. |
Starting on tests for ILI9486. So far, test_init_320x480 is now passing. Need to get tests_offsets and test_display_full_frame healthy.
I think I have the entries in
Execution time for
I don't immediately know why the Python 3.8 tests are unhappy. |
Ah, linting woes. I like blank lines, though! :) I'll try to clean that up... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic!
I’ve got one of these on order now because of you! 😁
FYI, you can run |
Excellent! Hopefully it even works! 😄 Did you get the Waveshare one or a different ILI9486-based one? I have to say that the IPS panel is a nice feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comments. Can you also add yourself to CONTRIBUTING.rst
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks.
Great! I'm very glad to contribute back to luma.lcd. The excellent documentation for this project, and the breadth of supported displays, is what encouraged me to give these little LCD displays a try in the first place. I've learned a lot since September. |
v2.8.0 released with this in 🚀 https://pypi.org/project/luma.lcd/2.8.0/ |
RE: 16-bit registers, I just found this : https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/tiny/ili9486.c#L38 |
The following additions, primarily to
device.py
are working for me when using this ILI9486-based display:https://www.waveshare.com/3.5inch-rpi-lcd-b.htm
attached directly to the GPIO header of an RPi4 Model B. That particular display (or the controller) wants to run in portrait mode, 320x480. Rotation is thus necessary to use it as 480x320. (I was stuck for quite a while getting an odd display trying to use it in landscape mode.)
The various demos within luma.examples all seem to be happy, using either full_frame or the diff algorithm to update the framebuffer. Some misc observations:
I've run the
bounce.py
demo with a SPI bus frequency up to 50 MHz, achieving ~23 fps. Performance does still scale with SPI bus frequency.The
pi_logo.py
demo also runs at such high frequencies, but the rendered colors end up being incorrect. The leaves on the Pi logo end up being orange instead of green! Slowing down to 32 MHz gets the colors correct. (Animation speed is still quite good at that SPI frequency using the diff algorithm.)Interestingly, the gradient example within
colors.py
is still unhappy even at 32 MHz. Even though the rest of that example, including the opening photo and the rainbow screen, all look fine, the gradient screen ends up with artifacts suggesting bad data transfer. Slowing down to 28 MHz, the gradient screen looks perfectly normal (photos below).Thanks,
Matt
fixes #135
Gradient screen from
colors.py
@ 32 MHzGradient screen from
colors.py
@ 28 MHz