kedei 3.5 inch tft lcd display spi with touch screen free sample

2023-01-03 12:32:11

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.

As we have found in several other places on the Web, this board is very much different than most of the other display boards, and it is still unclear what the underlying display controller actually is.

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.

That is if the Touch CS is low (asserted) and the other CS is high (not asserted) than the communications are processed by the XPT2046. And our updated example sketch touchpaint uses the standard teensy library https://github.com/PaulStoffregen/XPT2046_Touchscreen to process the presses.

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.

That is for each thing you want to send to the display, you typically send a 4 byte transfers. A few of these are to reset the display, some are commands and others are data. Example in a capture I did from starting up

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.

You will find that these devices (XPT2046) have a pin on them marked AUX, which on these display appear to be connected to a potential Resistor Divider made up of R1 and R2.

So if you send the byte E7 to the display with Touch CS asserted, it starts a AtoD conversion on that AUX pin, and transfer of two more zeros, will return you the AtoD value from AUX,

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

In addition, this library now has some of the API"s and functionality that has been requested in a pull request. In particular it now supports, the ability to set a clipping rectangle as well as setting an origin that is used with the drawing primitives. These new API"s include:

kedei 3.5 inch tft lcd display spi with touch screen free sample

... height with supports. ...This bracket will accommodate the Kedei 3.5" HDMI LCD screen, using kapakahi"s screw posts. The button wells from kapakahi"s original Thing will also fit. ...

Remix Raspberry Pi Display Case http://www.thingiverse.com/thing:1229473 For the KeDei 3.5" SPI TFTLCD 480x320 version 1.1 2015/8/11 Print Settings Printer Brand: RepRap Printer: reprap prusa i3 marlin Rafts: Doesn"t Matter Supports: No Resolution:...

So I ordered the OSOYOO 3.5" TFT display from Amazon (also seen it for sale as a KeDei display which is what is actually printed on the OSOYOO I received from Amazon), and I wanted a simple case for it that would hold & display it nicely with all...

... stl orientation- screen.stl should be printed downwards. -So the supports go on top of the mounting screws. Screen has some freedom of movement on the back of the pi, just dab som hotglue to the edge of the kedei-pcb and have a good time! ...

I love the case made by 0110-M-P and I couldn"t find a good case for cheap 3.5 kedei LCD so I made a top for 0110-M-P base. I"m using this with my octoprint and touch UI.

My touchscreen (KeDei (ebay)) was a bit higher to fit the original case so I made the display-slot slightly taller for the case and cap. ...Works with the following Raspberry Pi Models:

A Gameboy Zero Helper for the Kedei 3,5 " Display Space for micro usb break out, usb and volume wheel the top adds more useable space into your build print solid and drill the holes by your self

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...

I have the KEDEI 3.5" 128M SPI TFT screen, and had to modify it slightly: "extending the connector with wires", which gives the opportunity to add some more things like better power connection or i2c RTC. I made the case for the screen to cover the...

