Waveshare 35b 1/3 screen not displaying, rest has garbage text, rotated 90 degrees, and mirrored.

[Trekintosh]

Hello again.

I just got in a Waveshare35b, did a fresh install of Raspbian Lite on my SD card, then downloaded FBCP-ili9341.

I built with these options:
cmake - DPI_ZERO=ON -DWAVESHARE35B_ILI9486=ON -DSPI_BUS_CLOCK_DIVISOR=16 -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DDISPLAY_INVERT_COLORS=ON -DDISPLAY_CROPPED_INSTEAD_OF_SCALING=ON

When running the built script, I get some text, but it's mirrored, and backwards, and lots of the blank space is garbage, but once I enter some text and hit enter a bunch of times to bring it into frame, it seems to appear properly.

There appears to be no difference between cropped, not cropped, or different screen resolutions when not cropped. It still has the garbage in the blank spaces, and the rotation/mirrored. I am currently running the Pi in 640x480 so I can use the HDMI monitor as well as the SPI screen.

Here is an image before I pressed anything, and after I cleared out the screen and added some text approximately in the middle of the HDMI monitor

https://i.imgur.com/SPCOMI2.jpg
https://i.imgur.com/9ivNhzz.jpg

And a youtube video of me starting the script after power cycling the Pi and screen.
https://www.youtube.com/watch?v=NypLTy83oBM

Thanks.

[juj]

Thanks for reporting. Wired up my WaveShare 3.5" display to a Pi Zero, and I can reproduce.. gimme a moment.

[juj]

doh, there was a typo

diff --git a/ili9486.cpp b/ili9486.cpp
index f5ece28..4d3eb0e 100644
--- a/ili9486.cpp
+++ b/ili9486.cpp
@@ -72,7 +72,7 @@ void InitILI9486()
 #ifdef DISPLAY_ROTATE_180_DEGREES
     madctl |= MADCTL_ROTATE_180_DEGREES;
 #endif
-#if defined(DISPLAY_FLIP_ORIENTATION_IN_HARDWAREE)
+#if defined(DISPLAY_FLIP_ORIENTATION_IN_HARDWARE)
     madctl |= MADCTL_ROW_COLUMN_EXCHANGE;
 #endif

try pulling latest code above to fix that. After that it should work ok.

[juj]

Tested that the CMake -DDISPLAY_CROPPED_INSTEAD_OF_SCALING=ON option should also work as expected, i.e. if that is not enabled, the whole display is scaled to view, and when it is enabled, a center portion of the frame is viewed.

A 480x320 screen on a Pi Zero can be a bit of a tough cookie performance wise. Try running with CMake -DSTATISTICS=2 option to view performance graph data, and experiment with #define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF option in config.h to see which works better for this combo.

[Trekintosh]

Thanks! Seems to work like a charm now. So much faster than my UCTronics with their driver, which had framerates in the 1's when working in the console. This seems to be completely usable. I wasn't planning on putting X on this device, but if you like I can grab a RetroPie image and try some games for performance testing.

[juj]

Excited to hear this!

What I'd be most curious to hear about is the max MHz rating that the display can keep up with, before it loses sync. In https://github.com/juj/fbcp-ili9341#which-spi-display-should-i-buy-to-make-sure-it-works-best-with-fbcp-ili9341 I've listed data about my WaveShare 3.5" display: it runs at max SPI speed of 31.88MHz, which I obtain by severely underclocking the Pi by setting core_freq=255 in /boot/config.txt, and using -DSPI_BUS_CLOCK_DIVIDER=8 with fbcp-ili9341, so SPI speed is then 255MHz/8=31.88MHz.

