supported? 7 pins -> without CS pin? #178

ozett · 2020-12-16T12:30:05Z

hi,
i trying to get fbcp-ili9341 running. but no success.
instead this python code runs on the same wiring perfectly: https://github.com/solinnovay/Python_ST7789
seems to be a 7789 driver with the CS-Pin missin on my display. this python-lib works.

i tried all this without any reaction on the display.
maybe there is a foolproof way to get an image on the display while this fbcp-ili9341 is running?

root@raspberrypi:/usr/src/fbcp-ili9341/build# history | grep cmake
   36  sudo apt-get install cmake
   40  cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 ..
   41  cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=20 ..
  104  history | grep cmake
  134  history | grep cmake
  229  history | ggrep cmake
  230  history | grep cmake
  231  cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 ..
  233  cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  235  cmake -DST7735=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  236  cmake -DST7735R=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  237  cmake -DST7789VW=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  238  cmake -DST7789VW=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  239  cmake -DST7735R=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  241  cmake -DST7789VW=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  243  cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..
  245  history | grep cmake

this is my wiring. works with the python-example. but with same wiring not with the fbcp-ili9341.
i am on an old rasperry

cat /proc/device-tree/model
Raspberry Pi Model B Rev 2

appreciate any hint/help. thanks

The text was updated successfully, but these errors were encountered:

juj · 2020-12-16T13:32:57Z

One gotcha that has been reported with CMake is that when changing the controller type, one may need to manually delete the file CMakeCache.txt from the build directory (or delete the whole build directory).

Other things to try may be to test if the display is not compatible with

fbcp-ili9341/spi.cpp

Line 102 in 30b9738

#define UNLOCK_FAST_8_CLOCKS_SPI() (spi->dlen = 2)

by replacing that line with

#define UNLOCK_FAST_8_CLOCKS_SPI() ((void)0)

Apart from that, can't immediately think what might be the fault. May need to snoop the bus with a logic analyzer to figure the issue out. The ST7789 display I wrote the driver implementation against was this: https://www.adafruit.com/product/3787

ozett · 2020-12-16T14:59:24Z

thanks for your fast thoughts on this..
i am not that deep into hardware, so i was wondering if CS is needed. but i guess: not.
i will try your code change and see what happens.

as a nooby and as a general question: i dont get errors after starting the buildfile, what should i expect to see on the spi-display? my display stays black all the time...(not in python, there it is fine and working with same wiring)

i am connected via ssh, there is no hdmi or any other peripherial than the st7789 display.
i tried to start omxplayer and show an image. i also tried fbi and feh. always black display....
maybe there is a test option?

[as a sidenote: while the executable is running, i can start the python lib&script and get output on the display from the python script (a clock). shouldnt there be a confict for dual use? or is this ok? ]

root@raspberrypi:/usr/src/fbcp-ili9341/build# ./fbcp-ili9341
bcm_host_get_peripheral_address: 0x20000000, bcm_host_get_peripheral_size: 33554432, bcm_host_get_sdram_address: 0x40000000
BCM core speed: current: 250000000hz, max turbo: 250000000hz. SPI CDIV: 20, SPI max frequency: 12500000hz
Allocated DMA channel 7
Allocated DMA channel 1
Enabling DMA channels Tx:7 and Rx:1
DMA hardware register file is at ptr: 0xb4b04000, using DMA TX channel: 7 and DMA RX channel: 1
DMA hardware TX channel register file is at ptr: 0xb4b04700, DMA RX channel register file is at ptr: 0xb4b04100
Resetting DMA channels for use
DMA all set up
Initializing display
Resetting display at reset GPIO pin 25
InitSPI done
Relevant source display area size with overscan cropped away: 720x480.
Source GPU display is 720x480. Output SPI display is 240x240 with a drawable area of 240x240. Applying scaling factor horiz=0.33x & vert=0.33x, xOffset: 0, yOffset: 40, scaledWidth: 240, scaledHeight: 160
Creating dispmanX resource of size 240x160 (aspect ratio=1.500000).
GPU grab rectangle is offset x=0,y=0, size w=240xh=160, aspect ratio=1.500000
All initialized, now running main loop...

i am on latest raspian and kernel: Raspbian GNU/Linux 10

root@raspberrypi:/usr/src/fbcp-ili9341/build# uname -a
Linux raspberrypi 5.4.79+ #1373 Mon Nov 23 13:18:15 GMT 2020 armv6l GNU/Linux
root@raspberrypi:/usr/src/fbcp-ili9341/build#

juj · 2020-12-16T17:13:47Z

The idea of the CS (Chip Select) pin is to allow chaining multiple SPI devices onto the same data&clock bus, where the CS pins are used to select which of the connected devices the host wants to talk to at any given time. On many displays I have the CS pin can just be connected to ground to make them behave "always-on", but I do have one display that also needs to receive the CS pin high->low edge transitions in order to "wake up" to process any incoming commands. So the answer for "is CS pin needed?" is "it depends on the display".

Given that your display already works without a CS pin using the other library clearly shows that the CS pin is not needed for your particular display. When you don't provide the pin number for fbcp-ili9341, it will just ignore that and not use it when driving the display.

By default when you start up the display, you should see the default framebuffer 0 of the linux. If you are booting to command line mode, I believe the fb0 should be showing a text entry asking to log in to the Pi. If you run any graphical program, it should show that program instead.

Also given that you don't specify -DSTATISTICS=0 override to CMake, it means the driver should be showing a performance statistics overlay on the screen, so even if there is nothing showing up on the Pi linux framebuffer, the perf overlay should at least be getting displayed.

You can try uncommenting

fbcp-ili9341/gpu.cpp

Line 21 in 662e8db

// #define RANDOM_TEST_PATTERN

to force a test pattern to show up, but that should not be necessary, as the overlay should at least be shown.

[as a sidenote: while the executable is running, i can start the python lib&script and get output on the display from the python script (a clock). shouldnt there be a confict for dual use? or is this ok? ]

There will certainly be a conflict. If the python clock script does not hang on the display, then it means that fbcp-ili9341 was probably not actively printing out any bytes to the bus. There is an internal debug config

fbcp-ili9341/spi.cpp

Line 18 in 662e8db

// #define DEBUG_SPI_BUS_WRITES

that can be used to see what activity happens on the bus.

Hmm, looking at the pin wiring.. having trouble verifying the pins from that photo.. do you have the green reset pin connected to CE0 pin on the Pi? If so, try moving it to another general BCM? pin on the Pi that does not have a special function.

ozett · 2020-12-16T20:40:26Z

thanks for explanation.

i assue that the fcp-ili9341 is still not working well, even when the binary seem running without errors...
i may try tomorrow the debug or test-pattern.

i dont change any wiring and the python lib is working well on the same raspberry.

the reset cable is wired to gpio/bcm 25 = pin 22. i dont see any problems, but i can try a different pin/bcm

---addition:
yes, you spotted something on the image, rights where the pin-header is on the image. i used this from the web, looks wrong on the PCB side and the pin-header in this image. Myself jumpered all wires like the table on the left. the right side shows not my rasperry , i have an old B-Version, not a raspi 3.