... On an ugly reprap display I also deliberately omitted, since I use octoprint touch (with a osoyoo / kedei 3.5 "HDMI touch TFT https://amzn.to/2IivrUA). ...

kedei 3.5 inch tft lcd display spi with touch screen free sample

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...

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 tft lcd display spi with touch screen free sample

I am trying to set up a Kedei Raspberry Pi Display version 1.1 2017/10/10 Type 3590 (horizontal 800*480px) with my Pi 4. Unfortunately, I didn"t manage to get the Touch Screen running on SPI. The HDMI input works so far!

For now, I followed this tutorial (Sorry, its German, but its more or less a translation of the eBay seller"s tutorial). I also tried to download the "official" Kedei Driver (LCD_show_35hdmi_Horizontal).

kedei 3.5 inch tft lcd display spi with touch screen free sample

The problem is, that the producer claims this display is working only with their "special" version of Raspbian (they are providing an image). And there in almost zero documentation (the display came without any documentation).

However, Googling around I have found that some people were able to compile and install kernel drivers and it seems that some drivers are available from here: http://kedei.net/raspberry/raspberry.html

Now what happens... main HDMI screen cets coloured in four colors (red-yellow-blue-cyan), but SPI display started working. It shown four raspberry logos and a bunch of text, which ends with this line:

I also have one of these displays ("vision 1.0" ... damn they could not even spell version right in their first try), and I once tried the full image given by kedei ... it worked, but I was very sceptical, and finally I worked on some other projects.

If kedei is not giving any open source driver, then someone has to reverse-engineer the whole thing and write an open source driver on his/their own ...

That"s a very sensible approach - try and keep away from displays that need a custom OS in order to work. The tinylcd displays, at least the 3.5inch one anyway, have a fbtft overlay available by default in Raspbian - see for yourself in the /boot/overlays/ directory. You"ll still need to do other configurations, like console redirection, etc.

kedei 3.5 inch tft lcd display spi with touch screen free sample

Compatible and Direct-connect with any revision of Raspberry Pi. (If you are using a Raspberry Pi Zero / Zero 2 W, an additional HDMI cable is required.)

Raspberry Pi leads out 40 GPIO pins, while the screen leads out 26 pins. When connecting, pay attention to the corresponding pins and Raspberry Pi pins.

5) Insert the TF card into the Raspberry Pi, power on the Raspberry Pi, and wait for more than 10 seconds to display normally. But the touch is abnormal at that time, and the touch needs to be calibrated as the following steps.

3. After reboot, touch will work normally under normal circumstances. But for different resistance screens, the accuracy of using the default calibration parameters may not be very suitable.

You can perform touch calibration by clicking the Raspberry Pi icon on the taskbar, selecting Preferences -> Calibrate Touchscreen, and following the displayed prompts.

4. After calibration, the following data will be displayed. If you want to save these touch values, you can replace the data in the red circle with the data in the corresponding position in 99-calibration.conf.

The installation of xserver-xorg-input-evdev and xinput-calibrator in Ubuntu system reports an error, so the touch cannot be used normally. How to solve it?

The installation of xserver-xorg-input-evdev and xinput-calibrator in Kali system reports an error, so the touch cannot be used normally. How to solve it?

kedei 3.5 inch tft lcd display spi with touch screen free sample

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.

Finally got my whitescreen issue resolved with a loooong processes of a clean headless install of raspberian stretch and the drivers as outlined above. I have no monitor other than this screen. I now have an issue continuing with my project whose first step is to do an update and upgrade. This reverts me to the whitescreen issue again. Can I presume that every time I do an update I also then need to reinstall the driver? What else does the driver install overwrite?

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

this can make bigger sales $$$$ if the creator gives a driver that can solve the problem or show how to enable the HDMI for extended display or double display mode activated function.

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

this can make bigger sales if the creator gives a driver that can solve the problem or show how to enable the HDMI for extended display or double display mode activated function.

“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.

this is a bit annoying to change from "R-pi display to HDMI" or "HDMI to R-pi display", if you want to give a public presentation or if you make projects involving the HDMI connector at the same time using a extended display or cloned display or projecting video or images PNG.

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

this can make bigger sales if the creator gives a driver that can solve the problem or show how to enable the HDMI for extended display or double display mode activated function.

this is a bit annoying to change from “R-pi display to HDMI” or “HDMI to R-pi display”, if you want to give a public presentation or if you make projects involving the HDMI connector at the same time using a extended display or cloned display or projecting video or images PNG.

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

this can make bigger sales if the creator gives a driver that can solve the problem or show how to enable the HDMI for extended display or double display mode activated function.

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 tft lcd display spi with touch screen free sample

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.

Here my experiences with the screen: quite slow refresh, not too high contrast, crisp screen, touch works, software works but is already outdated, but considering the price this screen is well worth the money! If I compare it to the NeoSec screen it is a better deal for applications with a high contrast theme and no demand on smooth video.

So now for the test. On the sellers page an URL is placed to get the software, on a Google drive. Not a clickable url, but an image with a long filename to type over …. Oh well, I got the archive.

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.

Now the bad news: no word how these kernels were build. So we are stuck with wheezy for now until the Chinese supply a more current build, hopefully based upon jessie. Until then: be careful updating the system by holding back on kernel updates.

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 tft lcd display spi with touch screen free sample

ER-TFT035-6 is 320x480 dots 3.5" color tft lcd module display with ILI9488 controller,superior display quality,super wide viewing angle.As a bonus, this display has a optional resistive touch panel and a optional capacitive touch panel with controller FT6236, so you can detect finger presses anywhere on the screen and doesn"t require pressing down on the screen with a stylus and has nice glossy glass cover and easily controlled by MCU such as 8051, PIC, AVR, ARDUINO ARM and Raspberry PI.It can be used in any embedded systems,industrial device,security and hand-held equipment which requires display in high quality and colorful image.It supports 8080 8-bit,9-bit,16-bit, parallel,3-wire,4-wire serial spi interface. FPC with zif connector is easily to assemble or remove.Lanscape mode is also available.

Of course, we wouldn"t just leave you with a datasheet and a "good luck!".Here is the link for 3.5"TFT Touch Shield with Libraries, Examples.Schematic Diagram for Arduino Due,Mega 2560 and Uno . For 8051 microcontroller user,we prepared the detailed tutorial such as interfacing, demo code and development kit at the bottom of this page.

kedei 3.5 inch tft lcd display spi with touch screen free sample

Not a problem with the Rpi display. Put aside for now. Played a little more but think I have to figure out how those 595 are used, but that is something for another day. Should get my other breakout board tomorrow with the display adapter and TS buffer on board so think this week going to be some soldering.

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:

I have received notifications from Ebay that the two different displays I ordered (one like the one with shift registers) shipped. One is guaranteed by Friday, the other expected Saturday....

Yep. Not planning on doing any major surgery to any of the libraries to support the display but would be nice to get to figure out how it actually works and get it to display something.

Regarding the RPI display I found this that you might want to browse in your free time (haha): https://github.com/juj/fbcp-ili9341/issues/40 as well as this. Think this is one of those projects to do for curiosity rather than try and get implemented. Yes it is 3-wire but - T_CS and L_CS is interrelated can"d have one without the other.

I have this display, https://www.amazon.com/gp/product/B00SK6932C/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1, a 1.44in ST7735. Ran the graphics test and looks like the viewable area needs to be shifted to the right and down by a couple pixels like you mentioned. Also, I noticed when printing the large text it goes off the screen and will wrap - this is noticeable when you run the rotation.ino sketch.

@defragster - Yep I ordered another one like that on Ebay(https://www.ebay.com/itm/153515689082).. That ships from LA so should get here in next week or so: Again these are ones without CS pin..

I actually opened debug_tt - I need to see that working again on T_3.x and on T4 through USB at least. I"m going to go back to minimal and ignore the extended stuff I thought could work on USB - as you got that working with custom prints.

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.

I may redo some of these tab names and what they are... That is the INITR_144GREENTAB defined in the Adafruit library starts at 3,2... I probably update it a long time ago to what I have as my displays were all offset differently... So for my other displays, I should probably either:

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...

Think the display driver is the same but... You will need to implement 3-wire as well as toggling the Touch_CS pin as well to complete the transfer - that"s why I posted the code references.

And yep all you need is the one sendCommand, don"t really need the other one. I got my second 7735 display so I could check out if it fully works - also attached a photoresistor. Yes it worked across two displays - pretty cool actually. Having fun with it. Wish I could do a video to demonstrate but would see the T4 and can"t do that yet.

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... .

It was interesting to see in some of the things you posted about using with ESP32, that they actually modified the display and added on another chip...

Back on ST7735/89_t3 code - I changed the defaults for the 144GREEN... tab to be compatible with the Adafruit display, as I verified that was what was up in MASTER...

So I updated that, plus updated two of the example apps (graphictest and rotationtest) to these plus put in commented out changes to allow you to set the ROW, COL start numbers that work with my other displays.

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.

Yeah, saw what the did for the ESP32 - didn"t even go further until a few of the solutions shown that you could do it software. May go back to that now that I got uncanny eyes working. Have to see what happens if I start toggling the touch cs in conjunction with the writing data.

eye[e].display->sendCommand(ST7735_RAMWR, &nullp, 0); However doesn"t work correctly - part of the logo stays on the screen and instead of 1 big eye per screen I am see 2 eyes in this config - 1/2 eye, full eye, 1/2 eye.

- Right now I am trying to figure out why the UnCannyEyes sketch is wiping out my board... I was running it yesterday, but today when I build it and run it, it crashes... Then Windows gives me a message that there is not a valid USB device connected... Am hoping it was not my cleanup changes to the ST7735 code.... Or my Hardware connections to display. Verified not connection as I unplugged the processor from the breakout board (Paul"s). I edited the sketch to change Reset pin to 23 and the 2nd display to 14 (also tried 21), as these are in the RX/TX pins that Paul routed...

"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\\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"

"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++

Actually it is crashing on T3B2 (older one without jumper) - Tried on different one with jumper and it appears to run... At least I am getting debug info... So will move tests over to different board!

@KurtE - just to add to confusion I just tested the sketch on T4B2(no wire) and the sketch ran without issue - logo and eye displayed fine. I actually have been using T4B2(wire on top).

If something crashes on the latest T4 beta hardware, please post a detailed report on the T4 beta thread. I believe I do have a couple of those ILI9488 displays sitting around somewhere...

It seems @mjs513 was getting failures in - that is tough to trap - Serial4 can be online before setup() - but USB after. And if it is in the area of " //[B]printf("before C++ constructors\n"); " - using code with data and arrays or .begin setup - would be stuck too.

Paul asked about adding hook()"s - maybe a new one once? But assume no C code is live until after "constructors"? And it would be mute for such early failures except maybe through Serial# with bitbang/PJRC out code.

Probably something there worth investigating/understanding with mem segment copy or init causing a reset during startup()? I wonder if the same code has problems on T_3.6? Probably not given it may not repro on all T4"s?

If something crashes on the latest T4 beta hardware, please post a detailed report on the T4 beta thread. I believe I do have a couple of those ILI9488 displays sitting around somewhere...

I noted my T3B2 confusion too - and by "without" JUMPER is that the "white wire"? Without white wire - or Newer Rev #21 final PCB - it could be a Serial# UART power issue affecting boot.

If something crashes on the latest T4 beta hardware, please post a detailed report on the T4 beta thread. I believe I do have a couple of those ILI9488 displays sitting around somewhere...

@KurtE - no displays but I put the 7X Serial# breakout ( 14 pins at 3+V ) on the T4B4 - both white wire Mod - and it showed no issues - as posted on T4 thread with the eyes sketch and it didn"t have any issue - so it doesn"t seem to be brownout related.

@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...

@mjs513 and ... With that RPI display, as I mentioned, I think I will try to setup an RPI to be able to at least use this display... and then try to capture the signals in Logic Analyzer.

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.

In that crazy sketch I posted, you got the cmd and data bytes right. CMD = 0x11 and DAT = 0x15. Here is the little snippet of code I was playing with - not sure if ts select stuff is right was just playing that was why I was asking about what the Touch was doing:

I did a new logic capture with shorter amount of data... This one I compressed into a zip file of only about 27mb. It captures the startup until I see the first Raspberry Pi Logo...

If interested I might be able to post and/or email the captured run... I capture all 6 data pins plugged into the display(Int, Touch_CS, display_cs, Mosi, Miso, SCLK).

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...

Got the file and sorting through it now - interesting so far. Need to confirm whats on Channels 0 and 1: Channel 0 = INT?IRQ? and channel 1 = Touch CS.

Right now it looks like it toggles T_CS right before it does a Display_CS. and sends the data. Ok so I am getting an idea. Now to figure out what the initialization is to see what Chip it is - think its a 9486

I am not sure yet how bad I screwed it up for running on the ST7735 displays... I tried to change it to remove including the main library header in main file, and have it such that you uncomment the one you wish to use in config.h... But with the hack I had to allow two displays to be initialized differently I moved the eye definitions down below the includes...

Been looking at the Logic Analyzer dump and can"t for the life of figure out what display controller its using. Doesn"t seem to match anything I"ve seen for this display - argh. First 8bytes should be controlling the first 595 chip and then next 16 bytes should be the data to be sent? Since its in groups of 4bytes is that equivalent to a 32bit transfer? Also seems to sending the last transfer continuously until the next change, for instance I saw about 20 transfers of 0x00,0x15,0x00,0x00 before the next packet sent.

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

Yeah - the LA results are confusing - pretty much did the same as you except looking at the data on the screen and saw the same thing. The one thing I found that exactly matches the our display is here: https://github.com/juj/fbcp-ili9341/issues/40, but the initialization sequence seems to be different. Was just going to and follow that initialization sequence - but they seem to indicate its a MPI3501 which I can"t find any spec sheet on - others seem to think it may be a 9486 - oh well.

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

@mjs513 - Hopefully your screen is not damaged so you can play :D I do see the Touch CS pin being manipulated after each write of 4 bytes... My guess is it is tied to the shift registers or the like and tells it to update the output bits... I am seeing in the earlier capture about 90 nano-seconds, so the Delay 1us is still maybe 10 times more than it needs.

Wonder what would happen if you got rid of the delay all together if it would still work. Where did you get your display from :) Think mine is dead.

I do believe it can be sped up some.. Things like not needing to set CS for each of these transfers... But still have wait for transfers to complete in order to change touch cs state...

Yikes - nice 60 MHz works but only dropping to 298 to 250 ms sounds like some ugly overhead involved. Not following close enough to know what display this is without reading prior page - but whatever it is sounds like it is good to be working.

Real question is, Do we really want to do anything with these? If I had purchased 100 of these and had some product to sell, maybe worth the time, to make driver that works with them... Not sure anyone else has one? @defragster? Don"t think its worth the time to do a proper driver for it. There are better displays to work with than that one. One of the complaints was about the update speed - it stunk! as you found out. Think the only thing that I would do is just update the sketch to display a one of the pics from the GitHub page just for completeness. Maybe "textout" for curiosity but that"s about it. There is a lot of better things to spend time on.

For that many pixels it will be nice to have a high res display someday for monitoring barometer change - or maybe tides … maybe the phase of the moon … or paint drying :)

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.

Don"t think its worth the time to do a proper driver for it. There are better displays to work with than that one. One of the complaints was about the update speed - it stunk! as you found out. Think the only thing that I would do is just update the sketch to display a one of the pics from the GitHub page just for completeness. Maybe "textout" for curiosity but that"s about it. There is a lot of better things to spend time on.

I hacked up your hacked up sketch to only be one tab... Can still be a lot cleaner... But if you wish to take a look at current stuff with only one tab.

Still doing identical to the version you posted... But removing all of the queue stuff except some simple stuff. Got me to now about 180ms to draw screen.

Cool change - so changing to 32bit transfers actually helped. That"s quite a speed performance you got over what we started with the RPI display. I know, its now become a challenge. Really can"t do much with my display out of action until I get a new one. Can"t wait to give it a try.

I actually bought 2 of them to test with. I can get one working but not both but I am not sure if its a power problem or not. If I have both connected the screens just remain black. If I remove one from the breadboard the other will work. Have to do some more testing. Was a bit distracted today - putting together my new breakout board with the tri-state buffer. It works like a charm on the ILI9488, even works with the ILI9341 which doesn"t have a problem with being tri-stated. Had to stop for the day - was not doing well - think I need to start watching what I am eating.

FrankB did a PT8211 edit I tested and it got pulled today. I went ahead with proposed Startup__Hook()"s, very cool that (digital) I/O usable under 2 ms after clock starts - all else but Serial under 46 ms.

Mike - let me know if you look at TempMon again - I did a quick look and quit before getting anywhere. Also not seeing anything but 1[SRC_SRSR_IPP_RESET_B] reading from the "resetReasonHw = SRC_SRSR;" - am I using that right? Maybe the 1062 startup is always kicked off with reset by the bootloader MCU?

For the RPI display relatively easy hook - MOSI=11, L_CS=10, T_CS=6, CLK=13, Gnd=Ground, 5v=5v. No addition Libs necessary. Everything self contained.

I am still wondering about the schematics shown for this display. Some reason I think it is wrong.. Since the CS of touch is needed, I think that must be tied to the latch the data (one of the clock names)...

Not 100% sure about the schematics either. One that was for an earlier revision of the board and two it was reversed engineered - never could find anything official on the display which is always a concern.

Progress on the SSD1351 UncannyEyes. Turns out the primary problem with running 2 LED displays is power. I added a external supply to supply power to the OLEDs and got the eyes to display. But still have some problems.

I got an eye to display on each display individually. When I try to display on both I wind up with both the eyes displaying on last eye configured - weird effect though :). In other words in the case above both eyes will display on the OLED on C/S pin 5.