(in regular use the default 400MHz with SPI CDIV 14, yielding 400MHz/14=28.57MHz is so close to 31.88MHz, that gaining the extra few MHz is not worth downclocking from 400MHz to 255MHz, so I don't actually run with that day to day)

By balancing the core_freq= option in /boot/config.txt and the SPI CDIV option to fbcp-ili9341, you can find the max SPI drive speed that the display can run at, up to the last few kHz. https://github.com/juj/fbcp-ili9341#tuning-performance has some paragraphs about this.

I'd be curious as to if e.g. 400MHz/12=33.33MHz works for you, or even faster. That kind of info would help chart a bit how much copy to copy manufacturing variance there exists on these displays.

[Trekintosh]

Interestingly, even 28571429hz (28.57Mhz) doesn't work on my screen. I get garbage text and blank spaces have orange garbage. Like this picture:

Apologies for the glare, this thing is mad shiny but worth it for the IPS screen.

Once I hit enter a few times most of the text reappears, but I still have small lines of orange garbage between lines of text.

[Trekintosh]

In fact with clock div 16 I get worse garbage when there's a lot going on on screen. This picture is supposed to be htop.

However clock div 18 works properly. Any suggestions where to go from here? I don't want to downclock but if there's a combo with mild overclock and divisor that gets closer, I'm all for it.

[juj]

CDIV=16 with core_freq=400 (this is the default Pi speed setting) is 400/16=25MHz SPI speed, whereas CDIV=18 with core_freq=400 is 400/18=22.222MHz, so this tells that the max speed for that display is somewhere between these, 22.22MHz - 25MHz.

You can try setting CDIV=16 while underclocking core_freq option in /boot/config.txt:

• core_freq=384 with CDIV=16 will get 384/16=24MHz speed, or if that's still too much,
• core_freq=376 for 376/16=23.5MHz, or even lower,
• core_freq=368 for 368/16=23MHz, you get the idea.

You can also try overclocking, and set

• core_freq=414 and CDIV=18 for 414/18=23MHz, or
• core_freq=423 for 423/18=23.5MHz, or
• core_freq=432 for 432/18=24MHz.

I have generally used underclocking, since that is safe, and overclocking can be a bit unstable otherwise, and needs good power supply and other voltage settings, good heatsink or fan, etc. Although underclocking does drop overall performance of the Pi, for example for the GPU and memory bus, so it is a tradeoff. Using default core_freq=400 with CDIV=18 for 22.222MHz does not sound at all too bad, it may be that the extra few MHz gained via underclocking might not be worth the CPU performance drop.

[Trekintosh]

Well fbcp takes up 33% cpu at all times as is so underclocking is not a compromise I’m really willing to make for regular use. I’ll try it tomorrow and see if we can pin down a point where the display cuts out though.

…

On Thu, Jun 21, 2018 at 9:23 PM juj ***@***.***> wrote: CDIV=16 with core_freq=400 (this is the default Pi speed setting) is 400/16=25MHz SPI speed, whereas CDIV=18 with core_freq=400 is 400/18=22.222MHz, so this tells that the max speed for that display is somewhere between these, 22.22MHz - 25MHz. You can try setting CDIV=16 while underclocking core_freq option in /boot/config.txt: - core_freq=384 with CDIV=16 will get 384/16=24MHz speed, or if that's still too much, - core_freq=376 for 376/16=23.5MHz, or even lower, - core_freq=368 for 368/16=23MHz, you get the idea. You can also try overclocking, and set - core_freq=414 and CDIV=18 for 414/18=23MHz, or - core_freq=423 for 423/18=23.5MHz, or - core_freq=432 for 432/18=24MHz. I have generally used underclocking, since that is safe, and overclocking can be a bit unstable otherwise, and needs good power supply and other voltage settings, good heatsink or fan, etc. Although underclocking does drop overall performance of the Pi, for example for the GPU and memory bus, so it is a tradeoff. Using default core_freq=400 with CDIV=18 for 22.222MHz does not sound at all too bad, it may be that the extra few MHz gained via underclocking might not be worth the CPU performance drop. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aea2AJG_LMHBa9vOILGY2MuvR8u7pW50ks5t_HEqgaJpZM4UyZgE> .

[juj]

Yeah, that makes sense. The #define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF option in config.h is the single most effective way on the Pi Zero to reduce CPU usage of fbcp-ili9341. That is worth testing if it helps any.

[juj]

Did some profiling and optimization today on Pi Zero + 480x320 display, and was able to reduce CPU usage from ~33% to ~25% in Pi console when #define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF option is used. That is a nice -24% CPU utilization reduction, but it is unfortunately quite far from 0%. Added #define UPDATE_FRAMES_WITHOUT_DIFFING option for more aggressive CPU usage saving. It is recommended to drop TARGET_FRAME_RATE option in display.h, because of raspberrypi/userland#440 it is tricky to drop anywhere near 0% CPU usage.

[Trekintosh]

Okay, so I gave it a shot. Single Rectangular Diff gives me only 15-25% CPU usage, and performance is still excellent.

Update without diffing drops CPU usage down to 5%-10% but performance is utterly unacceptable, with what feels like half a second between a keypress and a reaction on screen. It's actually worse than my UCTRONICS screen's stock drivers.

Both of these were with target framerate set to 30.

I'm content with only 15-25% usage on this machine, but less would always be better. As is though I'm extremely impressed, this drastically cut down CPU usage.

[juj]

Another change that was done today is to introduce the frame rate guessing heuristic from Pi 3B dedicated thread mode to Pi Zero singlethreaded mode. In a console that is idle with only a single blinking text caret on screen, and STATISTICS option not defined, the change optimizes CPU usage down from 15-20% to ~10%.

[Trekintosh]

Yes, after cloning a new one, and building with a target framerate of 20 and single rectangle, I am running at 5-12% CPU at all times. This is most impressive.