kedei 3.5 inch spi tft lcd arduino for sale

2023-01-03 12:32:11

Is there a chance of getting it working with an Arduino Uno R3 or Mega2560? The graphics libraries that use SPI that I"ve found keep mentioning the RST and DC lines, which aren"t present on this board.

I haven"t had the opportunity to try it on a Raspberry Pi yet. From pinouts of raspi (googled images) they only have one long strip of GPIO/etc connectors, do they not? Even if plugging this board onto the 40-pin connector, where the two 5V pins match up, on the raspi the opposing two aren"t GND, they"re listed as "+3,3V" and "SDA". Something tells me that.. well, either I"m missing something, or this display needs some form of connector between itself and the raspi it"s meant to run off originally. (Oddly enough, they came with raspi-with-TFT-on-top plastic enclosures, which wouldn"t leave any space for rewiring pins.)

I doubt it. It would be a lot cleaner with regular SPI for both. You just change mode each time. e.g. 9-bit mode #3 for TFT. 8-bit mode #0 for the XPT.

Ah-ha. The HC595 is a shift register. They might use them to produce 16-bit parallel to drive the TFT. If they do, it will be a nightmare. Even worse than 9-bit SPI.

Well, it"ll be interesting to see if I get this to work eventually. A quick guess would be that with L_CS pulled low, the LCD chip gets to talk with the MISO/MOSI lines. After initializing it, I suppose the next step will be to (read datasheet..) and see if the MISO/MOSI-lines are used to clock out display data with L_CS high so the LCD chip doesn"t listen to that garbage, or if it is meant to be fed through the LCD chip aswell.

16-bit modules are cheaper than SPI display modules. So it is quite possible that he has crippled the display with shift registers instead of buying a proper SPI module.