ozett · 2020-12-16T20:55:34Z

i guess my raspberry is a model B, rev2.
following that, the gpip/BCM numbering started here.
i dont think the backlight is wrong, if your pin-numbering is GPIO/BCM. is it?

--> https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/the-gpio-connector

juj · 2020-12-17T05:39:04Z

Yes, the pin numbering that is used is the BCM pin names convention. The reason to avoid Pi’s CE0 line is that it is used by the Pi’s hardware SPI0 chip, so it may cause a conflict.

ozett · 2020-12-17T11:24:41Z

i think i never used CE0=BCM8=Pin24....
must be something else, hope to find time to test some more later...

my wiring...never changed it ( and as a countercheck same wiring running ok with the python lib) ->

juj · 2020-12-17T17:17:18Z

Great, yeah, that looks all correct as far as the wiring goes.

Unfortunately I am out of ideas on what would be wrong. Other things you could try is to uncomment

fbcp-ili9341/config.h

Line 111 in 662e8db

// #define UPDATE_FRAMES_WITHOUT_DIFFING

and then delete all the display initialization and reset related code in https://github.com/juj/fbcp-ili9341/blob/master/st7735r.cpp#L10 , and then see if fbcp-ili9341 is able to drive the display after first using the working python driver.

If it does, then it suggests that the initialization sequence in fbcp-ili9341 is not compatible with the display.

ozett · 2020-12-17T17:32:03Z

fortunately i bought a pack of 3 displays and have old rasperrys lying around...
i make a second hardware (same pins, but new colors in wiring, but both with latest kernel 5.x, which dropped fbtft_device, may that affect your code also) and test your suggestion. will report back ...

ozett · 2020-12-17T20:57:59Z

second system up and running, python lib ok, fbili9341 still black...
i will further test something of your suggestions ...

ozett · 2020-12-17T21:23:04Z

one option failed. weird.
-DST7789 compiled
-DST7735 failed
-DST7735R compiled

(sidenote: would be helpful to get textoutput for witch driver -DST the executable was once build, dont see it at the moment)

but tft still black.. will try more...

ozett · 2020-12-17T22:10:19Z

Unfortunately I am out of ideas on what would be wrong. Other things you could try is to uncomment

fbcp-ili9341/config.h

Line 111 in 662e8db

// #define UPDATE_FRAMES_WITHOUT_DIFFING

and then delete all the display initialization and reset related code
If it does, then it suggests that the initialization sequence in fbcp-ili9341 is not compatible with the display.

thats was it. something in the init is not right.
without init its now running --- all with your help ..... -> 💐
many, many thanks for your time and effort.. i see it blinking now, great.

tomorrow will be another day (to go further) ...

thx again for now, great help!

ozett · 2020-12-18T08:56:52Z

testing .. 😄

juj · 2020-12-18T10:02:09Z

Nice! You may be able to improve performance by reducing CDIV to a smaller value from 40. My ST7789 display was able to reach up to CDIV=4. (85MHz bus speed)

ozett · 2020-12-18T11:47:06Z

after some testing and reboots:

INIT:
i need init from the python lib....
maybe i need further help to find necessary init-sequence...
🙏

SPI on works:
i leave spi-on in config.txt for the python lib.
does not affect the fbcp-ili9341... works

Rotation:
/boot/config.txt:

dtparam=spi=on

gpu_mem=128
avoid_warnings=1
display_rotate=1

#hdmi_force_hotplug=1
#hdmi_cvt=240 240 30 3
#hdmi_group=2
#hdmi_mode=87
#hdmi_drive=2

the rotation brings distortion/scaling... any hint to get this right?

ozett · 2020-12-18T12:27:33Z

i read your instructions again and added:
/boot/config.txt

hdmi_group=2
hdmi_mode=87
hdmi_cvt=240 240 60 1 0 0 0
hdmi_force_hotplug=1

display_rotate=1

now this is correct.

(only left to figure out the init...)

ozett · 2020-12-18T12:40:14Z

python-lib starts the display with reset and init:

https://github.com/solinnovay/Python_ST7789/blob/master/ST7789/ST7789.py#L204

how to test and transfer this to fbcp-ili9341 ?

ozett · 2020-12-18T13:25:41Z

i am a horrible coder, just a general noob ... 🤡

seems that a possible init is already there (whats this If 0 ?):
https://github.com/juj/fbcp-ili9341/blob/master/st7735r.cpp#L107

how to set code and option for another init like the python one?
https://github.com/solinnovay/Python_ST7789/blob/master/ST7789/ST7789.py#L204

juj · 2020-12-19T11:14:08Z

#if 0 is https://stackoverflow.com/questions/2852913/what-exactly-does-an-if-0-endif-block-do .

Fbcp-ili9341 specifies the command-data sequences as strings on one line. The first character is the command byte, and the subsequent characters are the data bytes. E.g.

fbcp-ili9341/st7735r.cpp

Line 39 in 662e8db

SPI_TRANSFER(0x3A/*COLMOD: Pixel Format Set*/, 0x05/*16bpp*/);

is the same as

https://github.com/solinnovay/Python_ST7789/blob/9da7aecdfb81cc46e881fe15bd12d39e0aa42e95/ST7789/ST7789.py#L215-L216

ozett · 2020-12-19T12:05:48Z

ok,
thanks for link to explanation #if 0 -> commented out the C-Way. all right.

my display seems to need a sequence. i can fiddle in my code-files and report if it works.
but that my be not a professional way to get it into your codebase.

i will report success/fail and than you can see if you want to make this an -DST or --Option?

ozett · 2020-12-19T14:08:20Z

i tried to port only the hex-binary init-sequence from the python-lib to a place in the .cpp init (all at random place, i guess), but it did not work out yet.

dont know if the SPI must somehow initialized...
dont know if the python-send routine for the commands is different...

still trying to get it in order...

