SPI (spi2) does not appear to work? Add spi1?

I thought I would try hooking up an ST7796 display to the UNO-Q and
nothing was displayed, so I then hooked up logic Analyzer and found that there
was nothing coming out of the MOSI pin.

Decided to try a simple sketch/setup to verify this:
Sketch:

#include <SPI.h>
#define SPIX SPI
void setup() {
  // put your setup code here, to run once:
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(10, OUTPUT);
  digitalWrite(10, HIGH);
  SPIX.begin();
  SPIX.beginTransaction(SPISettings(16000000, MSBFIRST, SPI_MODE0));
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  digitalWrite(10, LOW);
  for (int i = 0; i < 256; i++) SPIX.transfer(i);
  digitalWrite(10, HIGH);
  digitalWrite(LED_BUILTIN, LOW);
  delay(250);
}


Channels shown pins 10-13 followed by SPI pins on the other connector.

All that I see is the clock (pin D13)

Looking at the Device Tree sources, I see:
On Zephyr side:

&spi2 {
	status = "okay";
	pinctrl-0 = <&spi2_sck_pb13
		     &spi2_miso_pb14 &spi2_mosi_pb15 &spi2_nss_pb9>;
	pinctrl-1 = <&spi2_sck_pd1
		     &spi2_miso_pc2 &spi2_mosi_pc3>;
	pinctrl-names = "default", "sleep"; /* TODO: sleep is ICSP mux */
};

&spi3 {
	status = "okay";
	pinctrl-0 = <&spi3_sck_pg9
		     &spi3_miso_pg10 &spi3_mosi_pb5 &spi3_nss_pg12>;
	pinctrl-names = "default";
};

The spi3 object is already discussed in a different thread:

On ArduinoCore-zephyr side:
spis = <&spi2>, <&spi3>;

Will try to debug some: Gut tells me, that probably issue with other define usage
of PB15 in the device tree. Found similar issues with other zephyr boards.

Maybe the PWM pin define:

		pwm-pin-gpios =
				/* <&gpiob 6 0>, */    /* D1/PB6 - TIM4_CH1 */
				/* <&gpiob 3 0>, */     /* D2/PB3 - TIM2_CH2 */
				/* <&gpiob 3 0>, */    /* D2/PB3 - TIM2_CH2 */
				<&gpiob 0 0>,     /* D3/PB0 - TIM3_CH3 */
				<&gpioa 11 0>,    /* D5/PA11 - TIM1_CH4 */
				<&gpiob 1 0>,     /* D6/PB1 - TIM3_CH4 */
				/* <&gpiob 2 0>, */    /* D7/PB2 - TIM8_CH4N */
				/* <&gpiob 4 0>, */    /* D8/PB4 - TIM3_CH1 */
				<&gpiob 8 0>,     /* D9/PB8 - TIM4_CH3 */
				<&gpiob 9 0>,     /* D10/PB9 - TIM4_CH4 */
				<&gpiob 15 0>,    /* D11/PB15 - TIM1_CH3N */

Secondary question: Wondering about trying to define an SPI2 object that uses
spi1? Maybe the pins: 2, 4, 5?

1 Like

Sounds like same initial issues we had with the Giga. Also noticed that they hard coded the CS pins which we removed because it was causing issues when we tried other pins.

Wondering if it has the same SD card performance issues that the giga has - my guess is yes since if I remember right we isolated to a zephyr issue?

Quick update: I verified there was an issue with the MOSI pin, by adding in
some debug stuff I did for GIGA and H7...
Sketch now looks like:

#include <SPI.h>
#define SPIX SPI

