STILL Cant get waveshare 3.5 inch screen to work

[holadivinus]

I can't figure it out!
whenever I try a CDIV under 18 it breaks.
the core freq is 400.

build command is:

cmake -DWAVESHARE35B_ILI9486=ON -DSPI_BUS_CLOCK_DIVISOR=18 -DSTATISTICS=0 ..

This is quite infuriating especially with multiple people saying it works with just cdiv 14 and core freq 400 UGH

[holadivinus]

:(

[juj]

400MHz/18 = 22.22MHz. The WaveShare (B) 3.5 inch display I tested with worked with 255MHz/8=31.88MHz max. Although the display controller spec is only rated to work up to 15.15MHz, so anything beyond that is good luck, and 22.22MHz > 15.15MHz, so that is already ~+46% faster than the spec rating goes.

WaveShare has a new (C) revision display that is rated up to 125MHz. Have not tried it personally, though in #63 really good performance numbers were reported. (Although there is no public spec sheet available of the display, so support is scarce)

[holadivinus]

Found the problem. i was using a waveshare 3.5 A instead of my B

[holadivinus]

Ummmm none of the configs in waveshare35b.h work and neither are the ones your comment say works.

;-;

[holadivinus]

Tried cmake -DWAVESHARE35B_ILI9486=ON -DSPI_BUS_CLOCK_DIVISOR=16 -DSTATISTICS=0 -DUSE_DMA_TRANSFERS=OFF ..

just made garbo- in the top left corner :(

[juj]

It does then suggest that the copy of the display you are working with maxes out somewhere between 22.22MHz and 25 MHz. :/ Not sure there is anything to do about that.

[martinville]

After messing around a lot I found that the below options works best (Note the below is on a RPI 2B+) You may need to alter -DARMV8A=ON if you run it on a different pi. My WS 35B2 TFT screen seems to be very finicky.

sudo cmake -DSPI_BUS_CLOCK_DIVISOR=14 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_INVERT_COLORS=ON -DUSE_DMA_TRANSFERS=ON -DSTATISTICS=1 -DARMV8A=ON -DDMA_TX_CHANNEL=4 -DDMA_RX_CHANNEL=5 ..

or without the DMA Transfer setting. (Probably safer to test with)

sudo cmake -DSPI_BUS_CLOCK_DIVISOR=14 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_INVERT_COLORS=OFF -DUSE_DMA_TRANSFERS=ON -DSTATISTICS=1 -DARMV8A=ON ..

[holadivinus]

I dont know how your getting that. almost everything i try results in garbo or black screen. :(

[holadivinus]

NOW when i load cmake -DWAVESHARE35B_ILI9486=ON -DSPI_BUS_CLOCK_DIVISOR=18 -DSTATISTICS=0 ..
the screen has lines running down it and inverted colors WTH AAWDaikfwaoufiuahfaofaAFREGAGFGAGFADSSASGDGASG

i've. been. recompiling. and. changing. and. running. variants. all. DAY! nothing works!

I'm using a 3.5-inch waveshare screen (B) on an RPI 3 B+.
NOTHING FLIPPING WORKS
EVEN MY SAFE COMMAND HAS STOPPED WORKING
IVE REINSTALLED THE DRIVER 3 TIMES NOW AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

I'm sorry but this is REALLY getting on my nerves. hours wasted on this stupid problem... see you tomorrow.

[holadivinus]

😡

[juj]

In issue #103, @rafistolique has found out that his copy of ILI9486 display is able to reach faster speeds if one disables DMA, and also restores the looser idle 9th bit in SPI transfers by editing

diff --git spi.cpp
@@ -98,9 +98,10 @@ void SetRealtimeThreadPriority()
 // Errata to BCM2835 behavior: documentation states that the SPI0 DLEN register is only used for DMA. However, even when DMA is not being utilized, setting it from
 // a value != 0 or 1 gets rid of an excess idle clock cycle that is present when transmitting each byte. (by default in Polled SPI Mode each 8 bits transfer in 9 clocks)
 // With DLEN=2 each byte is clocked to the bus in 8 cycles, observed to improve max throughput from 56.8mbps to 63.3mbps (+11.4%, quite close to the theoretical +12.5%)
 // https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=181154
-#define UNLOCK_FAST_8_CLOCKS_SPI() (spi->dlen = 2)
+#define UNLOCK_FAST_8_CLOCKS_SPI() ((void)0)
 
 #ifdef ALL_TASKS_SHOULD_DMA
 bool previousTaskWasSPI = true;
 #endif

then that configuration actually reaches much faster overall SPI bus speeds for the ILI9486 display, or at least his copy of the display. If you are still looking for performance improvements, it may be worth a to take a look. The whole thread #103 is worth taking a read if using iLI9486 display.

[juj]

Closing out old issues.