void InitST7735R()
{
// python lib does it like this:
//SPI_MODE = 0b11
//SPI_SPEED_HZ = 40000000
//disp = TFT.ST7789(spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE, max_speed_hz=SPI_SPEED_HZ),mode=SPI_MODE, rst=RST, dc=DC, led=LED)

// python lib init:
//# Initialize display.
//disp.begin()


// python lib init drives this:
//
//# Turn on the backlight LED
//self._gpio.setup(led, GPIO.OUT)
//self._gpio.setup(led, GPIO.HIGH)
//
//# Set SPI to mode 0, MSB first.
//
//spi.set_mode(mode)
//spi.set_bit_order(SPI.MSBFIRST)
//spi.set_clock_hz(SPI_CLOCK_HZ)


// testing TFT disply 7 pin without CS
//disp.begin() == disp.reset, disp.ini

// disp.reset
/*
"""Reset the display, if reset pin is connected."""
        if self._rst is not None:
            self._gpio.set_high(self._rst)
            time.sleep(0.100)
            self._gpio.set_low(self._rst)
            time.sleep(0.100)
            self._gpio.set_high(self._rst)
            time.sleep(0.100)
*/

  // If a Reset pin is defined, toggle it briefly high->low->high to enable the device. Some devices do not have a reset pin, in which case compile with GPIO_TFT_RESET_PIN left undefined.
#if defined(GPIO_TFT_RESET_PIN) && GPIO_TFT_RESET_PIN >= 0
  printf("Resetting display at reset GPIO pin %d\n", GPIO_TFT_RESET_PIN);
  SET_GPIO_MODE(GPIO_TFT_RESET_PIN, 1);
  SET_GPIO(GPIO_TFT_RESET_PIN);
  usleep(120 * 1000);
  CLEAR_GPIO(GPIO_TFT_RESET_PIN);
  usleep(120 * 1000);
  SET_GPIO(GPIO_TFT_RESET_PIN);
  usleep(120 * 1000);
#endif

// Do the initialization with a very low SPI bus speed, so that it will succeed even if the bus speed chosen by the user is too high.
spi->clk = 34;
__sync_synchronize();


    // TODO: ST7789 Python example 
    // disp.init:

    printf("sending pythonlib init..");

    usleep(10 * 1000);  // usleep is microseconds, should be python (fragment of seconds=miliseconds): time.sleep(0.010). right?
    SPI_TRANSFER(0x11);
    usleep(150 * 1000); // usleep is microseconds, should be python: time.sleep(0.150). right?  ?? is timing critial?
    
    SPI_TRANSFER(0x36, 0x00);
    SPI_TRANSFER(0x3A, 0x05);

    SPI_TRANSFER(0xB2, 0x0C, 0x0C);
    SPI_TRANSFER(0xB7, 0x35);
    SPI_TRANSFER(0xBB, 0x1A);
    
    SPI_TRANSFER(0xC0, 0x2C);
    SPI_TRANSFER(0xC2, 0x01);
    SPI_TRANSFER(0xC3, 0x0B);
    SPI_TRANSFER(0xC4, 0x20);
    SPI_TRANSFER(0xC6, 0x0F);
    
    SPI_TRANSFER(0xd0, 0xa4, 0xa1);
    
    SPI_TRANSFER(0x21);

    SPI_TRANSFER(0xe0, 0x00, 0x19, 0x1E, 0x0A, 0x09, 0x15, 0x3D, 0x44, 0x51, 0x12, 0x03, 0x00, 0x3F, 0x3F);
    SPI_TRANSFER(0x00, 0x18, 0x1E, 0x0A, 0x09, 0x25, 0x3F, 0x3f, 0x43, 0x52, 0x33, 0x03, 0x00, 0x3F, 0x3F);
    //SPI_TRANSFER(0x21);
    //SPI_TRANSFER(0x11);
    SPI_TRANSFER(0x29);
    usleep(100 * 1000);   // python: time.sleep(0.100) # 100 ms  // python ms=miliseconds--> "C"= ulseep microseconds * 1000 ??

    printf("sending pythonlib init end");

}

ozett · 2020-12-19T17:05:38Z

Still fails to init

tried to sort it with fiddling, but still only python init works.

made a fresh checkout
changed only your init-suggestions for st7735r.cpp (see image 1 )
cleared build-dir always with rm -r *
compiled always with cmake -DST7789=ON -DSTATISTICS=0 -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSPI_BUS_CLOCK_DIVISOR=20 -DUSE_DMA_TRANSFERS=OFF ..

😢 fail: fbcp-ili9341 works only after previous init with the python-lib.
🔈 (it fails, if i do the init again. i can end and start fcbp-ili9341 executable without error and its working, but all stops if i do the python-init again)

Question of a NOOB:

Differences in python? --> see image2

maybe the python-lib sends mode 3 for success (whats this mode? needed?) ?
maybe the python-lib sends bit_order for success (how to do this?) ?

How do i test further to get the right init commands copied over from the python-lib?
any clue? thanks for every hint....
i am out of luck for today...

IMAGE 1:
https://github.com/juj/fbcp-ili9341/blob/master/st7735r.cpp#L10

IMAGE2:
https://github.com/solinnovay/Python_ST7789/blob/master/ST7789/ST7789.py#L164

ozett · 2020-12-19T17:32:19Z

Huuu, whats this?
May the Fork has dark Powers?

[edit: NO, i tried it, but screen stays black with my tft... 😢 ]

ozett · 2020-12-19T20:01:14Z

no initialize with fbcp-ili9341

i tried your first suggestion without success. 😢

i tried the change from the fork without success. 😢

👍 running fbcp-ili9341 after the python init works alltimes fine.
than the display shows always framebuffer content.

😕 my last clue is that is something with 1) spi-mode. 2) spi_clock/timing or 3) DC-settings while commands.
dont know how to test this....

this is the transfered cmd-sequence from the python-lib, but still does not init standalone...

void InitST7735R()
{

BEGIN_SPI_COMMUNICATION();

// disp.init (python-lib):
printf("sending pythonlib init..");

//not from python, worth a try. seems to brake something
//SPI_TRANSFER(0x01/*Software Reset*/);  // needed?

usleep(10 * 1000);  // usleep is microseconds, should be python (fragment of seconds=miliseconds): time.sleep(0.010). right?
SPI_TRANSFER(0x11);  //SPI_TRANSFER(0x11/*Sleep Out*/)
usleep(150 * 1000); // usleep is microseconds, should be python: time.sleep(0.150). right?  ?? is timing critial?

//SPI_TRANSFER(0x13/*NORON: Partial off (normal)*/);
//SPI_TRANSFER(0x26/*Gamma Curve Select*/, 0x04/*Gamma curve 3 (2.5x if GS=1, 2.2x otherwise)*/);

SPI_TRANSFER(0x36, 0x00);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);
//SPI_TRANSFER(0x37/*VSCSAD: Vertical Scroll Start Address of RAM*/, 0, 320 - DISPLAY_WIDTH);
SPI_TRANSFER(0x3A, 0x05);  //SPI_TRANSFER(0x3A/*COLMOD: Pixel Format Set*/, 0x05/*16bpp*/);

SPI_TRANSFER(0xB2, 0x0C, 0x0C);
SPI_TRANSFER(0xB7, 0x35);   
//SPI_TRANSFER(0xBA/*DGMEN: Enable Gamma*/, 0x04);
SPI_TRANSFER(0xBB, 0x1A);

SPI_TRANSFER(0xC0, 0x2C);
SPI_TRANSFER(0xC2, 0x01);
SPI_TRANSFER(0xC3, 0x0B);
SPI_TRANSFER(0xC4, 0x20);
SPI_TRANSFER(0xC6, 0x0F);

SPI_TRANSFER(0xd0, 0xa4, 0xa1);

SPI_TRANSFER(0x21);  //SPI_TRANSFER(0x21/*Display Inversion On*/);

