kedei 3.5 inch spi tft lcd for raspberry pi free sample
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.
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:
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...)
[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa01041 bcm2709.serial=0x2938b030 smsc95xx.macaddr=B8:27:EB:38:B0:30 bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[ 4.838806] input: MOSART Semi. Rapoo 2.4G Wireless Touch Desktop as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:24AE:1000.0001/input/input1
[ 4.902783] input: MOSART Semi. Rapoo 2.4G Wireless Touch Desktop as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:24AE:1000.0002/input/input2
- 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),
I successfully installed KeDei 3.5 inch 480x320 TFT LCD on a Raspberry Pi Zero with Raspbian Buster. It works nicely as text console, especially when I use lens to magnify the view. :-)
However, I want to use it for another purpose: I would like to keep the regular screen & console output at HDMI port and use the LCD as a special-purpose peripheral.
Is there any tutorial how to set up this kind of device (TFT LCD with SPI interface) either as a serial port, or some other kind of device that would allow it to be used by a single application for special prupose, such as control panel for some communication equipment?
... 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). ...
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 ).
Ok, so, before I was using a Raspberry Pi Zero. Now I switched to my Raspberry Pi 3B and it works great. Any idea on why it won’t work on the Zero? The pinout is the same, is it possible that one of my pins isn’t good?
Buenas tardes, yo tengo instalado raspbian en la Raspberry Pi 3 y la pantalla, el modelo que me pone por detrás es XPT2046, siguiendo el tutorial consigo que funcione la pantalla táctil pero no está calibrada.
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.
Hi Smat, Please install the version 4.9 raspbian firstly, and then install the suitable version driver according to the isntruction. Please don’t update raspbian directly, as the driver can’t update for this
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.
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.
“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.
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:
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.
@mjs513 - Thanks. I pushed up a slight change to for rotations 2/3 where if not offset... I tried to order one from Adafruit... But won"t ship to PMB, they suggested order from Digikey...
@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..
opps - didn"t see no CS - bad enough the driver chip is hit or miss - I saw the pin array and assumed all were there and never looked … and it shows right there in the pics ...
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.
Just to let you all I know I did finally get UncannyEyes working on the T4 - simple change to just use drawPixel :). Still have to hook up the bells and whistles (photoresistor, buttons etc).
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.
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... .
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...
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.
- 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\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/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/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)
Which version of UncannyEyes are you using - the one from Adafruit or the one that I posted. I had the same problem when I was initially running UncannyEyes from Adafruit. Made the changes that I posted and then the problem went away - think it may have been trying to get to an address the wasn"t available. I have seen that behavior before but not for a long time. Here is the version I am using:
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.
Paul. Not sure if you saw post #3493 (https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=209497&viewfull=1#post209497) where I caused fault using Eigen and it enters bootloader.
@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.
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...
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.
And Second about not sure what exactly device this is: Looking at the link you gave earlier: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=124961
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
Glad it was something stupid it on my part. Anyway as for the T_CS pin - you absolutely need it. Read that on several of the forums. This is the quote from the GitHub page that I got the code from:
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.
Unfortunately it sort of neuters the usage of the FIFO otherwise it might make sense to try using 32 bit writes from FIFO, but that would only gain sligthly...
@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.
Unfortunately it sort of neuters the usage of the FIFO otherwise it might make sense to try using 32 bit writes from FIFO, but that would only gain sligthly...
Guess what - T4 has a delayNanoseconds(uint32_t) function in the core - thought I remembered seeing this way back when: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194243&viewfull=1#post194243 - surprised I was able to find it:) - page 10 of 145 pages of the other thread
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.
Got the feeling it was that one missing proper control pins from recent posts - after posting I went one page back and didn"t see a link. This thread for 9488 has seen other traffic so wasn"t sure.
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.
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.
Have to tell you that cheap LA I got - while not a Salae - has come in handy to do some troubleshooting. Think at some point going to have to pick up a Salae - yes I saw your note on the hobbyist discount.:)
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?
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.
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.
@mjs513 - Which library are you using? Adafruit? Or the one I have been modifying? I assume the later... Remember there are pieces of the uncannyEyes that I had #ifdefed out in the case of this library as did not find easy way to do so in the other library...
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...
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.
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...
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.
On a different note - I attached a speaker directly to pin 8 and wanted to test the tone library and came across this updated library for RTTL: https://github.com/end2endzone/NonBlockingRTTTL. Works pretty good, you might want to check it out if you just want sounds, as for clips: https://www.redringtones.com/star-wars-ringtones/page/2/
@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
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.
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...
The good (or bad) news is it crashes my T4 as well... Will debug again tomorrow... But might again probably should put up on T4 thread for Paul to take a look at.
The good (or bad) news is it crashes my T4 as well... Will debug again tomorrow... But might again probably should put up on T4 thread for Paul to take a look at.
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.
from post >>uncannyEyes0.Zip (https://forum.pjrc.com/threads/55735-ILI9488_t3-Support-for-the-ILI9488-on-T3-x-and-beyond?p=210168&viewfull=1#post210168)
NOT NEEDED :: from post >>debug_tt.zip (https://forum.pjrc.com/threads/55735-ILI9488_t3-Support-for-the-ILI9488-on-T3-x-and-beyond?p=209654&viewfull=1#post209654)
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.
NOTE: it fails, then Button upload when debug_tt active in sketch by uncommenting or recommenting - when the local copy of "HardFault_HandlerC" comes or goes - just the change in config.h causes the code to recompile and that brings the failure back.
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:
Back when debug_tt was first noted as having an impact it seemed the only thing it added was alternate code resource for the CORES "weak" FaultHandler - my testing seems to indicate that as adding that locally to the unCannyEyes sketch was the same as including the debug_tt. Both a nearly empty version - or a FULL copy of the PJRC version.
There is something very odd here - but not just for mjs513 this time. Typing this I just thought I should pack up my BUILD dir for working and failing - the issue might be something that shows in the leftover build files. Wil go Add those to that post.
Back when debug_tt was first noted as having an impact it seemed the only thing it added was alternate code resource for the CORES "weak" FaultHandler - my testing seems to indicate that as adding that locally to the unCannyEyes sketch was the same as including the debug_tt. Both a nearly empty version - or a FULL copy of the PJRC version.
There is something very odd here - but not just for mjs513 this time. Typing this I just thought I should pack up my BUILD dir for working and failing - the issue might be something that shows in the leftover build files. Wil go Add those to that post.
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/
This can be achieved by rendering subsequent frames on top of previous frames without erasing, and then erasing only those pixels that have changed.
That"s exactly what I say (since many years.. :) ) - it looks a bit more "dynamic" if do it the other way: first delete the pixels that changed to "black", then overwrite all others. But best is, to do double-buffering, if possible.
(..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)
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.
Freaky … I turned it off to hit the uncannyEyes again on another T4 - then this T4 back on - the color bar NOW matches p#381 pic of MJS513 - including two greens in middle though FAR RIGHT (before last I see as WHITE) Dark Gray looks darker - though my leftmost YELLOW is more washed out.
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.
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...
Probably something stupid I am doing... The last three numbers on each line are the negated. First was done part of Serial.printf, just to make sure I was outputting correctly, 2nd one was output by itself using Serial.print(...,HEX);
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:
I was beginning to do that before you got the initial sketch that we started from working so I just left it at that. Don"t know if it worth it at this point to spend that much time going through the LA dump to figure out wants going on - but I know we will at some point :)
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.
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
Ok. What image did you use and how do you install it - or point me in the right direction - I do have a raspberry pi 3 sitting around I can test it on.
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...
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...….
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...
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 :)
Hi @mjs513 - The raw data of the last posting, came from the RPI Logic Analyzer save file that I sent you awhile ago in a zip file... It is all in the very beginning of the data.
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.
Looked like several of the same commands and results. The last two are different, with the last one actually being the first command shown in the other list, as both CS pins are low at that point, but then touch CS rises just after the output.
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:
Anyway on startup the raspberries show correctly with a black background. Which is the top of the screen - the color seems match for the box that is farthest from screens ribbon cable.
I think I mentioned that the new display wouldn"t work at all with the existing lib - screen stayed white. I changed the startup sequence to match what we have in the startup3 sketch, sans raspberries. So it works now but text is messed up - haven"t fixed that. Now I am tired - use rgb or bgr for color scheme in the .h file. Here is my modifications if you all want to test :)
Raspberries are sorta like that - greenish top and purpleish bottom. Didn"t power up a Pi or set it up to see how it should look. rPi"s didn"t see any PRIME DAY love so I skipped for now. Still don"t know where my old rPi is - I have two piZero"s right here …
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
As for the @KurtE"s latest startup sketch you should see 3 berries - yep - sort of green and top reddish/purplish on the bottom. I have two displays - both act a bit differently but the new startup seems to work on both now.
What I am seeing now is one display everything seems to work fine for graphicstest then on the other display its a mirror of the other - argh. I am using mode3 and mode1
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[] = {
As for Github - one thing I have never tried, and assume there is a way to do, if you receive a PR, You may want to have it logically merged, and then run tests on it, to verify that things are working correctly and then say yep it worked, and then accept the PR and have it reflected in the master branch for anyone who then does a sync...
Which looking at my board I believe it is pin 8 of the 2046 chip (one nearest the 4 pin connector) with +5v and it looks like that pin may be routed to R2 and maybe R1. On my board R2 is populated and R1 is not...
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.
Running Touch Paint has the color bar drawing opposite where it is tested for - and the short screen axis is swapped - long axis follows the pointer - short axis is flipped … like the color palette bar on the wrong side?
But the colors look to be perfect and unique - no doubled bars and good BLACK fillscreen with nice sharp color definition - no longer muted and over driven like before!
Running Touch Paint has the color bar drawing opposite where it is tested for - and the short screen axis is swapped - long axis follows the pointer - short axis is flipped … like the color palette bar on the wrong side?
But the colors look to be perfect and unique - no doubled bars and good BLACK fillscreen with nice sharp color definition - no longer muted and over driven like before!
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.
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.
Running Touch Paint has the color bar drawing opposite where it is tested for - and the short screen axis is swapped - long axis follows the pointer - short axis is flipped … like the color palette bar on the wrong side?
But the colors look to be perfect and unique - no doubled bars and good BLACK fillscreen with nice sharp color definition - no longer muted and over driven like before!
Ok. Now that I am awake think I figured out the problem. Make sure that the madctlRotationValues for R1 is uncommented and R2 ones is commented out. It should look like this:
The rotation array in the .cpp does that mapping for you - so don"t worry about it - just tried it on my display
Ms.Josey 
Ms.Josey