void print_gpio_regs(const char *name, GPIO_TypeDef *port) {
  //printk("GPIO%s(%p) %08X %08X %08x\n", name, port, port->MODER, port->AFR[0], port->AFR[1]);
  Serial.print("GPIO");
  Serial.print(name);
  Serial.print(" ");
  Serial.print(port->MODER, HEX);
  Serial.print(" ");
  Serial.print(port->AFR[0], HEX);
  Serial.print(" ");
  Serial.print(port->AFR[1], HEX);
  Serial.print(" ");
  Serial.print(port->IDR, HEX);
  Serial.print(" ");
  Serial.print(port->ODR, HEX);
  Serial.print(" ");
  uint32_t pupdr = port->PUPDR;
  Serial.print(pupdr, HEX);
  Serial.print(" : ");
  for (uint8_t i = 0; i < 16; i++) {
    switch (pupdr & 0xC0000000) {
      case 0x00000000ul: Serial.print("-"); break;
      case 0x40000000ul: Serial.print("U"); break;
      case 0x80000000ul: Serial.print("D"); break;
      default: Serial.print("?"); break;
    }
    pupdr <<= 2;
  }
  Serial.println();
}

void show_all_gpio_regs() {
  print_gpio_regs("A", (GPIO_TypeDef *)GPIOA_BASE);
  print_gpio_regs("B", (GPIO_TypeDef *)GPIOB_BASE);
  print_gpio_regs("C", (GPIO_TypeDef *)GPIOC_BASE);
  print_gpio_regs("D", (GPIO_TypeDef *)GPIOD_BASE);
  print_gpio_regs("E", (GPIO_TypeDef *)GPIOE_BASE);
  print_gpio_regs("F", (GPIO_TypeDef *)GPIOF_BASE);
  print_gpio_regs("G", (GPIO_TypeDef *)GPIOG_BASE);
  print_gpio_regs("H", (GPIO_TypeDef *)GPIOH_BASE);
  print_gpio_regs("I", (GPIO_TypeDef *)GPIOI_BASE);
}


void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(10, OUTPUT);
  digitalWrite(10, HIGH);
  SPIX.begin();
  SPIX.beginTransaction(SPISettings(16000000, MSBFIRST, SPI_MODE0));

  show_all_gpio_regs();
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  digitalWrite(10, LOW);
  for (int i = 0; i < 256; i++) SPIX.transfer(i);
  digitalWrite(10, HIGH);
  digitalWrite(LED_BUILTIN, LOW);
  delay(250);
}

Output on Serial monitor: Serial (pins 0, 1)

uart:~$ GPIOA ABBEFFDF 0 1000 C100 0 64000000 : UDU-------------
GPIOB ABA6AABA 77600022 15504422 E90 200 28501900 : -DD-UU---UDU----
GPIOC FFFFFFFF 0 0 0 0 0 : ----------------
GPIOD FAFFFFFF 0 440000 3000 0 5000000 : --UU------------
GPIOE FFFFFFFF 0 0 0 0 0 : ----------------
GPIOF FFFFFFFF 0 0 0 0 0 : ----------------
GPIOG F2EAABFF 88800000 60668 3580 0 9284400 : --DU-DD-U-U-----
GPIOH FE9FFFFF 0 22200 0 0 0 : ----------------
GPIOI FFFF 0 0 0 0 0 : ----------------

To decode the SPI pins are on PB13-PB15
GPIOB ABA6AABA 77600022 15504422 E90 200 28501900 : -DD-UU---UDU----
(Fixed table a little)

D11 -> PB15 -> AF1->TIM1_CH3N
D12 -> PB14 -> AF5 -> SPI2_MISO
D13 -> PB13 -> AF5 -> SPI2_SCK

I updated the overlay file and built the "booloader" and used the burn bootloader
which appeared to use it:

Now I see:

uart:~$ GPIOA ABBEFFDF 0 1000 C000 0 64000000 : UDU-------------
GPIOB ABA6AABA 77600022 55504422 E90 200 A8501900 : DDD-UU---UDU----
GPIOC FFFFFFFF 0 0 0 0 0 : ----------------
GPIOD FAFFFFFF 0 440000 3000 0 5000000 : --UU------------
GPIOE FFFFFFFF 0 0 0 0 0 : ----------------
GPIOF FFFFFFFF 0 0 0 0 0 : ----------------
GPIOG F2EAABFF 88800000 60668 3580 0 9284400 : --DU-DD-U-U-----
GPIOH FE9FFFFF 0 22200 0 0 0 : ----------------
GPIOI FFFF 0 0 0 0 0 : ----------------

And AFR is 55504422 So all SPI pins

and Now:

I will probably create a PR for the changes

As for adding spi1 as SPI2 it built but got had several errors in the run
about table __device_dts_ord_80 was not found... and a couple of others...