SPI_TRANSFER(0xe0, 0x00, 0x19, 0x1E, 0x0A, 0x09, 0x15, 0x3D, 0x44, 0x51, 0x12, 0x03, 0x00, 0x3F, 0x3F);
SPI_TRANSFER(0x00, 0x18, 0x1E, 0x0A, 0x09, 0x25, 0x3F, 0x3f, 0x43, 0x52, 0x33, 0x03, 0x00, 0x3F, 0x3F);
//SPI_TRANSFER(0x21);
//SPI_TRANSFER(0x11);
SPI_TRANSFER(0x29);
usleep(100 * 1000);   // python: time.sleep(0.100) # 100 ms  // python ms=miliseconds--> "C"= ulseep microseconds * 1000 ??

printf("sending pythonlib init end");




#if defined(GPIO_TFT_BACKLIGHT) && defined(BACKLIGHT_CONTROL)
    printf("Setting TFT backlight on at pin %d\n", GPIO_TFT_BACKLIGHT);
    SET_GPIO_MODE(GPIO_TFT_BACKLIGHT, 0x01); // Set backlight pin to digital 0/1 output mode (0x01) in case it had been PWM controlled
    SET_GPIO(GPIO_TFT_BACKLIGHT); // And turn the backlight on.
#endif
 
ClearScreen();
 
#ifndef USE_DMA_TRANSFERS // For DMA transfers, keep SPI CS & TA active.
  END_SPI_COMMUNICATION();
#endif
}

ozett · 2020-12-19T20:30:34Z

digged the internet, another fork seems again to have patches for my display...
(but i am to dull how to make this working.)

so i googled and found, that my display needs SPI mode 3 !!!!!!
how to set SPI mode to 3? here on arduino

ozett · 2020-12-19T20:54:14Z

thats the end of my google wisdom.
and the end for today.

i dont see how to set mode 3 like this on SPI in your code....

juj · 2020-12-19T22:32:58Z

Interesting find, that might be the reason. To configure SPI mode 3, you can add

#define DISPLAY_SPI_DRIVE_SETTINGS (1 | BCM2835_SPI0_CS_CPOL | BCM2835_SPI0_CS_CPHA)

in e.g. after line

fbcp-ili9341/st7735r.h

Line 16 in 662e8db

#define DISPLAY_WRITE_PIXELS 0x2C

Or alternatively replace this line:

fbcp-ili9341/display.h

Line 83 in 662e8db

#define DISPLAY_SPI_DRIVE_SETTINGS (0)

ozett · 2020-12-20T10:15:03Z

you shed a light of hope...i will try... thx

ozett · 2020-12-20T13:33:30Z

😿 sadly that all does not help to init the display.

if i configure SPImode=3 like suggestest, stopping the fbi-ili9341 executable breaks the display showing up again with the ext start.

if i compile without #define DISPLAY_SPI_DRIVE_SETTINGS (1 | BCM2835_SPI0_CS_CPOL | BCM2835_SPI0_CS_CPHA)i can start and stop the fbi... executable and the display always shows the frambuffer content.

STILL 😢 i do have to init the display with the python code first, to show anything on fb.

