Is the ILI9486 Waveshare supported ?

[rogerclarkmelbourne]

Looking at the driver fort the ILI9486 it looks like it uses different pins than is documented for the Waveshare board.

I presume if this is the case I'd need to make a copy of the ili9486 folder and modify it to make a Waveshare driver ??

[bkosciow]

hi, I'm using this with waveshare shield via SPI and it is ok. If you have gpios then use GPIO driver and set new pins, something like this: drv = GPIO() drv.pins = { 'RS': 27, 'W': 17, 'DB8': 22, 'DB9': 23, 'DB10': 24, 'DB11': 5, 'DB12': 12, 'DB13': 16, 'DB14': 20, 'DB15': 21, 'RST': 25, 'LED': None, 'CS': None }

[bkosciow]

Seems I answered wrongly :) There is no gpio drv for ili9486 but if you copy one from ili9325 or just use it, it should work with gpio

[rogerclarkmelbourne]

OK. I think perhaps the display I have is non-standard.

It looks like a clone of the Waveshare display, but I dont know the definitely pinout

I found this

http://www.lcdwiki.com/zh/3.5inch_RPi_Display

But the pinout does not match either the ILI9486 driver or the pin list in the readme :-(

[bkosciow]

Display from URL is an SPI one and its output is exactly the same as mine: https://www.waveshare.com/product/4inch-rpi-lcd-a.htm Use SPI driver and it should work. Remember to enable SPI on RPi

[rogerclarkmelbourne]

Ok have SPI enabled using raspi-config, and the ili9486_image.py did start to display an image but it was corrupted and then was erased when only half complete.

[rogerclarkmelbourne]

I'm very confused

I looked in https://github.com/bkosciow/gfxlcd/blob/master/gfxlcd/driver/ili9486/spi.py#L13-L17

self.pins = {
            'CS': 8,
            'RST': 25,
            'RS': 24,
            'LED': None
}

for the ILI9486 control pins, but they don't match the pins for your screen

https://www.waveshare.com/product/4inch-rpi-lcd-a.htm

where the pins seems to be

CS:24 RST:22 RS:18 LED:None

What demo works with your screen ?

I don't think any of the drivers match your screen pins

BTW. My screen is probably https://www.waveshare.com/product/3.5inch-rpi-lcd-a.htm (or another very similar)

[bkosciow]

It depends how you count gpios, see here: https://raspi.tv/2013/rpi-gpio-basics-4-setting-up-rpi-gpio-numbering-systems-and-inputs GPIO 8 => pin #24 GPIO 25 => pin #22 GPIO 24 => pin #18

[rogerclarkmelbourne]

Ah. OK. My bad... I see what you mean.

Unfortunately my screen still doesn't work :-(

It does work if I use the "driver" from WaveShare (LCDShow), but if I run the ili9486_image.py demo e.g.

python3 ./ili9486_image.py

What I get displayed is random.

One time when I ran the demo, I got half an image, but it then cleared.

Sometimes I get random patches of noise pixels, and the pixels seem to flicker as if the screen has a 10Hz refresh rate.

The reset that the library performs, always seems to work, and the screen gets cleared each time I run the demo, but apart from that, it looks like either the commands that are being sent are not compatible with the chipset on my display, or the RS pin is incorrect, and commands are getting interpreted as data.

(I have some experience of other displays e.g. ILI9341 on microcontrollers, so I understand the process of updating the display.

I presume there must be a way to read the device ID and confirm the chipset.

[rogerclarkmelbourne]

I'm not sure if this is the problem, but a friend of mine has an identical board, and tested it with your library on his RPi 3B and it worked fine, but I'm using a RPi 3B+ and it doesnt work,

I have a RPi Zero W, and I will load the latest Raspbian Stretch onto that board, and retest.

Can you tell me if you have tested your library on the RPi 3B+ ??

[bkosciow]

Hi. I tested it on Rpi2b / 2b+ / Zero / Zero W The last thing that is on my mind is to reduce SPI speed, try to change it via the second argument to SPI class?

[rogerclarkmelbourne]

OK. I am going to test on a Rpi Zero soon, but its taking a long time to install from a new SD card (to do the updates)

I presume the SPI speed should be the same on the 3B and 3B+, but I had other problems on the 3B+ with some USB devices not working, because of timing problems, so perhaps the same applies to the SPI bus :-(

I will confirm if it works on the Zero W.

[rogerclarkmelbourne]

I just tested on my RPi Zero W, and it works OK.

So the problem seems to be only on the RPi 3B+

I will try changing the SPI speed, but perhaps the problem could also the timing of the CS or RS pins, where perhaps a delay needs to be inserted between, enabling CS and SPI transmission starting

Or possibly a delay between the RS signal and PSI (or all of them need a delay)

Its strange because on the RPi Zero the image loads very slowly compared with other microcontrollers connected to displays like the ILI9341 (which are similar)

On a 72Mhz microcontroller its possible to send approx 10 frames per second of 320 x 240 to a ILI9341 display, but the image takes at least 5 seconds on my RPi Zero.

Even the drawing demo is much slower than on a microcontroller.

So whatever the problem, I would be surprised if its the SPI speed.

BTW. Do you know any C code which does the same as you Python library, as I think it may be to slow for my application

[bkosciow]

Python is very slow I tried to write C lib, it was faster but still not fast enough. GPIO was much faster but SPI only a few times ;) https://github.com/bkosciow/cili should install via pip install gfxcili I think we should use a different mode to have a decent speed when streaming

[rogerclarkmelbourne]

OK

I looked for a lib that was completely in C, but could not find one.

I'm not much of a Python programmer, and prefer C, but I think most people use Python on the RPi because its easier.

I think perhaps I should open another issue to show that the library does not seem to work on the RPi 3B+ and probably won't work on the 3A+ either, and I will close this issue.

[midium]

I know long time is passed, though I've found this python library (https://github.com/huliqun/Myway_Python_ILI9486) that works fast like a charm on displaying things. I have to admit anyway that the image quality is slightly lower than the one from using your library. I smell this is due to how the image is managed by the library. Not sure if maybe you can borrow some concept from this one to fasten up your ;)

[bkosciow]

thanks for info, quick look and I see that the image is used as a buffer. I will look deeply, maybe some LCD setting is a key

[midium]

I think the problem of the speed is on how you draw the image. I've just checked how you do it on the draw_image method of Area.py class and it seems a lot more cumbersome way of the one from the other library I've sent you. Basically they use numpy to get the bytes buffer of the image and then they send this buffer in chunks without making lots of checks. Maybe this is rendering the image with a slightly worst resolution (and anyway it is very good) of yours, but surely is quite fast. One further improvement would be recognize those areas that are actually changed from the previous image and render just those (for example when rendering a menu we might just change the color of the highlighted element and restore the previous selected one, so why render the whole image again instead of maybe smaller and faster to render areas?) but I still can't foresee how to do it.

[bkosciow]

I will look into it but my function is more complicated. It checks for transparency and tries to avoid overwriting pixels. But I think rewriting it to use numpy and bytes should improve performance a lot. I will also check different access to SPI Thanks for pointing it out As for buffer, I was thinking about it (as I use a buffer in CharLCD lib) but it is faster to just rewrite some parts than call area function on display. I haven't got time to find solution to detect how large the change is and if we want to skip or rewrite area