ILI9341 with Pico?

Hi,

Does anyone know how to use ILI9341 LCDs (http://www.electrodragon.com/product/eds-tft-lcd-lcm-spi-interface-variable1-82-2/) with a Pico? There's a module page for the classic Espruino (http://www.espruino.com/ILI9341) but I can't find a way to make them work with my Pico. The only difference with the insctructions on the page is that I plugged CS to the A8 pin (instead of B8) and used A5 for GND and A7 for VCC. And I don't know what to do with the LCD LED pin.

The screen doesn't display anything with the 2 sample scripts from the module page. I have tried with a 2.2'' and a 2.4'' LCD from electrodragon.

It should work fine - I've actually got one here soldered to a Pico.

Are you wiring up by hand, or just connecting it to something like a breadboard?

If you're wiring by hand you should really make GND connect to GND, VCC connect to 3.3v, and LED connect to 3.3v too.

If you're just placing it right in, make sure that the LED pin goes to a GPIO pin that you can also make 3.3v.

It's worth checking that the backlight has lit up - it should be pretty obvious. Some of those displays might need GND to turn the LED on, rather than 3.3v.

Ok it's probably the LED pin then. Your second example (paletted mode) doesn't seem to use this pin so I just assumed it was useless. :-)

I just tested the LCD on my Pi and it works so at least I know I have a working unit. The brightness is terrible though, I'm wondering if I somehow killed the backlight by using 5v instead of 3.3v. Is that even possible with a Pico?

I think the screen draws too much current to drive off of GPIO pins. As gordon recommended, you need to connect Vcc to the 3.3v pin, and Gnd to Gnd. I think if you do that, it will work.

Unless you connected something the VBat pin (which is at almost 5v when powered off usb), you couldn't have applied 5v to it - besides, when LEDs get abused, they usually fail completely.

I have had those LCDs working off of GPIO (hence the example there) as the GPIOs will provide 20mA. It's not great though and brightness generally suffers compared to wiring directly to power - it's just a handy way of using the display if you want to plug it into breadboard without much wiring :)

LCDs (backlight LED(s)) working off of GPIO

to control brightness.

Some of these LCD carrier/breakout boards use a setting with a transistor (and current limiting resistor) to drive the backlight LED(s) to allow power feeding from a 5V and controlling from a 3.3V. With separate power and a PWM GPIO in control, brightness control is optimal.

in my case ILI9341 is working but on the original Espruino board is pretty fast, and on the pico very slow, I mean about demonstration code form espruino.com, it slower than avr, much slower,
what could be a reason?

Speed depends on how the boards are connected: parallel, serial, and when serial, clk speed matters too. IL9341 performance with Standard Espruino and Pico are for sure comparable. If they are not about equal, something with the setup is wrong. It also depends how many colors and what font is used. I felt it is about the same.

Are both versions using the same firmware, and hardware SPI?

Also, could one be using Paletted code and the other not? There are now some differences there: http://www.espruino.com/ILI9341

I'm not sure if paletted really work with ILI9341...I haven't tried yet, but from my experience of pulling pixels for saving and restoring for implementation of overlay / popup tought me, that over serial it is quite a demanding thing... it is not like the simple BW Nokia displays, even though founctionally it may work. The discussion with @Gordon at that time hinted to switch to parallel from serial to get snappy performance... Using ILI9341 controller's specific data transfer operations in combination with Espruino assembled code could speed up the process as well.

Paletted code works more quickly, but only for changes on the whole screen. Really it's totally dependent on how fast you can get SPI working, whereas the other method often depends more on execution speed.

I recently added Graphics.getModified which could help with this by only updating the modified area, but it would need driver support.