as a noob, i am now out of ideas to test (speed/SPI-speed/ clock, order of init-cmds?...dont know..

ozett · 2020-12-20T14:39:46Z

SCK line must be driven high ?

as it does not work with code for SPImode=3, do this all need more code change?

its above my understanding of SPI, but may you get a clue for something i can test?

more on this here, very interesting:
Bodmer/TFT_eSPI#163 (comment)
A gotcha... The ST7789 is unusual, it is operated in SPI Mode 3, so the SCK line must be driven high when you do not wish to communicate with the TFT, otherwise an extra clock pulse will be introduced and that will mess up the next command.

maybe the spi-cmds on init fails, for this reason?

if is not working for missing CS (who knows?), some crazy guy broke this out.
it my type of display...

https://www.instructables.com/Adding-CS-Pin-to-13-LCD/

ozett · 2020-12-20T15:35:01Z

still deperate looking or a solution with my limit knowledge,

i compared the adafruit init with the python init for the st7789 and found differences in cmd for resolution (0x55 vs 0x05)
and i dont know how to transfer cmds for dimension to syntax of "SPI_TRANSFERS" ....

(sidenote: my fragment of the adafruit init did not resolve the problem)

juj · 2020-12-20T17:17:23Z

A gotcha... The ST7789 is unusual, it is operated in SPI Mode 3, so the SCK line must be driven high when you do not wish to communicate with the TFT, otherwise an extra clock pulse will be introduced and that will mess up the next command.

maybe the spi-cmds on init fails, for this reason?

That is what Mode 3 means. Having BCM2835_SPI0_CS_CPOL present in DISPLAY_SPI_DRIVE_SETTINGS is what flips the Serial CLock signal line to be driven high when communicating with the display.

if is not working for missing CS (who knows?), some crazy guy broke this out.

The fact that the display works with any driver at all definitely means that the display does not need a Chip Select line. Lacking a CS line will just mean that you cannot connect a second SPI display or other device, like touch controller, on the same line.

i compared the adafruit init with the python init for the st7789 and found differences in cmd for resolution (0x55 vs 0x05)

Both 0x05 and 0x55 should result in the same 16-bit 64KB color format for SPI displays. Iiuc the high nybble is only in effect when using the RGB color mode of the interface. According to the data sheet:

No harm to pass 0x55 there though to reduce a source of differences.

The CASET and RASET commands are not part of the initialization sequence. They are sent hundreds of times per frame at display runtime when uploading pixel commands. If you did not do any other modifications to fbcp-ili9341 except to remove all the init code when you got it working, then it means that fbcp-ili9341 is successfully sending the CASET and RASET messages to the display to upload pixels.

ozett · 2020-12-20T19:30:49Z

now confued using google: i found a different init-sequence:

https://www.newhavendisplay.com/app_notes/2-4TFT_ST7789.txt

i crosschecked some slight differenences, but my python-init still works.
at the moment i will stick with it, because i dont know the starting cause and if (only) changing the init will help...

for reference:

void TFT_24_7789_Init(void)
{
int n;
GPIO_ResetBits(GPIOC, CS1);
GPIO_SetBits(GPIOC, nRD);
GPIO_ResetBits(GPIOC, nWR);
GPIO_WriteBit(GPIOC, RES, Bit_RESET);
TFT_delay(100);
GPIO_WriteBit(GPIOC, RES, Bit_SET);
TFT_delay(100);
TFT_24_7789_Write_Command(0x0011);//exit SLEEP mode
TFT_delay(100);

TFT_24_7789_Write_Command(0x0036);TFT_24_7789_Write_Data(0x0080);//MADCTL: memory data access control
TFT_24_7789_Write_Command(0x003A);TFT_24_7789_Write_Data(0x0066);//COLMOD: Interface Pixel format *** I use 262K-colors in 18bit/pixel format when using 8-bit interface to allow 3-bytes per pixel
//TFT_24_7789_Write_Command(0x003A);TFT_24_7789_Write_Data(0x0055);//COLMOD: Interface Pixel format  *** I use 65K-colors in 16bit/pixel (5-6-5) format when using 16-bit interface to allow 1-byte per pixel
TFT_24_7789_Write_Command(0x00B2);TFT_24_7789_Write_Data(0x000C);TFT_24_7789_Write_Data(0x0C);TFT_24_7789_Write_Data(0x00);TFT_24_7789_Write_Data(0x33);TFT_24_7789_Write_Data(0x33);//PORCTRK: Porch setting
TFT_24_7789_Write_Command(0x00B7);TFT_24_7789_Write_Data(0x0035);//GCTRL: Gate Control
TFT_24_7789_Write_Command(0x00BB);TFT_24_7789_Write_Data(0x002B);//VCOMS: VCOM setting
TFT_24_7789_Write_Command(0x00C0);TFT_24_7789_Write_Data(0x002C);//LCMCTRL: LCM Control
TFT_24_7789_Write_Command(0x00C2);TFT_24_7789_Write_Data(0x0001);TFT_24_7789_Write_Data(0xFF);//VDVVRHEN: VDV and VRH Command Enable
TFT_24_7789_Write_Command(0x00C3);TFT_24_7789_Write_Data(0x0011);//VRHS: VRH Set
TFT_24_7789_Write_Command(0x00C4);TFT_24_7789_Write_Data(0x0020);//VDVS: VDV Set
TFT_24_7789_Write_Command(0x00C6);TFT_24_7789_Write_Data(0x000F);//FRCTRL2: Frame Rate control in normal mode
TFT_24_7789_Write_Command(0x00D0);TFT_24_7789_Write_Data(0x00A4);TFT_24_7789_Write_Data(0xA1);//PWCTRL1: Power Control 1
TFT_24_7789_Write_Command(0x00E0);TFT_24_7789_Write_Data(0x00D0);
								  TFT_24_7789_Write_Data(0x0000);
								  TFT_24_7789_Write_Data(0x0005);
								  TFT_24_7789_Write_Data(0x000E);
								  TFT_24_7789_Write_Data(0x0015);
								  TFT_24_7789_Write_Data(0x000D);
								  TFT_24_7789_Write_Data(0x0037);
								  TFT_24_7789_Write_Data(0x0043);
								  TFT_24_7789_Write_Data(0x0047);
								  TFT_24_7789_Write_Data(0x0009);
								  TFT_24_7789_Write_Data(0x0015);
								  TFT_24_7789_Write_Data(0x0012);
								  TFT_24_7789_Write_Data(0x0016);
								  TFT_24_7789_Write_Data(0x0019);//PVGAMCTRL: Positive Voltage Gamma control	
TFT_24_7789_Write_Command(0x00E1);TFT_24_7789_Write_Data(0x00D0);
								  TFT_24_7789_Write_Data(0x0000);
								  TFT_24_7789_Write_Data(0x0005);
								  TFT_24_7789_Write_Data(0x000D);
								  TFT_24_7789_Write_Data(0x000C);
								  TFT_24_7789_Write_Data(0x0006);
								  TFT_24_7789_Write_Data(0x002D);
								  TFT_24_7789_Write_Data(0x0044);
								  TFT_24_7789_Write_Data(0x0040);
								  TFT_24_7789_Write_Data(0x000E);
								  TFT_24_7789_Write_Data(0x001C);
								  TFT_24_7789_Write_Data(0x0018);
								  TFT_24_7789_Write_Data(0x0016);
								  TFT_24_7789_Write_Data(0x0019);//NVGAMCTRL: Negative Voltage Gamma control
TFT_24_7789_Write_Command(0x002A);TFT_24_7789_Write_Data(0x0000);TFT_24_7789_Write_Data(0x0000);TFT_24_7789_Write_Data(0x0000);TFT_24_7789_Write_Data(0x00EF);//X address set
TFT_24_7789_Write_Command(0x002B);TFT_24_7789_Write_Data(0x0000);TFT_24_7789_Write_Data(0x0000);TFT_24_7789_Write_Data(0x0001);TFT_24_7789_Write_Data(0x003F);//Y address set

TFT_delay(10);
}

ozett · 2020-12-20T19:44:00Z

uhh sorry, i did not notice your posting... thanks for still giving me some feedback

If you did not do any other modifications to fbcp-ili9341 except to remove all the init code when you got it working, then it means that fbcp-ili9341 is successfully sending the CASET and RASET messages to the display to upload pixels.

yes, i am only fiddling with the init code in fbcp-ili9341 st7735r.cpp....but nothing helps.
after a reboot i still first need to run the python code , after that i can start tie fbcp-i..executable and the display shows up.

my goal was to only run the compiled fbcp...executable to show the framebuffer on the tft.
up to now: no luck.

but i can reproduce the sequence with python and the compiled executable to get working tft-display.

i am bit lost in space, and still think hopefully only the init-sequence in st7735r.cpp must be tewaked?

ozett · 2020-12-20T19:48:22Z

thats what i have at the minute:

void InitST7735R()
{

BEGIN_SPI_COMMUNICATION();

#if 0
printf("start adafruitlib init..\n");

// sequence from adafruit lib: https://github.com/adafruit/Adafruit-ST7735-Library/blob/master/Adafruit_ST7789.cpp
// 9 cmds:
SPI_TRANSFER(0x01/*Software Reset*/);  // needed?
usleep(150 * 1000); 
SPI_TRANSFER(0x11);  //SPI_TRANSFER(0x11/*Sleep Out*/)
usleep(10 * 1000); 
SPI_TRANSFER(0x3A, 0x55);  //SPI_TRANSFER(0x3A/*COLMOD: Pixel Format Set*/, 0x05/*16bpp*/);   on python 0x05, on dafruit 0x55!!
usleep(10 * 1000); 
SPI_TRANSFER(0x36, 0x08);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);  on python: 0x00
//SPI_TRANSFER(0x2A, 0x00,0,0,240);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);  on python: 0x00
//SPI_TRANSFER(0x2B, 0x00,0,320>>8,320&0xFF);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);  on python: 0x00
SPI_TRANSFER(0x21);  //SPI_TRANSFER(0x21/*Display Inversion On*/);
usleep(10 * 1000); 
SPI_TRANSFER(0x13/*NORON: Partial off (normal)*/);
usleep(10 * 1000); 
SPI_TRANSFER(0x29);
usleep(10 * 1000); 

printf("end  adafruitlib init..\n");
#endif


// disp.init (python-lib):
printf("start pythonlib init..\n");

//not from python, worth a try. seems to brake something

//SPI_TRANSFER(0xFD/Set Command Lock/, 0x12); 
//SPI_TRANSFER(0xFD/Set Command Lock/, 0xB1); 

//SPI_TRANSFER(0x01/*Software Reset*/);  // needed?

usleep(10 * 1000);  // usleep is microseconds, should be python (fragment of seconds=miliseconds): time.sleep(0.010). right?
SPI_TRANSFER(0x11);  //SPI_TRANSFER(0x11/*Sleep Out*/)
usleep(150 * 1000); // usleep is microseconds, should be python: time.sleep(0.150). right?  ?? is timing critial?

//SPI_TRANSFER(0x13/*NORON: Partial off (normal)*/);
//SPI_TRANSFER(0x26/*Gamma Curve Select*/, 0x04/*Gamma curve 3 (2.5x if GS=1, 2.2x otherwise)*/);

SPI_TRANSFER(0x36, 0x00);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);
//SPI_TRANSFER(0x37/*VSCSAD: Vertical Scroll Start Address of RAM*/, 0, 320 - DISPLAY_WIDTH);
SPI_TRANSFER(0x3A, 0x05);  //SPI_TRANSFER(0x3A/*COLMOD: Pixel Format Set*/, 0x05/*16bpp*/);