UNO-Q: Fix SPI (spi2) - disable PWM on D11 by KurtE · Pull Request #242 · arduino/ArduinoCore-zephyr

3 Likes

Works with my zephyr version of ST77xx library code :smiley:

There are for sure probably some speedups that can be done:

As you can see there are areas with pretty large gaps between bytes/words
output:

Some areas like fillRects are better with their breaks between outputs, but
still not great:

But at least is is starting to work.

2 Likes

@KurtE Made the overlay changes to the q, rebuilt and flashed the q. SDfat lib now runs.

Running the stock SDFat bench sketch from the IDE at 24 Mhz shows pretty lousy performance as expected:

 Type is exFAT
Card size: 30.98 GB (GB = 1E9 bytes)

Manufacturer ID: 0X27
OEM ID: PH
Product: SD32G
Revision: 3.0
Serial number: 0X6C06C24C
Manufacturing date: 8/2021

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
50.89,14220,10050,10055
50.68,10079,10050,10069

Starting read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
51.30,10142,9970,9978
51.34,10028,9970,9971

Done
Type any character to start

You already pointed out the reason - large gaps between bytes/words which was a know issue in zephyr but not sure if they ever incorporated a fix for that.

2 Likes

Not sure, if/when this PR will be pulled in. The Arduino developers are currently very focused on getting specific things working and sometimes some of these other things can take a while like sometimes months, to get reviewed an pulled in.

In the mean time, I created a hack that appears to work, to at least get the
SPI port to work, where you force the D11 pin into SPI mode like:

void setup() {
    GPIOB->AFR[1] = (GPIOB->AFR[1] & 0x0FFFFFFF) | 0x50000000;
...

For the fun of it, I might try a few different hacks to see if I can get it to work
on the 6 pin header.

I now have a simple ST7796 sketch running using the JSPI connector pins
instead of D11-13.

@Merlin513 @bmillier @ptillisch
Some reason I don't think it would pass muster with the Zephyr people :smiley:

See the code under: #ifdef USE_JSPI_PINS
And the quick and dirty helper function.

#include <elapsedMillis.h>

#include <ST77XX_zephyr.h>

#define USE_JSPI_PINS

#define TFT_DC 4
#define TFT_CS 2
#define TFT_RST 3


// Option 1: use any pins but a little slower
// Note: code will detect if specified pins are the hardware SPI pins
//       and will use hardware SPI if appropriate
// For 1.44" and 1.8" TFT with ST7735 use
//ST7735_t3 tft = ST7735_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCK, TFT_RST);

// For 1.54" or other TFT with ST7789, This has worked with some ST7789
// displays without CS pins, for those you can pass in -1 or 0xff for CS
// More notes by the tft.init call
//ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCK, TFT_RST);

// Option 2: must use the hardware SPI pins
// (for UNO thats sclk = 13 and sid = 11) and pin 10 must be
// an output. This is much faster - also required if you want
// to use the microSD card (see the image drawing example)
// For 1.44" and 1.8" TFT with ST7735 use
//ST7735_t3 tft = ST7735_t3(TFT_CS, TFT_DC, TFT_RST);

// For 1.54" TFT with ST7789
//ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_RST);

// For 3.5" or 4.0" TFT with ST7796


ST7796_zephyr tft = ST7796_zephyr(&SPI, TFT_CS, TFT_DC, TFT_RST);

uint8_t test_screen_rotation = 0;

void set_gpio_pin_mode(GPIO_TypeDef *port, uint8_t pin, uint8_t af) {
  // Set the MODER = could be done in fewer steps
  uint32_t moder = port->MODER;
  uint32_t mask = ~(0x3 << (pin * 2));
  moder = (moder & mask) | (0x2 << (pin * 2));
  port->MODER = moder;

  if (pin < 8) {
    port->AFR[0] = port->AFR[0] & ~(0xf << (pin * 4)) | (af << (pin * 4));
  } else {
    pin -= 8;
    port->AFR[1] = port->AFR[1] & ~(0xf << (pin * 4)) | (af << (pin * 4));
  }
}

void print_gpio_regs(const char *name, GPIO_TypeDef *port) {
  //printk("GPIO%s(%p) %08X %08X %08x\n", name, port, port->MODER, port->AFR[0], port->AFR[1]);
  Serial.print("GPIO");
  Serial.print(name);
  Serial.print(" ");
  Serial.print(port->MODER, HEX);
  Serial.print(" ");
  Serial.print(port->AFR[0], HEX);
  Serial.print(" ");
  Serial.print(port->AFR[1], HEX);
  Serial.print(" ");
  Serial.print(port->IDR, HEX);
  Serial.print(" ");
  Serial.print(port->ODR, HEX);
  Serial.print(" ");
  uint32_t pupdr = port->PUPDR;
  Serial.print(pupdr, HEX);
  Serial.print(" : ");
  for (uint8_t i = 0; i < 16; i++) {
    switch (pupdr & 0xC0000000) {
      case 0x00000000ul: Serial.print("-"); break;
      case 0x40000000ul: Serial.print("U"); break;
      case 0x80000000ul: Serial.print("D"); break;
      default: Serial.print("?"); break;
    }
    pupdr <<= 2;
  }
  Serial.println();
}

void show_all_gpio_regs() {
  print_gpio_regs("A", (GPIO_TypeDef *)GPIOA_BASE);
  print_gpio_regs("B", (GPIO_TypeDef *)GPIOB_BASE);
  print_gpio_regs("C", (GPIO_TypeDef *)GPIOC_BASE);
  print_gpio_regs("D", (GPIO_TypeDef *)GPIOD_BASE);
  print_gpio_regs("E", (GPIO_TypeDef *)GPIOE_BASE);
  print_gpio_regs("F", (GPIO_TypeDef *)GPIOF_BASE);
  print_gpio_regs("G", (GPIO_TypeDef *)GPIOG_BASE);
  print_gpio_regs("H", (GPIO_TypeDef *)GPIOH_BASE);
  print_gpio_regs("I", (GPIO_TypeDef *)GPIOI_BASE);
}




void setup() {
  Serial.begin(115200);
  long unsigned debug_start = millis();
  while (!Serial && ((millis() - debug_start) <= 5000))
    ;
  Serial.println("Setup");
  // Use this initializer if you're using a 1.8" TFT 128x160 displays
  //tft.initR(INITR_BLACKTAB);

  // Or use this initializer (uncomment) if you're using a 1.44" TFT (128x128)
  //tft.initR(INITR_144GREENTAB);

  // Or use this initializer (uncomment) if you're using a .96" TFT(160x80)
  //tft.initR(INITR_MINI160x80);

  // Or use this initializer (uncomment) for Some 1.44" displays use different memory offsets
  // Try it if yours is not working properly
  // May need to tweek the offsets
  //tft.setRowColStart(32,0);

  // Or use this initializer (uncomment) if you're using a 1.54" 240x240 TFT
  //tft.init(240, 240);   // initialize a ST7789 chip, 240x240 pixels

  // OR use this initializer (uncomment) if using a 2.0" 320x240 TFT:
  //tft.init(240, 320);           // Init ST7789 320x240

  // OR use this initializer (uncomment) if using a 2.0" 320x240 TFT:
  //  tft.init(240, 320);           // Init ST7789 320x240

  // OR use this initializer (uncomment) if using a 240x240 clone
  // that does not have a CS pin2.0" 320x240 TFT:
  //tft.init(240, 240, SPI_MODE2);           // Init ST7789 240x240 no CS

  // Or for ST7796 3.5 or 4"
#ifdef USE_JSPI_PINS
  // they are pins c2, c3, d1
  set_gpio_pin_mode(GPIOC, 2, 5);
  set_gpio_pin_mode(GPIOC, 3, 5);
  set_gpio_pin_mode(GPIOD, 1, 5);

  pinMode(11, INPUT);
  pinMode(12, INPUT);
  pinMode(13, INPUT);
#endif

  tft.init(320, 480);
  tft.fillScreen(ST77XX_RED);
  show_all_gpio_regs();
}

void loop() {
  elapsedMillis em;
  tft.fillScreen(ST77XX_BLACK);
  tft.fillScreen(ST77XX_NAVY);
  tft.fillScreen(ST77XX_DARKGREEN);
  tft.fillScreen(ST77XX_DARKCYAN);
  tft.fillScreen(ST77XX_MAROON);
  tft.fillScreen(ST77XX_PURPLE);
  tft.fillScreen(ST77XX_OLIVE);
  tft.fillScreen(ST77XX_LIGHTGREY);
  tft.fillScreen(ST77XX_DARKGREY);
  tft.fillScreen(ST77XX_BLUE);
  tft.fillScreen(ST77XX_GREEN);
  tft.fillScreen(ST77XX_CYAN);
  tft.fillScreen(ST77XX_RED);
  tft.fillScreen(ST77XX_MAGENTA);
  tft.fillScreen(ST77XX_YELLOW);
  tft.fillScreen(ST77XX_WHITE);
  tft.fillScreen(ST77XX_ORANGE);
  tft.fillScreen(ST77XX_GREENYELLOW);
  tft.fillScreen(ST77XX_PINK);

  uint32_t dt = em;
#if 0
  Serial.print(dt);
  delay(250);
  em = 0;
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_BLACK);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_NAVY);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_DARKGREEN);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_DARKCYAN);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_MAROON);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_PURPLE);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_OLIVE);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_LIGHTGREY);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_DARKGREY);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_BLUE);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_GREEN);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_CYAN);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_RED);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_MAGENTA);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_YELLOW);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_WHITE);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_ORANGE);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_GREENYELLOW);
  tft.fillRectCB(0, 0, tft.width(), tft.height(), ST77XX_PINK);
  dt = em;
  Serial.print(" ");