Like: There is no setRotation - Note: the way I had it setup the display was being used with single buffer mode (like useFrameBuffer in my stuff) so all of the drawPixel like calls are just setting value in memory... So probably would not be hard to update... Or maybe there already is a way...

Also there was some code that was used on 2nd eye to mirror stuff, by setting some values on the hardware. At the time there was no sendCommand like code. I added that code yesterday, to maybe allow that, but did not try it out... (Don"t have 2nd display so not sure again if it would work). At a minimum I believe if you enable it, not all of the constants (Operation codes) will be defined as they came from Adafruit, but should not be hard to just add those local to sketch...)

Wanted to let you know about the power issue using 2 OLEDs. Remember you told me about SendCommand yesterday :). There are so many ifdef"s in there to cover the different displays I didn"t even notice :). Was just happy about getting it working with the 2 displays attached. Will take a look - been doing errands today :)

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...

Oops - sorry I misunderstood thought you were referring to the other sendcommands - sorry my bad. Will have to download the latest copy. Only problem now I am running into is that that after a few frames the animation stops sometimes. Resetting it a couple of times seems to get it working fully. Will try with your latest version

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.

@mjs513 - Your LA dump looks screwy especially on the CS pins. As for wiring, I redid mine again today on T4 (my own breakout) this time with pins 10, 9