//SAM SPI_TRANSFER(0xA0/*Set Remap*/, 0x34/*0x04=BGR<->RGB Swap | 0x10=Vertical swap | 0x20=Enable COM split odd even (this makes pixel addressing sane as one'd expect)*/);
//SPI_TRANSFER(0xA0/*Set Remap*/, 0x74/*0x04=BGR<->RGB Swap | 0x10=Vertical swap | 0x20=Enable COM split odd even (this makes pixel addressing sane as one'd expect)*/);

//SPI_TRANSFER(0xA1/*Set Display Start Line*/, 0);
//SPI_TRANSFER(0xA1/*Set Display Start Line*/, 128);

//SPI_TRANSFER(0xA2/*Set Display Offset*/, 0);
//SPI_TRANSFER(0xAB/*Set Function Select*/, 0x01/*16bpp colors*/);
//SPI_TRANSFER(0xB5/*Set GPIO0 and GPIO1 pin*/, 0);

//SPI_TRANSFER(0xAE/Sleep Mode On (Display OFF)/);

SPI_TRANSFER(0xB2, 0x0C, 0x0C); //PORCTRK: Porch setting
//SPI_TRANSFER(0xB3/*Set Front Clock Divider/Oscillator Frequency*/, 0xF1/*Divide Ratio=1, Oscillator Frequency=0xF*/); // This controls frame rate -> set to fastest
SPI_TRANSFER(0xB7, 0x35);   //GCTRL: Gate Control
//SPI_TRANSFER(0xBA/*DGMEN: Enable Gamma*/, 0x04);
SPI_TRANSFER(0xBB, 0x1A); //data(0x002B);//VCOMS: VCOM setting

SPI_TRANSFER(0xC0, 0x2C); //LCMCTRL: LCM Control
SPI_TRANSFER(0xC2, 0x01); // 00C2);TFT_24_7789_Write_Data(0x0001);TFT_24_7789_Write_Data(0xFF) //VDVVRHEN: VDV and VRH Command Enable
SPI_TRANSFER(0xC3, 0x0B);  //_Data(0x0011);//VRHS: VRH Set
SPI_TRANSFER(0xC4, 0x20);//VDVS: VDV Set
SPI_TRANSFER(0xC6, 0x0F); //FRCTRL2: Frame Rate control in normal mode

//SAM SPI_TRANSFER(0xCA/*Set Multiplex Ratio*/, 95); // This effectively sets the pixel height of the display, set this to 127 for 128x128 OLED, and to 95 for 128x96 OLED. It looks like even the 128x96 OLED has 128x128 bytes worth of internal memory (for hardware scrolling?)
//SPI_TRANSFER(0xCA/*Set Multiplex Ratio*/, 127); // This effectively sets the pixel height of the display, set this to 127 for 128x128 OLED, and to 95 for 128x96 OLED. It looks like even the 128x96 OLED has 128x128 bytes worth of internal memory (for hardware scrolling?)


SPI_TRANSFER(0xD0, 0xa4, 0xa1); ;//PWCTRL1: Power Control 1

SPI_TRANSFER(0x21);  //SPI_TRANSFER(0x21/*Display Inversion On*/);

SPI_TRANSFER(0xE0, 0x00, 0x19, 0x1E, 0x0A, 0x09, 0x15, 0x3D, 0x44, 0x51, 0x12, 0x03, 0x00, 0x3F, 0x3F);
SPI_TRANSFER(0xE1, 0x00, 0x18, 0x1E, 0x0A, 0x09, 0x25, 0x3F, 0x43, 0x52, 0x33, 0x03, 0x00, 0x3F, 0x3F);
//SPI_TRANSFER(0x21);
//SPI_TRANSFER(0x11);
SPI_TRANSFER(0x29);
usleep(100 * 1000);   // python: time.sleep(0.100) # 100 ms  // python ms=miliseconds--> "C"= ulseep microseconds * 1000 ??


printf("end  pythonlib init end\n");




#if defined(GPIO_TFT_BACKLIGHT) && defined(BACKLIGHT_CONTROL)
    printf("Setting TFT backlight on at pin %d\n", GPIO_TFT_BACKLIGHT);
    SET_GPIO_MODE(GPIO_TFT_BACKLIGHT, 0x01); // Set backlight pin to digital 0/1 output mode (0x01) in case it had been PWM controlled
    SET_GPIO(GPIO_TFT_BACKLIGHT); // And turn the backlight on.

//test
printf("BL off\n");
CLEAR_GPIO(GPIO_TFT_BACKLIGHT); // And turn the backlight on.
usleep(100 * 1000);

printf("BL on\n");
SET_GPIO(GPIO_TFT_BACKLIGHT); // And turn the backlight on.
usleep(100 * 1000);

printf("BL off\n");
CLEAR_GPIO(GPIO_TFT_BACKLIGHT); // And turn the backlight on.
usleep(100 * 1000);

printf("BL on\n");
SET_GPIO(GPIO_TFT_BACKLIGHT); // And turn the backlight on.
usleep(100 * 1000);

#endif
 
ClearScreen();
 
#ifndef USE_DMA_TRANSFERS // For DMA transfers, keep SPI CS & TA active.
  END_SPI_COMMUNICATION();
#endif
}

ozett · 2020-12-21T11:46:13Z

out of ideas, again. 😭

What works:

/boot/config.txt dtparam=spi=on
init the display with solinnovay-python lib

#!/usr/bin/env python
# -*- coding: utf-8 -*-

#import Adafruit_GPIO as GPIO
import Adafruit_GPIO.SPI as SPI

# test  visual studio save!

import sys
sys.path.append('/usr/src/Python_ST7789/ST7789')

import ST7789 as TFT
#import datetime
#from time import sleep

#from PIL import Image, ImageDraw, ImageFont, ImageColor

#import numpy as np

# Raspberry Pi pin configuration:
RST = 25
DC  = 24
LED = 27
SPI_PORT = 0
SPI_DEVICE = 0
SPI_MODE = 0b11             // binary 0b11 ==  dezimal=3 ??
SPI_SPEED_HZ = 40000000


disp = TFT.ST7789(spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE, max_speed_hz=SPI_SPEED_HZ),mode=SPI_MODE, rst=RST, dc=DC, led=LED)

# Initialize display.
print('disp.begin...')
#disp.begin()
disp.begin()

# Clear display.
print('disp.clear...')
disp.clear()

print('sys.exit ...')
sys.exit()

run fbcp-ili9341