#endif
  Serial.println((uint32_t)em);
}

I know the saying goes: “When in Rome, do as the Romans do”
But sometimes ... :laughing:

1 Like

@KurtE

Very cool :slight_smile: Hopefully ArduinoTeam will get the SPI fixes into the core before the next release!!!

Hi guys, sorry this is a bit OT but related in some way and you guys know what you are talking about :slight_smile:

I’m looking at the SOC → MCU SPI, there are a few posts here about it, from what I can see the Arduino guys are saying the hardware is working but the spidef stuff is not set up.

From the data sheet I have Soc SE5 SPI -> MCU SPI3 being used. Also I can see that another SPI is there on the JSPI (JSPI1)pins.

The dts I am looking at is: u-boot/dts/upstream/src/arm64/qcom/qrb2210-arduino-imola.dts at 8008ca96a4dc53ddb3e51b96ea7e86d881ab7969 · arduino/u-boot · GitHub

I have also grabbed the dtc output on the board.

If I look at the dev folder I only see a single spidev:

ls -l /dev/spi*
crw------- 1 root root 153, 0 Jan 10 21:40 /dev/spidev0.0

In the dts file I see:

&spi5 {
	status = "okay";
	/delete-property/ dmas;

	spidev@0 {
		reg = <0>;
		compatible = "cisco,spi-petra";
		status = "okay";
	};
};

So that to me in my very limited understanding would mean that spidev0.0is using SPI5, which should be the correct one for the soc→mcu spi.

I don’t understand though where the JSPI (JSPI1)one is, I would expect two spidevs in the dev folder, or am I totally misunderstanding how all this works?

Sorry, I am not sure how the SPIDEV stuff works here between the two processors. I have
only played with Arduino SPI stuff.

When I look that the SPI objects for the Q: where the List of SPI object is defined in the
overlay file: spis = <&spi2>, <&spi3>;

ArduinoCore-zephyr/variants/arduino_uno_q_stm32u585xx/arduino_uno_q_stm32u585xx.overlay at main · arduino/ArduinoCore-zephyr

The SPI objects in the DTS are defined in the Zephyr project under boards:

&spi2 {
	status = "okay";
	pinctrl-0 = <&spi2_sck_pb13 &spi2_miso_pb14 &spi2_mosi_pb15 &spi2_nss_pb9>;
	/* use      <&spi2_sck_pd1 &spi2_miso_pc2 &spi2_mosi_pc3> for the ICSP connector */
	pinctrl-names = "default";
};