Just verified that our earlier test apps the colors were wrong as well, I updated the simple one to output the color it was going to output to the screen>

My first attempt to fix this was to play with the output of the MADCTL register 0x36, At least for the ili9351 and ili9488 one bit of this is supposed to control if RGB or BGR... At least that is how I read it?

And changed that setting. But no change on the display... Since this is a one off, probably never used display I might simply hack it the other way, And modify the constants for now and the function to generate color from R,G,B...

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...)

I think the Rotation stuff is wrong for X,Y and direction of bits.. Will play later. Included in github is updated touchpaint using the right touch controller. But, X, Y stuff still needs work!

@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.

I infected everything with the TempMon HIGH/LOW/PANIC - edited values shutting down for PANIC as it runs hotter driving display … and forgot I put in debug_tt for early tests and … opps … I have placed Temp_isr"s in there that were firing about 900K Hz … did the _isr off in _isr and then I started getting FAULT reported on IRQ #79 {"IRQ_GPIO1_INT7"} from that code I found and incorporated ??? Chasing that down shows how ugly and ill formed the debug_tt code is with one long source file and overloaded code ... Needs a ground up re-write.

I changed SublimeText to black on white from default colors - much more readable on larger hi-res screen with tiny font - but I have three copies open to diff folders as I jump from thing to thing ... and each copy has 9 or 18 or 24 random core/lib/sketch files open as I jump from Audio-displays-tempmon-debug_tt-USBHost- {...} - more distractions than focus.