can stop and start the executabele repeatedly when unchanged fbcp-ili9342 code for
#define DISPLAY_SPI_DRIVE_SETTINGS
config.txt has dtparam=spi=on , needed for python -init first
start/stop/start... works only one time with spi-mode 3 in st7734.h
#define DISPLAY_SPI_DRIVE_SETTINGS (1 | BCM2835_SPI0_CS_CPOL | BCM2835_SPI0_CS_CPHA)
does no also not work standalone when config. txt has no dtparam=spi=on .😕
did always hard-reset between tests and compile with:
cmake -DST7789=ON -DSTATISTICS=0 -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSPI_BUS_CLOCK_DIVISOR=20 -DUSE_DMA_TRANSFERS=OFF .. && make -j

tested the init of TFT_eSPI for ST7789_2, but also fails to init the display.

SPI_TRANSFER(0x11);  //SPI_TRANSFER(0x11/*Sleep Out*/)
usleep(150 * 1000); 
usleep(250 * 1000); 
SPI_TRANSFER(0x3A, 0x55);  //SPI_TRANSFER(0x3A/*COLMOD: Pixel Format Set*/, 0x05/*16bpp*/);   on python 0x05, on dafruit 0x55!!
usleep(10 * 1000); 
SPI_TRANSFER(0x36, 0x00); 
SPI_TRANSFER(0x2A, 0x00,0x00,0x00,0xF0);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);  on python: 0x00
SPI_TRANSFER(0x2B, 0x00,0x00,0x00,0xF0);  //SPI_TRANSFER(0x36/*MADCTL: Memory Access Control*/, madctl);  on python: 0x00 
SPI_TRANSFER(0x21);  //SPI_TRANSFER(0x21/*Display Inversion On*/);
usleep(10 * 1000); 
SPI_TRANSFER(0x13/*NORON: Partial off (normal)*/);
usleep(10 * 1000); 
SPI_TRANSFER(0x29);
usleep(150 * 1000); 
usleep(250 * 1000); 

printf("end bodmer TFT eSPI init..\n");

Conclusion:

init-sequence commands not that important, or wrong? or incomplete?
must be some other timing? SPI timing or sequence timing?
any other setting is relevant ? SPI start/stop ? SPI speed?...
what can i test with my limited knowledge?

Help needed: Python works, Why?

why does the python-lib init the display correct, so that afterwards the fbcp-ili9341 excecutable can display the FB ?
any idea for another test?

ozett · 2020-12-21T12:43:16Z

Success. it runs!

(details following: i guess that SPI mode 3 and RESET in init has done the trick)

ozett · 2020-12-21T14:13:22Z

only SPI-mode=3 does the trick.

i fiddeld too much with code,
i did a new checkout and added only this:

#define DISPLAY_SPI_DRIVE_SETTINGS (1 | BCM2835_SPI0_CS_CPOL | BCM2835_SPI0_CS_CPHA)

after that line in

fbcp-ili9341/st7735r.h

Line 16 in 662e8db

#define DISPLAY_WRITE_PIXELS 0x2C