&spi3 {
	status = "okay";
	pinctrl-0 = <&spi3_sck_pg9 &spi3_miso_pg10 &spi3_mosi_pb5 &spi3_nss_pg12>;
	pinctrl-names = "default";
};

zephyr/boards/arduino/uno_q/arduino_uno_q-common.dtsi at main · zephyrproject-rtos/zephyr

Where that overlay above is overlaying information from stm32u5.dtsi
Which has:

		spi1: spi@40013000 {
			compatible = "st,stm32h7-spi", "st,stm32-spi-fifo", "st,stm32-spi";
			#address-cells = <1>;
			#size-cells = <0>;
			reg = <0x40013000 0x400>;
			interrupts = <59 5>;
			clocks = <&rcc STM32_CLOCK(APB2, 12)>;
			st,spi-data-width = "full-4-to-32-bit";
			status = "disabled";
		};

		spi2: spi@40003800 {
			compatible = "st,stm32h7-spi", "st,stm32-spi-fifo", "st,stm32-spi";
			#address-cells = <1>;
			#size-cells = <0>;
			reg = <0x40003800 0x400>;
			interrupts = <60 5>;
			clocks = <&rcc STM32_CLOCK(APB1, 14)>;
			st,spi-data-width = "full-4-to-32-bit";
			status = "disabled";
		};

		spi3: spi@46002000 {
			compatible = "st,stm32h7-spi", "st,stm32-spi-fifo", "st,stm32-spi";
			#address-cells = <1>;
			#size-cells = <0>;
			reg = <0x46002000 0x400>;
			interrupts = <99 5>;
			clocks = <&rcc STM32_CLOCK(APB3, 5)>;
			st,spi-data-width = "limited-8-16-bit";
			status = "disabled";
		};

zephyr/dts/arm/st/u5/stm32u5.dtsi at main · zephyrproject-rtos/zephyr

In your above information: I think that is probably referring to the other processor. As for how many SPI objects it has and how they are defined, sorry I have no idea.

But assuming similar device tree information, the spidev@0 in it is defining sort of a
device that uses spi5, and sets up bindings for it. The Arduino zephyr code does not
have examples of it here under the q defines. In my own stuff, where I build
test apps directly with zephyr, I have some, for example for Portenta H7 where
I may have TFT display where:

&spi2 {
	status = "okay";
	pinctrl-0 = <&spi2_sck_pi1
		     &spi2_miso_pc2 &spi2_mosi_pc3>;
	pinctrl-names = "default";
	/* added for sketch */
	generic_tft_spi_dev: generic_tft_spi_dev@0 {
		status = "okay";
		compatible = "vnd,spi-device";
		reg = <0>;
		spi-max-frequency = <30000000>;
	};

};

and also in that file I have:

/ {

	zephyr,user {
		generic_tft-gpios = <&gpioj 11 GPIO_ACTIVE_HIGH>,	/* CS D2 */
						<&gpioc 7 GPIO_ACTIVE_HIGH>,	/* DC D4 */
						<&gpiog 7 GPIO_ACTIVE_HIGH>;	/* RST D3 */
						/* <&gpio1 30 GPIO_ACTIVE_LOW>;	touch cs Pin 26 */

	};

};

And in the source code I can get to that object:

static struct spi_dt_spec generic_tft_spi =
	SPI_DT_SPEC_GET(DT_NODELABEL(generic_tft_spi_dev), SPI_OP, 0);
#endif

Which I then pass that object in my case to some ST7796 code I have, that
from it can also find out which actual SPI object is used, that is in the code
ST77xx code I save away that pointer to member variable _spi_dev.
And can all off to zephyr SPI code like:
spi_transceive(_spi_dev->bus, &_config16, &tx_buf_set, nullptr);

Sorry, I know my answer is sort of a shotgun answer as not sure exactly may or may not help... Hopefully some of this helps some...

1 Like

Thanks Kurt, I will read all that carefully a bit later…

I have read though your post a couple of times now :slight_smile:

Thanks very much for all the details.

The SPI5 bit I was talking about is indeed the other processor, and I think it looks set up correctly but I don’t know much about SPIDev.

Do you have a link somewhere about how to alter the device tree for these boards, is it as bad as having to rebuild the whole kernel or are there shortcuts?