Oh, this makes it easier - googling for the tarball I needed (lcd_show_v6 for my board since it"s got "v6.1" printed on it) got me to OsoYooTFT/README.md at master · jgamblin/OsoYooTFT · GitHub and http://en.kedei.net/raspberry/raspberry.html

Hrmm.. I don"t think source is included. In the lcd_show_xx blobs are just kernels and modules, with a couple of very small scripts to copy the LED or HDMI kernel to the /boot place of the filesystem. (And no error checking, if you try copying the LED kernel, it backups the original kernel, but if you then run the copy-LED-kernel command again, it happily overwrites your original kernel, leaving you with two LED-enabled kernels and no original. hrrf..)

Well, I downloaded the whole 35MB .GZ file. Unpacked it and found 3402 .ko files. I presume that these are kernel object files. Nothing that looked remotely like source files for your TFT display.

Since the ILI9481 can be driven directly by SPI, this seems a crazy way to do things. Especially since a HC595 might be clockable at 100MHz but you need to wiggle all 24-bits. And an AVR can only manage 8MHz on a good day.

Not when you consider that once you have loaded an 18 bit colour all you need to do is toggle the T_CS pin at say 10MHz and you can load the same pixels sequentially at 10Mpixels/s (=180Mbps) i.e. clear the screen faster than it is refreshed. With SPI you have to keep serially sending the same pixel N bits of colour over and over again, which is very inefficient. In the worst case (where sequential pixels are different colours) the shift register still wins if you can clock it faster than an SPI link maximum rate (easy on higher performance computers) because the same number of bits need to be clocked whatever interface is used.

This suggests more control bit are shifted in than is actually needed, but my hunch of an 18 bit + control parallel interface to the TFT seems to be correct.

That aside, I sort of assume I"ll need a 3,3V logic converter, since the rpi has 3,3v GPIO pins and most arduinos have 5V? So I don"t accidentally burn out the display chips.

Yes, I expect that bodmer or myself could probably get you working if we made some inspired guessing with the schematic. You could always email Kedei and ask him for the genuine schematic. Make sure that you tell him the Revision number(s) on the pcb.

I had success with downloading Kedei"s 4GB images specific for the 6.1 board and putting on an SD card. Now the raspi boots up, and I see the boot messages scroll by. The original article said "expect about 6fps from the display" and that seems right - it"s jerky, but works.

I"m going to order a couple of logic level converters now (a pair of 74LVC245 should do nicely on a breadboard), and then I can poke at it from an arduino environment.

kedei 3.5 inch spi tft lcd arduino for sale

I"ve gotten the level converters now, and experimented a little, with no results but a plain white screen. I copied the "init commands" code from the Linux source for ILI9341, which are the closest thing I could see in the patch made by KeDei for any init-code, plugged an arduino Uno in via a level converter from 5v down to 3v3, with SCK/MOSI/MISO from arduino pins 13/12/11, and pin 9 to toggle L_CS, keeping it HIGH but pulling it LOW for 1 to 5 milliseconds after each 4-byte SPI write.

Eventually I tried without the level converter too, since the 74HC595 datasheet said it could handle "up to Vcc" on the input pins, Vcc being max 6V. But that was after trying a lot of combinations in the code; all the variations of SPISettings in Arduino"s SPI library, for transferring four bytes one at a time (someone else who also looked at these displays found out that the registers always want four bytes - and that the first byte is always 0x0 !). Also doing as you suggested with an extra "DC command bit" so that the "bytes" were 9-bits wide, ending in a zero bit to indicate "command". No luck, ah well.. And I can"t even be sure that either the display is an ILI9341 just because the sales page said so (others had gotten similar displays with another drive chip), or that the code in the kernel source matches this KeDei-version of the display.

kedei 3.5 inch spi tft lcd arduino for sale

I designed this case so I could have the TFT35 screen from a Raspberry Pi on the front of my Ratrig V-Core 3. ...It will probably fit other extrusions but it was designed to sit nicely on 3030 extrusion that the Ratrig has.

3.5 inch TFT LCD touch screen waveshare. ...Arduino Shield.assembled in a bracket with M2x8 screws and M2-IUTB-inserts.Designed By Alon Rahamim from Trixel Engineering.

It also hold a 3.5 Inch TFT Screen. It is made of nine 3.25mm pieces that all connect with four - 3mm screws. Its very easy to print and assemble. Print each piece in any color you want and then just assemble in order 1 through...

This is a slightly tilted (and upright version included) holder for an Arduino mounted ILI9488 3.5" TFT display with touch and TF card reader. While not a complete enclosure, it looks a bit more elegant and is a bit more short-out-safe than having...

Since I switched to klipper and didn"t feel like figuring out the stock screen, I ended up using a Kuman 3.5" tft and a Pi3b+ for my klipper conversion.

Simplified model of a 3.5 inch LCD for Raspberry Pi. ...I used the usb connectors from this model: Raspberry Pi 3 Model B Reference Design Solidworks CAD Raspberry-Pi Raspberrypi Rpi

Fit an [Adafruit 3.5" TFT LCD touchscreen](https://www.adafruit.com/product/2441) [Octopi rig](https://octoprint.org/) in the front panel of the [Prusa i3 Mk3](https://www.prusa3d.com/original-prusa-i3-mk3/), keeping it centered on the printer...

Lerdge 3.5 inch screen Features:Add all-inclusive steel frame for the touch screen, more stable.The motherboard adopts resistance to touch, man-machine interaction provides a variety of options.High-resolution of 480*320.Support high-speed hardware...

This is enclosure for [Mellow FLY TFT V1 3.5 inches](https://aliexpress.com/item/1005004091787313.html). ...The enclosure was designed for Ender 3 printer.

Pi TFT plus Console Case for 3.5 Inch Displays Some additions for using displays without mounting holes: The support frame to place between Display und PI to give the display a better foundation then the connector plug alone could give (fits tightly...

Screen used is KeDei 3.5 inch LCD TFT 320x480 touch screen (sample link https://www.aliexpress.com/item/New-Original-3-5-Inch-LCD-TFT-Touch-Screen-Display-for-Raspberry-Pi-2-Raspberry-Pi/32851565266.html). ... You will need: - The screen (KeDei 3.5 inch...

This is a case for Raspberry Pi 4 with 3.5 inch TFT/LCD Display. It is a tight fit and may require some wriggling to fit the PI in. ...This is a very simple and a sleek case.

ER-TFTM050-3 is 5 inch tft lcd module WVGA 800x480 display,serial,spi,i2c parallel interface,RA8875 controller,capacitive or resistive touch screen panel.Souce from EastRising/buydisplay.com

I designed this stand frame for my new 5 inch CTP screen. It"s this one: JLT Technologies JRP 5008 https://es.aliexpress.com/item/1005002280377732.html Use some M3 screws to hold it. I put some auto adhesive small rubber feet to prevent slipping....

I"ve designed this and use it for holding this screen: http://www.banggood.com/FPV-4_3-Inch-TFT-LCD-Monitor-Screen-For-RC-Models-p-940817.html on my Turnigy 9X remote.

Are are links to the hardware: * [kuman for Raspberry Pi 3B+ TFT LCD Display, 3.5 Inch 480x320 TFT Touch Screen Monitor for Raspberry Pi Model B A+ SPI Interface with Touch Pen SC06](https://amzn.to/33aILS4) * [CableCreation [2-Pack] 3.2 feet Right...

This is a slanted box for compact projects incorporating a 3.2" TFT display such as this one which can be found on Aliexpress and many other places for about $USD8: https://www.aliexpress.com/item/32960934541.html I typically use a daughter card...

The display support comes before the assembly on the RJ45 connection. As a touch screen, I use the Elegoo Display 3.5 "inch TFT LCD touch screen monitor 480x320 for Raspberry Pi.

kedei 3.5 inch spi tft lcd arduino for sale

This is a modified version of the official PJRC ILI9341_t3 library (https://github.com/PaulStoffregen/ILI9341_t3) to work with KeDei Raspberry Pi displays.

And it is always a Work In Progress. Also using a lot of work from the the Raspberry Pi implementation: https://github.com/cnkz111/RaspberryPi_KeDei_35_lcd_v62

This library was created to allow extended use on the KeDei Raspberry Pi display and supports T3.5, t3.6 T4 and beyond. It also has support for other T3.x boards as well as TLC.

Your SPI communications on this board does not go directly to display but instead go to three shift registers. There are also two SPI Chip select pins, one labeled, which looks like it is for the Display and the other looks like it is for the touch controller. This is partially true.

However the SPI communications with the display are a lot different than any other I have seen. For example there are no reset pins, nor a Data/Command(DC) pin. Instead this information is encoded into the SPI data that you send to the display.

We figured it out, as the RPI startup code, did several strange SPI transfers at the beginning, which appeared like they were directed to the XPT2046 Touch controller.

This library borrows some concepts and functionality from another ILI9341 library, https://github.com/KurtE/ILI9341_t3n. It also incorporates functionality from the TFT_ILI9341_ESP, https://github.com/Bodmer/TFT_ILI9341_ESP, for additional functions:

The teensy 3.6 and now 3.5 have a lot more memory than previous Teensy processors, so on these boards, I borrowed some ideas from the ILI9341_t3DMA library and added code to be able to use a logical Frame Buffer. To enable this I added a couple of API"s

Place the Adafruit_ILI9341 library folder your arduinosketchfolder/libraries/ folder. You may need to create the libraries subfolder if its your first library. Restart the IDE

kedei 3.5 inch spi tft lcd arduino for sale

While googling for any info about lcd controller I came across this page: http://heikki.virekunnas.fi/2015/raspberry-pi-tft/, author managed to get from manufacturer patch file for kernel sources and tested it with 4.1.y - on which lcd worked. But still LCD replace HDMI, but I want to use this screen as additional for user interaction, while the bigger on HDMI as presentation monitor.

Since, fbtft has been merged with rpi kernel, so the fb drivers (including ili9341.c) was moved to fbtft_device driver (so the author of page can"t compile latest kernel with driver+patch).

So something about hardware, which I reverse engineered by the "hard way" - "grab multimeter and run through all LCD FPC pins and shift register pins"

Now I noticed there is "9486L" which can suggest that LCD screen is controlled by ILI9486L, I found this LCD on taobao too but I can"t contact seller.

I"m pretty sure about D/C (Pin 37 on LCD) and Reset (Pin 19 on LCD) pins by looking into driver code, but I can"t identify other signals (WR/RD/CS/etc...)

- Controller is not ILI9341/ILI9325 - those are for smaller displays (320x240, etc...), I guess this might be ILI9486/9488 because they are for 480x320 displays. But when I compared init with DS it does not fit right so LCD can have a clone of ILI9486/9488 ...

- Module use only SPI interface and two CE signals (CE0 for touch controller, CE1 for LCD shift registers - compared to others lcd modules, in KeDei module this is swapped),

kedei 3.5 inch spi tft lcd arduino for sale

This LCD Touchscreen HAT fits snuggly on top of the Raspberry Pi, practically form fitting on top of it so as not to compromise the overall dimensions of the credit card sized single board computer. The resistive touchscreen provides you with an easy way to display information coming off of the Raspberry Pi and the OS currently running on it.

The 4:3 aspect ratio backlit LCD equipped on this HAT possesses a resolution of 480 by 320 pixels with over 65 thousand colors and an SPI interface with a 16MHz driver speed. Simply plug the 13x2 GPIO header into your desired Raspberry Pi and you"ll be able to start using your new resistive touch screen!

kedei 3.5 inch spi tft lcd arduino for sale

3) pls try to install the image with raspbian and 3.5 driver and try it again: https://osoyoo.com/2016/05/26/osoyoo-lcd-touch-screen-for-raspberry-pi-installation-guide/

Hey Nikeron, is the used module really an ILI9325? Maybe we could then traceback the display connection and reverse-engineer it. From that point on when the schematics are released for everyone to build those displays themselfes, we could hack it then and create a free driver?

I downloaded RetroPie from https://retropie.org.uk/docs/First-Installation/ and have been trying to get my 3.5″ LCD to work. I downloaded the driver from http://kedei.net/raspberry/raspberry.html as described, but whenever I try and extract it with the “tar xzvf LCD_show_v6_1_3.tar.gz” around 50 lines are executed and then the Pi crashes. When I restart it, it goes into a kernel panic every time. I’ve reinstalled my OS multiple times. I cannot download the raspbian distro with the driver because I have been unable to install RetroPie on top of it and have been unable to display it on the LCD.

Do you mean you don’t want to install the LCD driver but just install OS? If so, this LCD can’t work, but you can search a 3.5 HDMI LCD in our store and it works with just OS for display function.

Hi, I got version 6.3 of the screen. I tried installing it on the latest Raspbian with latest drivers from kedei.net. But when the Raspberry starts booting, the screen only works for a few seconds before being frozen. ( Raspberry works, only screen is frozen ).

I had this happen initially. To resolve it I DISABLED SPI under raspi-config and then also set the bootup settings to be Desktop. I have a weird keyboard and the CTRL-ALT Fn keys didn’t work right, but normally CTRL-ALT-F1 or F7 change you from terminal to desktop virtual sessions in Linux.

Hola buenas tengo un problema es que compre esta pantalla Raspberry PI 3 Modelo B 3.5 “pulgadas TFT Lcd con Pantalla Táctil de la interfaz SPI. 480*320 píxeles con lápiz táctil para PI 2

4).I copied the file >>>LCD_show_v6_1_3.tar.gz<<>/home/pi<>> RASPBIAN STRETCH WITH DESKTOP<<>tar xzvf LCD*.tar.gz<>cd LCD_show_v6_1_3<> ./LCD35_v <>R-pi display to HDMI<> cd LCD_show_v6_1_3 <> ./LCD_hdmi <>./LCD_dhmi<>HDMI to R-pi display<>R-pi display to HDMI<>HDMI to R-pi display<>>!! #I feel like I want to return my display now#.

https://www.aliexpress.com/item/Raspberry-PI-3-Model-B-3-5-inch-TFT-LCD-Display-with-Touch-Screen-by-SPI/32804087006.html?shortkey=iABj6neU&addresstype=600

“ATTENTION” in the instructions they wrote >>./LCD_dhmi<>HDMI to R-pi display<<: it is just to reinstall the driver again, I need to execute the point 5) through the point 7) again.

https://www.aliexpress.com/item/Raspberry-PI-3-Model-B-3-5-inch-TFT-LCD-Display-with-Touch-Screen-by-SPI/32804087006.html?shortkey=iABj6neU&addresstype=600

Hello, I have been able to install the driver and play/switch between LCD & HDMI, now is there any way to turn off the white screed or turn off LCD when Im not using it? Thanks

The LCD doesn’t do anything else. Initially I had the Memory split set to 16MB – but this through up a memory error on the LCD. Setting it higher removes this error – but still nothing else.

kedei 3.5 inch spi tft lcd arduino for sale

I am working on simulators of point of sale devices using Arduino Uno and ATmega 2560. This application would be fine with this touch screen display as what I need is some way of simple data entry to change settings, display settings to the user, and provide a way to trigger some events.

Unfortunately when using this display with an Arduino Uno and the original KeDei TFT library, there is very little memory available for storing data due to the small amount of memory on the Arduino and the large character font array in the KeDei library in file KeDei_font.cpp. However the touch interface seems to work with the Arduino.

The ATmega 2560 has much more memory and I was planning to use an ATmega 2560 instead of an Arduino Uno however I have run into a problem with the touch interface providing incorrect touch points when using the TFT display with the ATmega 2560. I have set the jumpers on the back of the display to 2560 however I"m still seeing incorrect touch points returned.

I have cloned the Osoyoo KeDei TFT library into my GitHub repository and have been working with the library. I have made a change to the 16x16 bitmap font table const unsigned char font16_B[95][16] in file KeDei_font.cpp of the KeDei TFT library to use an 8x8 bitmap font and to also eliminate lower case letters. This change has made a significant improvement by reducing the amount of memory consumed by the KeDei TFT library.

kedei 3.5 inch spi tft lcd arduino for sale

I orderer a 3.5″ SPI touchscreen with a Raspberry Pi 2 and a case, thinking it would be easy to set up, as it seemed to be like the one here. Unfortunately that was not the case.

With some googling I found out it was made by KeDei LCD and exactly this screen. Identifying strings on the screens were “Madei in KeDei of china”, “3.5 linch SPI TFTLCD”, “480*320 16bit/18bit” and “vision 1.0 2015/6/11”. I hope the guys who made this screen can write code better than english… Seems like it requires custom drivers by KeDei. Drivers could be downloaded from Baidu and they include the diff to compile your custom kernel. I haven’t compiled kernels before, so lets see if I could manage without doing that.

I installed Ubuntu on my Macbook Pro on an external hard drive (which is a whole another story, thanks to EFI), so I could follow instructions on Raspberry Pi pages. Compiling on RPi is quite slow (tried that overnight), so cross compiling is the way to go. Following the instructions worked pretty well, however I cloned tools to my home directory and added /home/heikki/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin to my path. After that everything worked as expected. After cloning and changing branch to rpi-4.1.y I patched semi-manually from the supplied diff from KeDei, however I have uploaded my updated diff to make it easier for you. There’s instructions on patching too, but long story short it’s “cat | patch -p1” in the base directory of the clone. The version I used was branch rpi-4.1.y, commit 785cea66a709eddb9858799192a7b7da566b44b0.

You should now have two framebuffer devices, /dev/fb0 and /dev/fb1. I’m not quite sure how the fbtft library interferes with the patch, as it seems to be activated too, but it works so no problem. (Actually I first activated module fb_ili9341, so you can try that too, if it contributed to my success). You can change to console to fb1 by command “con2fbmap 1 1” and back with “con2fbmap 1 0“, or on boot by editing /boot/cmdline.txt: add “fbcon=map:1” to the line somewhere. You can also change the font with “fbcon=font:ProFont6x11“. More things like this here.

kedei 3.5 inch spi tft lcd arduino for sale

LCD Display Modules└ LEDs, LCDs & Display Modules└ Electronic Components & Semiconductors└ Electrical Equipment & Supplies└ Business & IndustrialAll CategoriesAntiquesArtBabyBooks & MagazinesBusiness & IndustrialCameras & PhotoCell Phones & AccessoriesClothing, Shoes & AccessoriesCoins & Paper MoneyCollectiblesComputers/Tablets & NetworkingConsumer ElectronicsCraftsDolls & BearsMovies & TVEntertainment MemorabiliaGift Cards & CouponsHealth & BeautyHome & GardenJewelry & WatchesMusicMusical Instruments & GearPet SuppliesPottery & GlassReal EstateSpecialty ServicesSporting GoodsSports Mem, Cards & Fan ShopStampsTickets & ExperiencesToys & HobbiesTravelVideo Games & ConsolesEverything Else

kedei 3.5 inch spi tft lcd arduino for sale

When surfing for information on 3.5 ” TFT touchscreens for the Raspberry Pi,to improve the TinyLCD experience, I stumbled upon AliExpress where several shops offer a 3.5″ LCD TFT Touch Screen Display for incredible low prices.

Update June 2016: There is now a download/information page at http://osoyoo.com/driver/rpiscreen.php. Images for more versions (mine i 2.0, latest is 6.2) are available there. Alternative ishttp://kedei.net/raspberry/raspberry.html with Kali Ubuntu drivers too for version 3.0 and up.

The archive contains an image of Raspbian with the LCD driver installed. The image is quite current, and fit for B, B+ or 2 B. When I bought the screen an older image, build in augustus 2015, was downloadable, the kernel is quite fresh built, early October 2015.

The image supplied is wheezy, 3.18.9-v7 #27 SMP PREEMPT Sun Oct 4 23:57:41 CST 2015 armv7l. So quite a recent system! Also the Model 1 B and B+ kernel is present, also just current wheezy.

The system uses SPI to copy the screen contents to the LCD screen, and some GPIO’s for the touchscreen. Other GPIOs are free, and the connector construction leaves these pins indeed accessible!

kedei 3.5 inch spi tft lcd arduino for sale

Decided to play with the 74hc595 attached in the same way as U1 for that Kedei display and I attached a Logic Analyzer to some of the output pins. Labeling is based on: https://github.com/wdim0/esp8266_with_KeDei_lcd_module/blob/master/schema.jpg. In a zoomed view it looks like this:

Downloaded your updated lib and ran your test sketch with the "tft.initR(INITR_144GREENTAB_OFFSET);" and it worked perfect for my display (starts with 3,2 if I remember right, also used "tft.setRowColStart(3,2);" with just the initr_144greentab and that also worked.

Not sure if it also would make sense to add my simple test program to the library... If I did would probably remove some of the #define/#ifdef stuff for different boards and different SPI ports... But would add comments that if you specify SCK and MOSI that correspond to another SPI port it will use that port...

Will play soon with that display... May start off by maybe trying to set up an RPI that can at least initialize the display and capture the SPI transfers, to get an idea of what the actual communications are supposed to look like... .

That Adafruit UncannyEyes is pretty nifty - may make a permanent setup for it :) Really nice since you updated the library running at 24Mhz and tested at 48Mhz as well. Still with your updated SPI library as well.

D:\Users\Merli\Documents\Arduino\libraries\ST7735_ t3-T4_beta/ST7735_t3.h:141:8: note: candidate: void ST7735_t3::sendCommand(uint8_t, const uint8_t*, uint8_t)

D:\Users\Merli\Documents\Arduino\libraries\ST7735_ t3-T4_beta/ST7735_t3.h:142:8: note: candidate: void ST7735_t3::sendCommand(uint8_t, uint8_t*, uint8_t)

D:\arduino-1.8.9\arduino-builder -dump-prefs -logger=machine -hardware D:\arduino-1.8.9\hardware -hardware C:\Users\kurte\AppData\Local\Arduino15\packages -hardware C:\Users\kurte\Documents\Arduino\hardware -tools D:\arduino-1.8.9\tools-builder -tools D:\arduino-1.8.9\hardware\tools\avr -tools C:\Users\kurte\AppData\Local\Arduino15\packages -built-in-libraries D:\arduino-1.8.9\libraries -libraries C:\Users\kurte\Documents\Arduino\libraries -fqbn=teensy:avr:teensy4b2:usb=serial,opt=o2std,key s=en-us -ide-version=10809 -build-path C:\Users\kurte\AppData\Local\Temp\arduino_build_74 9147 -warnings=all -build-cache C:\Users\kurte\AppData\Local\Temp\arduino_cache_50 7931 -verbose C:\Users\kurte\Documents\Arduino\uncannyEyes\uncan nyEyes.ino

D:\arduino-1.8.9\arduino-builder -compile -logger=machine -hardware D:\arduino-1.8.9\hardware -hardware C:\Users\kurte\AppData\Local\Arduino15\packages -hardware C:\Users\kurte\Documents\Arduino\hardware -tools D:\arduino-1.8.9\tools-builder -tools D:\arduino-1.8.9\hardware\tools\avr -tools C:\Users\kurte\AppData\Local\Arduino15\packages -built-in-libraries D:\arduino-1.8.9\libraries -libraries C:\Users\kurte\Documents\Arduino\libraries -fqbn=teensy:avr:teensy4b2:usb=serial,opt=o2std,key s=en-us -ide-version=10809 -build-path C:\Users\kurte\AppData\Local\Temp\arduino_build_74 9147 -warnings=all -build-cache C:\Users\kurte\AppData\Local\Temp\arduino_cache_50 7931 -verbose C:\Users\kurte\Documents\Arduino\uncannyEyes\uncan nyEyes.ino

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\SPI" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp" -o nul

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\SPI" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ Adafruit_GFX_Library" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp" -o nul

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\SPI" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ Adafruit_GFX_Library" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ ST7735_t3" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp" -o nul

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\SPI" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ Adafruit_GFX_Library" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ ST7735_t3" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\preproc\\ctags_target_for_gcc_minus_e. cpp"

"D:\\arduino-1.8.9\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\preproc\\ctags_target_for_gcc_minus_e. cpp"

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/precompile_helper" "D:\\arduino-1.8.9\\hardware\\teensy\\avr/cores/teensy4" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -x c++-header -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr/cores/teensy4" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/pch/Arduino.h" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/pch/Arduino.h.gch"

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_b uild_749147/pch" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4" "-ID:\\arduino-1.8.9\\hardware\\teensy\\avr\\libraries\\SPI" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ Adafruit_GFX_Library" "-IC:\\Users\\kurte\\Documents\\Arduino\\libraries\\ ST7735_t3" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp.o"

Using precompiled core: C:\Users\kurte\AppData\Local\Temp\arduino_cache_50 7931\core\core_teensy_avr_teensy4b2_usb_serial,opt _o2std,keys_en-us_44178ada4dfd24cbd2e3430cabf71fb5.a

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TD:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\sketch\\uncannyEyes.ino.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\libraries\\SPI\\SPI.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\libraries\\Adafruit_GFX_Library\\Adafr uit_GFX.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\libraries\\Adafruit_GFX_Library\\Adafr uit_SPITFT.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\libraries\\Adafruit_GFX_Library\\glcdf ont.c.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\libraries\\ST7735_t3\\ST7735_t3.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147\\libraries\\ST7735_t3\\ST7789_t3.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/..\\arduino_cache_507931\\core\\core_teensy_avr_te ensy4b2_usb_serial,opt_o2std,keys_en-us_44178ada4dfd24cbd2e3430cabf71fb5.a" "-LC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_b uild_749147" -larm_cortexM7lfsp_math -lm -lstdc++

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.eep"

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.hex"

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.lst" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.elf"

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.sym" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.elf"

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/teensy_post_compile" -file=uncannyEyes.ino "-path=C:\\Users\\kurte\\AppData\\Local\\Temp\\ardui no_build_749147" "-tools=D:\\arduino-1.8.9\\hardware\\teensy/../tools/" -board=TEENSY40

"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_749147/uncannyEyes.ino.elf"

D:\arduino-1.8.9\hardware\teensy/../tools/teensy_post_compile -file=uncannyEyes.ino -path=C:\Users\kurte\AppData\Local\Temp\arduino_bui ld_749147 -tools=D:\arduino-1.8.9\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/7/2 -portlabel=(null) -portprotocol=(null)

@defragster - Hard to know what caused these both to get into the state, that it would not run that specific program, but would load and run others. And then once I changed it significantly enough it would load again... My guess is it could be some screwy timing thingy or maybe some exact size write at some specific location or, maybe a voltage spike/brownout as maybe I was plugging in or unplugging one of the displays or...

For the heck of it today, I hooked up that strange RPI TFT display to an RPI3, and then setup logic Analyzer to capture some of their initial SPI conversation.

Once installed you can load saved captures and scroll through the data, update some of the analyzers... Like look at the SPI for the touch screen init...

I have not found any searches by the markings shown on his version on what the underlying screen is... It looks like it may have about 40 pins coming off of the display, which I don"t believe matches for example the one I have Eastrising which I think the actual display has like 50 pins coming off of it. Nor have it Tried to pick apart the one ILI9486 version for Arduino Mega shield to see what display it has and the pins coming off of it.

Note with the LA, you can click on the sort of wheel looking thing on the right of the SPI thing under analyzers, and you can click to export as text/CSV file, which can give you textual verison, which I have done... I then tried editing the file to combine the 4 lines associated with each output that had a 0x00 next line 0x11 and marked that as CMD and then likewise for 0x15 and marked as DAT

Reading some more on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=124961&start=200 . They reference a driver for our display that uses wiringPi: https://github.com/cnkz111/RaspberryPi_KeDei_35_lcd_v62, If you look at his LA shots looks similar to what you got.

I now have it at least crawling on T4... The problem was that tft.begin() was never called, and as such the stuff was never initialized like the _csport and _cspinmask

T_CS - Chip select for xpt2046, you need this in order to make display work! nasty �� manually yank this line(pull low) when finish sending data through SPI

This sounds like the classic issue with multiple SPI devices on the same buss. You might try setting all of the CS pins HIGH before trying to init either device.

That is there was #if for the tft displays, then #elif for the adafruit OLED library and then #else for this one... As I did not see any good define to check directly for other library... it uses #pragma ONCE or the like...

This sounds like the classic issue with multiple SPI devices on the same buss. You might try setting all of the CS pins HIGH before trying to init either device.

It may be that the display in use does not tri-state the LCD MISO pin and that prevents the TOUCH controller reading of the needed data from the shared MISO pin. The common one we got has that issue, either the LCD MISO must not be connected {my solution} - or it must have a tri-state buffer installed and controlled by the use of a CS pin - @mjs513 resolved that - on this thread?

For a given SPI bus - unless there is some magic here I missed - common signals go to a common pin. Placing the device wire to another inactive pin would be he same as not having it connected.

Not sure what sketch I used except an example? Anyone with the right touchscreen XPT2046_Touchscreen driver [ili9341?] if none in that library was right for mine. Even if the display didn"t work - that returned valid info with touch on the SPI.

Lots of things not done (and/or maybe not doable...). Like I have not tackled rotation yet, nor DMA output Asynch... Not sure how doable that is as you need to change CS and TFT CS for each grouping of 3 or 4 bytes...

My Kedei displayed arrived today, same one as yours: https://www.ebay.com/itm/New-3-5-inch-TFT-LCD-320-480-Touch-Screen-Display-Module-for-Raspberry-Pi-3-B/263427102486?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649, it says version 6.3 on the back - hooked it up to the 3 T4b2s that I have and no dice nothing gets displayed with any of the sketches including your latest library. Have no idea why. Can"t have miss connected 3 times but then again you never know.

Gave up the RPI display - cant get a damn thing displaying on it. Even tried it on the T3.6. Even tried using pin 9 for CS. I also reinstalled Arduino IDE 1.8.9 and the latest teensyduino from post #3 I think it was. No luck with that either - do you hook up miso to anything? I have no idea why it won"t work and my LA trace is so screwy. I did download the latest SPI with writeRect incorporated. Maybe try again later.

@mjs513 - Totally understand giving up on that display! I would post picture of setup, but... Out of curiosity you might try running one of the simple apps like the frame buffer test program posted above, and hook up your LA, but without display, and see if the SPI conversation is still screwed up (that is state of CS pins...)

@mjs513 - bummer on display not displaying. I felt that when I could not get proper connects on breakout. The rPi KeDei here did hook up with a 6" M<>F Dupont cable to bare T4 M_pins into 9488 F_headers:

Tried power to 3.3V and no go - needs 5V, LED is very bright and as noted seems washed out, not enough contrast from TFT colorizing/blocking with BLACK being light gray.

You will need the latest core, Kurt"s modified Adafruit_GFX library and latest SPI with the writeRect PR (still open). The uncannyeye sketch is in post #353.

NOTE: Once it compiles to upload a failed repro build - to get back to working SerMon USB seems to take a SECOND Button push to get working SerMon back from USB. The SPI LED will blink - but USB stays corrupted until a second Button Push upload.

Edit: I am seeing two kinds of fail - the obvious one I removed debut_tt and made the config.h change - T4 not running - no SPI LED and this on SerMon:

I now have it so it builds and crawls on Teensy LC... it uses SPI.transfer and SPI.transfer16 to do the work. Might be able to more on it, but it aint worth it!

Ready to do 3d graphics on the T4 and adding to the libs: http://crawlingrobotfortress.blogspot.com/2015/12/, Better 3D graphics on the Arduino: avoiding flickering and tearing or how about ray tracing: https://hackaday.com/2014/11/25/ray-tracing-on-an-arduino/

Playing around with the simple kedei sketch in post #386 the colors are still off so I put in a wait for input loop so I can try to match the colors to screen. I got this, it looks like the bits need to be flipped when being sent. The colors with a c next to it I think make it colors maybe @defragster can check:

That is as mentioned before I do have an Logic analyzer capture of a startup on RPI... I have also had the LA output a CSV file of the SPI transfers. That starts off like:

I took another look at the data. First thing is I wondered if maybe looking at the wrong edge of the clock in the capture, so I changed it. (Go to SPI Analyzer click on the thing choose settings).

I am as bad as you. I did some massaging of the txt file and added a column for lcd_cmd and lcd_dat, a lot of duplicates ( I did in it excel using if statement). Tell me what you think:

Will be interesting to hear what your new display does. If it is still screwed up color wise, then one of the next things I would probably do with one of these display with different colors is to, try running it on an RPI with their Raspian image with the driver already installed. I did this with my display to verify it would output something. It came up with the complete Raspberry PI(linux) desktop on the display.

a) reconnect it to teensy and see if this (or one of the other sketches) now shows the correct colors. Which might imply that the KeDei driver somehow updated the display

Also another possibly interesting thing involved with this startup sequence is there is the SPI stuff talking to what we think is only the touch display. There is a conversation that happens before we actually then do the init sequence which those other CSV files showed...

So reloaded my saved away logic output, and setup another SPI filter looking at the TouchCS as the CS pin. Had to also change defaults on idle cs high or low, and trailing edge...

It could very well be. I got my third display and tested it on T4 - Ran the graphics test sketch and nothing - screen remained white. So I ran the kedei startup sketch and it displayed the 4 berries although colors still wrong but it was a lot clearer. Then I put it in the Pi and colors were correct and got a black background. There was one thing I did just since I noticed they had Touch on CS and LCD on the pin next to it. I swapped TS and CS pins without changing them in the sketch and it still worked...….

So reloaded my saved away logic output, and setup another SPI filter looking at the TouchCS as the CS pin. Had to also change defaults on idle cs high or low, and trailing edge...

Since I don"t have the raw data what you would have to do is to lcd_cmd(MOSI) and LCD_DAT(MISO)? or do I have it backwards - please teach me master yoda :)

a) I know on our current boards the SPI transactions, with the Touch CS being asserted with SPI, I know works with the XPT2046 chip on the display as we have a working version of touchpaint that uses this. Which is interesting as it does not go with these 4 byte outputs per command request.

Sorry - been distracted playing with this crazy display. Nothing seems to work to get it to right without negating the colors. I edited the kedei_simple sketch to pull in the startup from the other other sketch so been using that to play with. I did try mode3 and mode1 - no luck. Heres the sketch I was using - similar to what you just posted KurtE:

Anyhow - one thing I see is a couple of the colors BLEED flicker running the vertical bars - in both versions … about a quarter inch of streaky bleed - about a half dozen of the bar sets - others are crisp and clean. Not ALL combo"s but some half on the my left edge of middle bar bleeding left across to the leftmost bar.

"T:\\Ard186t4b2\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "T:\\TEMP\\arduino_build_647594\\preproc\\ctags_tar get_for_gcc_minus_e.cpp"

"T:\\Ard186t4b2\\hardware\\teensy/../tools/precompile_helper" "T:\\Ard186t4b2\\hardware\\teensy\\avr/cores/teensy4" "T:\\TEMP\\arduino_build_647594" "T:\\Ard186t4b2\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -x c++-header -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\Ard186t4b2\\hardware\\teensy\\avr/cores/teensy4" "T:\\TEMP\\arduino_build_647594/pch/Arduino.h" -o "T:\\TEMP\\arduino_build_647594/pch/Arduino.h.gch"

"T:\\Ard186t4b2\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_647594/pch" "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\cores\\tee nsy4" "-IT:\\tCode\\libraries\\SPI" "T:\\TEMP\\arduino_build_647594\\sketch\\KeDei_star tup.ino.cpp" -o "T:\\TEMP\\arduino_build_647594\\sketch\\KeDei_star tup.ino.cpp.o"

T:\tCode\libraries\KeDeiRPI35_t3\examples\KeDei_st artup\KeDei_startup.ino:142:6: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without

That is for example the lcd_dat commands between about the range 290 and 8630 and likewise 8641-16647 are just screen data, i.e. a 2 byte version of screen data. so I would replace these groups of outputs, into a couple of: const uint16_t screen1[] = {

Note: The values are now consistent from that touch request... What I noticed is I looked at the XPT2046 library and it was doing SPI at 2mhz, I was trying up to 30mhz... I then looked again at the captured SPI data and they were doing 8mhz.

Try.adding tft.setRotation (0).. Working from phone now, in bed about to crash. We may to add that to the begin function. Will te SD this tomorrow.

- also noticed when I pick up the KeDei to manipulate touch - my finger hits the tft voltage regulator on the back - it is right at too hot to touch comfortably for very long. The LED backlight is VERY/too bright.

I #if 0 - the init code at the start that tried to talk to the XPT2046 and ask for that special value, as we do it later correctly. The earlier code had too fast of a SPI speed to work, and we did not look at the values anyway.

Got latest Github KeDei from KurtE. Ran TouchPaint - all looks good. Only thing is Maybe the pressure detection on touch - seem to get weird liftoff dots?

Also need to check on the SPI speed - when I pushed it higher beyond a point on ili9341 it got flakey. - is it still using the 2M in the XPT_Touch code?

With the Teensy 3.2-3.6, I mostly saw that it was the SSD1306 (OLED screens) that were problematical with higher SPI bus speeds. I don"t recall having to slow down the SPI bus for the ST7735, but it maybe at the faster Teensy 4 speeds you do.

I did try to change the SPI clock down to 12Mhz but still exhibited the same behavior. Even tried at lower CPU clocks with no luck. However, playing around a little more I got it working by adding a single print statement to the eye movement loop, and fixed the whole issue:

When I had neopixels and the prop shield hooked up together with uncanny eyes, I found I needed to add a small delay between switching pins 11/13 between SPI mode and normal pin mode or else the first neopixel LED would stick.

Hardware: Some of these boards appear to probably have tristate on the MISO pin and some don"t, i.e. they don"t work well with other SPI devices. Which I believe includes the aliexpress. Some may have it. And of course some of them have different touch screen options.... So different libraries and the like would need to be used depending...

a) There is no way (that I know of) to use 16 bit colors with these displays in SPI mode. So we map colors from 16 bits to 18 bits, when we do graphic operations. So while on ILI9341 when we output a color: it is 16 bits that get sent over SPI(565 format). But for these displays it is 24 bits that get sent. This also implies by simple calculations that updating the display takes a lot longer than ILI9341. 320x240*2=153600 to 320x480*3=460800 (i.e. 3 times slower)

Again same size display as ILI948x boards, but they are screwy! That is instead of having the display with normal display processor doing SPI, it uses 3 shift registers. It also has an XPT2046 chip on board. This communications with this board are really screwy. If you want to know more details, they are scattered in this thread. Some of which are in the readme file of my github project: https://github.com/KurtE/KeDeiRPI35_t3

Software(https://github.com/KurtE/KeDeiRPI35_t3) : We probably spent 10 times as much time as these displays warrant. But we were too stubborn to give up.

https://www.ebay.com/itm/Adafruit-1-54-240x240-Weitwinkel-TFT-LCD-Display-mit-MicroSD-Slot-ST7789-3787/253600039760?hash=item3b0bbd8350:g:25IAAOSwcTRa6wJ J

Adafruit just announced it last week, so it may be taking its time going through channels. I checked over at the waveshare official site (https://www.waveshare.com/product/modules/oleds-lcds.htm), but I didn"t see any 240x320 displays that were the Adafruit size.

I"ve played around with a couple of ILI9488 displays with the parallel interface and the UTFT display library. I bought an SPI display but have been traveling for most of the last month and have only had time to unpack it from the box. I"m just now getting ready to try it out with your ILI9488_t3 library. I anticipate that the SPI interface is much slower than the 8/16-bit parallel interface. Is there any interest on integrating a parallel interface capability into the ILI9488_t3 library?

And made sure to include "tft.setRotation(0);" in my code so the above line is executed, and boom, the #defined colors are correct now. I"ll have to try bitmaps later.

kedei 3.5 inch spi tft lcd arduino for sale

I picked up a few of these KeDei screens from AliExpress when they were on sale for about $10 each: https://www.aliexpress.com/item/High-en ... 20356.html

In both cases I"ve been able to get the screens working, up until Emulation Station starts to run. At that point, emulationstation only outputs to HDMI, and the RetroPie logo on the TFT fades to black. If I kill emulationstation, focus switches back to the TFT.

kedei 3.5 inch spi tft lcd arduino for sale

You Might Also Be Interested In