like you suggested before(#178 (comment)).

Gotcha. Success.

juj · 2020-12-23T06:32:55Z

Hey, that is great to hear!

Made a TODO to make that a build option. It seems that different instances of the same controller out there may need to use a different SPI mode. So far my experience had been that if one had a certain type of controller (ILI9341, ILI9486, ST7789, etc.), it would always dictate which SPI mode was needed, but this is the first scenario that shows that it is not so: your display with ST7789 needs SPI mode 3, whereas my display with ST7789 needs SPI mode 0. So it looks like it needs to be a setting that people can toggle on their own. Interesting.

I'll close this bug out when I have that implementation available.

ozett · 2020-12-23T09:42:00Z

Your help was indispensable and great. thanx a lot.
Great to hear to you mantainance the code and build this option. realy great.
there are some people out on the internet with this kind of display, but lost. may they find the buildoption.

the maintainer of the TFT_eSPI has also build option for the SPI-Mode=3 variant as a second ST7789 = ST7789_2
maybe it is of helpt to have a similar naming convention?

https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ST7789_2_Init.h

🤝

ozett · 2020-12-23T09:45:07Z

now playing around to get a 3d-printed frame around the eye 😄

bocklucas · 2021-01-04T03:04:01Z

Hey @ozett! Thanks for collaborating with @juj to solve this issue! I'm sorting through this issue myself (I have the same components you do and am experiencing the same issue)

Quick question if you have a moment! Just want to make sure I wired everything up correctly, if you can confirm you have similarly wired everything up.

(For reference all of the Raspberry Pi pins I list will be the physical pins)

Raspberry Pi 3	Display
6	GND
13	BLK
15	RES
17	VCC
18	DC
19	SDA
21	SCL

(If the images aren't clear enough I can try and get better lighting)

If possible, could you also provide the solution you used to get it working? (I.e. what file changes you made, what cmake commands you ran to get it running?) Apologies, I'm having a tough time parsing it out from the comments (I'm bad at reading 😂 )

THANKS!! 🎉

P.S. Kick ass eye! Looks great in a 3D printed case!

ozett · 2021-01-04T08:26:12Z

colors of your wiring are hard see.

code:

checkout github code already?
than you added only this:

#define DISPLAY_SPI_DRIVE_SETTINGS (1 | BCM2835_SPI0_CS_CPOL | BCM2835_SPI0_CS_CPHA)

after that line in

fbcp-ili9341/st7735r.h

Line 16 in 662e8db

#define DISPLAY_WRITE_PIXELS 0x2C

like the DEVeloper suggested before(#178 (comment)).

Wiring is other than yours, this is mine:

your wiring

your wiring is different.
you must use the gpio-number from your wiring in the compile comand:
got to your source-path (like readme.md describes):

root@raspberrypi:/usr/src/fbcp-ili9341/build#

and compile with your gpio-pin-nr.

cmake -DST7789VW=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..

todo:

check your the gpio-numbers of your pins and use the correct ones in the compile-command.
maybe use a helper like this:

bocklucas · 2021-01-04T11:16:02Z

Thank you!! 😁

bocklucas · 2021-01-04T12:42:13Z

Update

SUCCESS

🎉 🎉 🎉 🎉 🎉 🎉
That was it, 100%.
After adding that line and re-wiring it to your photo with your wiring it began to work!

Thank youuuuuuuuuuuuuuuuuuu! 🎉 🎊
🎉 🎊 🎉 🎊 🎉 🎊 🎉 🎊 🎉 🎊
Best way to start a monday morning

ozett · 2021-01-04T15:14:44Z

Famtastic to see in picture that you got it working!
Was a pleasure to help. Cheers 👋

james1236 · 2021-01-14T03:12:58Z

I have 2 of these displays so thank you guys so much for this!

Edit, now I've got the first working thanks to your guys excellent instructions.

To summarize some of the above discussion and get a working display (if it's like mine) run in the console of your raspberry pi:

sudo apt-get install cmake
cd ~
git clone https://github.com/juj/fbcp-ili9341.git
cd fbcp-ili9341

Then run sudo nano display.h and paste in

#define DISPLAY_SPI_DRIVE_SETTINGS (1 | BCM2835_SPI0_CS_CPOL | BCM2835_SPI0_CS_CPHA)

under the line

#define DISPLAY_SPI_DRIVE_SETTINGS (0)

Then continue with

mkdir build
cd build

Then make sure the SPI interface is turned off either in raspi-config or through sudo nano /boot/config.txt and making sure the line dtparam=spi=off is there (not sure if this is a necessary step)

If you have previously run 'cmake' and would like a fresh start do this:

cd fbcp-ili9341/build
rm -r *

My wiring is:

RPi BOARD (Physical not BCM) Pin #23 (SCLK) -> Display SCL
RPi BOARD (Physical not BCM) Pin #19 (MOSI) -> Display SDA
RPi BOARD (Physical not BCM) Pin #15 -> Display RES
RPi BOARD (Physical not BCM) Pin #11 -> Display DC
Rpi BOARD (Physical not BCM) Pin #13 -> Display BLK

Then run the command below changing your wire numbers (if you're using different wiring) for -DGPIO_TFT_DATA_CONTROL=17 -DGPIO_TFT_RESET_PIN=22 -DGPIO_TFT_BACKLIGHT=27 to the BCM pins from this site https://pinout.xyz/pinout/pin13_gpio27

cmake -DST7789VW=ON -DGPIO_TFT_DATA_CONTROL=17 -DGPIO_TFT_RESET_PIN=22 -DGPIO_TFT_BACKLIGHT=27 -DSTATISTICS=0 -DSPI_BUS_CLOCK_DIVISOR=40 -DUSE_DMA_TRANSFERS=OFF ..

Finally run

make -j
sudo ./fbcp-ili9341

And if your display is like mine (advertised as ST7789 but ended up working with ST7789VW, no cs pin) it might just work!

For autorun on startup put this line before exit 0 in your sudo nano /etc/rc.local

sudo /home/pi/fbcp-ili9341/build/fbcp-ili9341 &

make sure the command is copied exactly; & is there or you might get stuck without being able to boot

These lines are in my sudo nano /boot/config.txt file:

hdmi_group=2
hdmi_mode=87
hdmi_cvt=640 640 60 1 0 0 0
hdmi_force_hotplug=1

And I've made sure that all references to dtoverlay=vc4-fkms-v3d are removed/commented out with # although I'm not sure if necessary

bocklucas · 2021-01-28T01:19:36Z

@james1236 were you able to get output to 2 screens?? Or do you just have 2 screens haha

Just thought I'd ask, that sounds like a pretty sweet setup if you have output to 2 screens.

james1236 · 2021-01-28T02:07:37Z

@james1236 were you able to get output to 2 screens?? Or do you just have 2 screens haha

Just thought I'd ask, that sounds like a pretty sweet setup if you have output to 2 screens.

Just one screen at a time, I have 2 screens that looked a bit different so them both working was a surprise

bocklucas · 2021-01-28T03:33:02Z

@james1236 were you able to get output to 2 screens?? Or do you just have 2 screens haha

Just thought I'd ask, that sounds like a pretty sweet setup if you have output to 2 screens.

Just one screen at a time, I have 2 screens that looked a bit different so them both working was a surprise

Gotcha! Haha awesome!

GaelicThunder mentioned this issue Jan 18, 2021

Black screen on 1.3" SPI Colour LCD (240x240) by Pimoroni (ST7789V) #185

Open

BurAndBY added a commit to BurAndBY/fbcp-st7789vw that referenced this issue May 31, 2023

Simple hack from juj#178

e7f118b

BurAndBY mentioned this issue May 31, 2023

Simple hack from juj/fbcp-ili9341#178 #299

Open

supported? 7 pins -> without CS pin? #178

supported? 7 pins -> without CS pin? #178

Comments

ozett commented Dec 16, 2020 • edited

juj commented Dec 16, 2020

ozett commented Dec 16, 2020 • edited

juj commented Dec 16, 2020

ozett commented Dec 16, 2020 • edited

ozett commented Dec 16, 2020

juj commented Dec 17, 2020

ozett commented Dec 17, 2020

juj commented Dec 17, 2020

ozett commented Dec 17, 2020

ozett commented Dec 17, 2020

ozett commented Dec 17, 2020

ozett commented Dec 17, 2020

ozett commented Dec 18, 2020

juj commented Dec 18, 2020

ozett commented Dec 18, 2020 • edited

ozett commented Dec 18, 2020

ozett commented Dec 18, 2020

ozett commented Dec 18, 2020

juj commented Dec 19, 2020 • edited

ozett commented Dec 19, 2020

ozett commented Dec 19, 2020

ozett commented Dec 19, 2020

Still fails to init

Question of a NOOB:

ozett commented Dec 19, 2020 • edited

ozett commented Dec 19, 2020 • edited

ozett commented Dec 19, 2020 • edited

ozett commented Dec 19, 2020

juj commented Dec 19, 2020

ozett commented Dec 20, 2020

ozett commented Dec 20, 2020

ozett commented Dec 20, 2020

SCK line must be driven high ?

ozett commented Dec 20, 2020 • edited

juj commented Dec 20, 2020

ozett commented Dec 20, 2020

ozett commented Dec 20, 2020 • edited

ozett commented Dec 20, 2020

ozett commented Dec 21, 2020

Conclusion:

Help needed: Python works, Why?

ozett commented Dec 21, 2020 • edited

Success. it runs!

ozett commented Dec 21, 2020 • edited

Gotcha. Success.

juj commented Dec 23, 2020

ozett commented Dec 23, 2020

ozett commented Dec 23, 2020

bocklucas commented Jan 4, 2021 • edited

ozett commented Jan 4, 2021 • edited

code:

Wiring is other than yours, this is mine:

your wiring

todo:

bocklucas commented Jan 4, 2021

bocklucas commented Jan 4, 2021 • edited

Update

SUCCESS

ozett commented Jan 4, 2021

james1236 commented Jan 14, 2021 • edited

To summarize some of the above discussion and get a working display (if it's like mine) run in the console of your raspberry pi:

bocklucas commented Jan 28, 2021

james1236 commented Jan 28, 2021

bocklucas commented Jan 28, 2021

ozett commented Dec 16, 2020 •

edited

ozett commented Dec 16, 2020 •

edited

ozett commented Dec 16, 2020 •

edited

ozett commented Dec 18, 2020 •

edited

juj commented Dec 19, 2020 •

edited

ozett commented Dec 19, 2020 •

edited

ozett commented Dec 19, 2020 •

edited

ozett commented Dec 19, 2020 •

edited

ozett commented Dec 20, 2020 •

edited

ozett commented Dec 20, 2020 •

edited

ozett commented Dec 21, 2020 •

edited

ozett commented Dec 21, 2020 •

edited

bocklucas commented Jan 4, 2021 •

edited

ozett commented Jan 4, 2021 •

edited

bocklucas commented Jan 4, 2021 •

edited

james1236 commented Jan 14, 2021 •

edited