@mjs513 - ST7735 - Maybe upload a copy of your exact one that is still causing USB issues.. I might even put in my actual Adafruit display to try it.

Added code to print out the text at X=0, y=height/2 (minus...) and you can see if I rotate the display such as the text is correct orientation, the black is at the top... Should be at bottom, so need to change settings for controlling some of this...

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.

In this case uncomment it. You don"t even need to have displays attached. To duplicate it though you can"t use your debug_tt. If you include it, it some how fixes the problem.

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.

In this case uncomment it. You don"t even need to have displays attached. To duplicate it though you can"t use your debug_tt. If you include it, it some how fixes the problem.

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:

but I haven"t lost usb except for this sketch in a very long time. Eigen threw it into the bootloader and even with debug_tt included still does it.

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!

This can be achieved by rendering subsequent frames on top of previous frames without erasing, and then erasing only those pixels that have changed.

(..and NEVER..NEVER, write pixels twice.. i.e. delete without thinking and redraw - this WILL flicker if there is a refresh in between - but OK, everybody knows that)

@Frank B - haven"t done 3d graphics since my college days and that was on Apollo computers, IBM360 and PDP11"s and of course TRS80 - yes I am old :) So with the T4 going to have some fun. Found a very simple Ray Tracing example with the usual test case of sphere"s that runs pretty much out of the box and takes about a sec to run using a ILI9341 using @KurtE ILI9341_t3n library:

@defragster - that looks exactly like my screen with the exception that touchscreen worked :) I don"t have to use the full constructor though to get it to work.

I just used the full constructor because it worked before - then I knew what the pins were … and they were explicit … to get working touch as posted I dropped those and except colors it works now.

I will try to play with it later. But maybe put a print out of the R, G, B colors passed in and a delay after so you can see if the colors look right...

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:

@mjs513 @defragster - Interesting. I am wondering if maybe the MADCTL values are incorrect for your display. This is the thing that controls things like change directions of bits and the like.

If so which value worked? So I might try that change on my display and hopefully it still works on mine... Oh wasn"t clear - none of them worked. Sorry.

I did break down and ordered another display just as a test - I screwed up that second one that I bought. Will get it Thursday. Don"t know if its worth spending more time on this one.

And was getting strange results when I tried to define your version of CL something like (~(CL(r, g, b))) or (CL(r,g,b)^0xffff) probably what the compiler did with it. Now I did it with variables, not sure if I just did it with constants yet... will try that next... But got different results if I stored the CL first into variable and then did the not operation or xor...

Or sort of a comment back to earlier posts. We could always maybe try to really properly understand the startup sequence that RPI does with these PO..

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:

Earlier which I did not save I had Sublime test regular expression search and replace. These are mostly groups of 4 bytes associated with each actual transfer:

Yes I know you will massage it but fair warning there are some blocks that don"t follow cmd/data blocks - I was doing that earlier. Then there are a whole bunch of repeated blocks with the same hex values. Its like it always repeating the last block sent until a new one is issued. This kinda of follows one of the drivers I saw. Got confusing :) Let me know when you are ready I will give you the link to fbct for the pi.

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:

The nerd that I am I tried to make it work without a lot of manual conversion. If do the delay etc and then do a mass copy and past of all 201K lines work load into the T4 - out of memory. To make it work you have to take all those dup lines and make them for loops I tried but just to get through 11K lines is took forever - don"t know if there is a shorter way.

Tried lining up what you have with what I was working on in my spreadsheet - a couple things didn"t line up but have to finish doing some chores around the house then I will get back to it.

Didn"t even look their - was busy checking the conversions. Any loaded it up with the correction and it ran but my colors are still off - screen is white raspberry is like an orange and leafs are a light pink. They are in the upper right corner of the display. Look like the screen colors are the same before we did the negate of the colors. Not sure what else you want to do with the lib you created.

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

2. Put it back on the Teensy - no good - screen white with colors as described in post 412. One thing I noticed was that on the teensy the screen was mirrored compared to the Pi.

It might have been busy with expanding file system? don"t think so was sitting for about 15 minutes or so - if I type on the keyboard I can see the keystrokes on the screen

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...

Then dumped out the startup sequence to file. I then mucked with it with sublime text, to change the 4 8 bit transfers per logical transfer into one 32 bit transfer:

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...….

kedei 3.5 inch tft lcd display spi with touch screen free sample

You Might Also Be Interested In