Using TFT ILI9486 8bits parallel on a Nucleo64 F103RB

Hi,
Sorry for asking a newbie question.
I would like to use the ILI9486 that comes with an arduino shield, wired for a 8bit parallel communication.

I have been able to compile a sample code an upload it to an Uno, with LCDWIKI libraries.

The uno is too small to support it, so I’d like to use other board laying in my drawers, a Nucelo64 F103RB, or bluepill.

Obviously, none of those board is not recognized…

I have found stevstrong’s library (GitHub - stevstrong/Adafruit_ILI9486_STM32), but its using maple framework that is outdated. It doesn’t compile with arduino IDE neither.

What are options?
Thanks in advance
++ SIMULOT

And also it’s using SPI instead of a 8-bit parallel bus

So not really what you want

I have found also the following library crafted for STM32

It doesn’t compile too, because it uses maple core.

So I have found the “board_build.core = maple” option.
Still not working with this platformio.ini file:

[env:nucleo_f103rb]
platform = ststm32
board = nucleo_f103rb
framework = arduino
board_build.core = maple
lib_deps =
  https://github.com/adafruit/Adafruit-GFX-Library.git
  https://github.com/nopnop2002/STM32_TFT_8bit.git
lib_ignore =

I get an error on platformio itself:

TypeError: '>=' not supported between instances of 'str' and 'int':
  File "/home/jfcassan/.platformio/penv/lib/python3.8/site-packages/platformio/builder/main.py", line 168:
    env.SConscript("$BUILD_SCRIPT")
  File "/home/jfcassan/.platformio/packages/tool-scons/script/../engine/SCons/Script/SConscript.py", line 597:
    return _SConscript(self.fs, *files, **subst_kw)

Maybe, this is a dead end.
I should either:

  • Using another framework,
  • Using stm native tools,
  • Change the screen element
  • Use another board…

Or this is simply to high for me.
++

This is a Arduino-STM32 board not Maple core board, just replace this with board = genericSTM32F103RB.

Compiles for me when using

[env:genericSTM32F103RB]
platform = ststm32
board = genericSTM32F103RB
framework = arduino
board_build.core = maple
lib_deps =
  Adafruit GFX Library@1.4.14 
  https://github.com/nopnop2002/STM32_TFT_8bit.git
  SPI
  Wire

with STM32_TFT_8bit/CubeDemo_STM32.ino at master · nopnop2002/STM32_TFT_8bit · GitHub.

Thanks Max, it compiles, it uploads to the board, but nothing visible.

I get only gibberish from the monitor. As you said, the board isn’t a maple… It surely matters.
I was able to debug striped down program using the regular core…

This suggests that maple core isn’t compatible with my board, or PIO can’t debug / monitor maple firmware…
Any suggestion?

Have you made sure to follow the wiring diagram

Also check if you can use the sketch STM32_TFT_8bit/examples/LCD_ID_Reader at master · nopnop2002/STM32_TFT_8bit · GitHub to check for basic connectivity.

Unfortunately, the shield is designed for an UNO, so pin wiring is not compatible. So I’ll have to not plug the shield directly and use some dupond wires to follow the diagram. I understand UNO’s pin layout can’t be used efficiently on this board.

But before that, a simple "Serial.println(“Hello”); is not working. With platformio.ini defining 4 configurations:

[env:nucleo_f103rb_arduino]
platform = ststm32
board = nucleo_f103rb
framework = arduino

[env:nucleo_f103rb_maple]
platform = ststm32
board = nucleo_f103rb
framework = arduino
board_build.core = maple

[env:genericSTM32F103RB_maple]
platform = ststm32
board = genericSTM32F103RB
framework = arduino
board_build.core = maple

[env:genericSTM32F103RB_arduino]
platform = ststm32
board = genericSTM32F103RB
framework = arduino

With this small test program:

#include <Arduino.h>

#ifndef LED_BUILTIN
  #define LED_BUILTIN PC13
#endif

void setup() {
  Serial.begin(9600);
  pinMode(LED_BUILTIN, OUTPUT);
}

int c = 0;
void loop() {
  Serial.println("Hello "+ String(++c));
  if (c%2==0)
    digitalWrite(LED_BUILTIN, HIGH);
  else 
    digitalWrite(LED_BUILTIN, LOW);
  delay(1000);
}

Build gives:

Environment                 Status    Duration
--------------------------  --------  ------------
nucleo_f103rb_arduino       SUCCESS   00:00:08.892
nucleo_f103rb_maple         FAILED    00:00:00.349
genericSTM32F103RB_maple    SUCCESS   00:00:02.584
genericSTM32F103RB_arduino  SUCCESS   00:00:08.915

The error on genericSTM32F103RB_mapple is located somewhere in platformio harness:

TypeError: '>=' not supported between instances of 'str' and 'int':
  File "/home/jfcassan/.platformio/penv/lib/python3.8/site-packages/platformio/builder/main.py", line 168:
    env.SConscript("$BUILD_SCRIPT")

Execution gives:

nucleo_f103rb_arduino:  monitor OK, blinking, debugger OK
nucleo_f103rb_maple: N/A
genericSTM32F103RB_maple :  no output, no blinking 
genericSTM32F103RB_arduino: no output, no blinking 

in conclusion:

  • the genericSTM32F103RB board doesn’t produce running code. I should see the led blinking even if the monitor is not functional.
  • The maple core compile only with genericSTM32F103RB but produced code doesn’t run on the board.

For the standard STM32Duino core the author recommends this variant of the library: nucleo-64 error on loading · Issue #7 · nopnop2002/STM32_TFT_8bit · GitHub Maybe the works better out of the box.

Hm there might be clock configuration issues (HSE_XTAL or clock in or whatever), I’m not sure, but I can test on my own nucleo board.

Does it still use the 8-bit interface then? Can you still manually connect the wires to the right pins? DO Do you have any pinout page on the device?

Hi Max, thanks for all of your support!

Is a “good” way to force PIO to use that library in place of the one defined by the core? When I add it in lib_deps, some files are taken from the core instead of the library.

This is precisely why I would prefer using the arduino framework and not the stm32 cube wich is really intimidating :roll_eyes:.

Yes, the device uses 8 bits on the uno. This isn’t typical pins for an SPI or I²C interface. I have dived into LCDWIKI code, and found something like:

  #define write8(d) {                                              \
    PORTH = (PORTH&~HMASK)|(((d)&(0x03<<6)>>3)|(((d)&0x03)<<5); \
    PORTB = (PORTB&~BMASK)|(((d)&((0x01<<5)|(0x03<<2)))<<2);                      \
    PORTG = (PORTG&~HMASK)|(((d)&(0x01<<4)<<1); WR_STROBE; }

So, I’m quite sure this code set the 8 data pins
I hope this could be ported to my board with some amount of brain juice.

PIO should accept the

lib_deps = 
   library_name=<git link / sourc>

form to explicitly use a source for a given library name.

The device is arrived from China, with no doc. but a faded label having SKU:MAR305? mark…

Finally, I have found the product page:
http://www.lcdwiki.com/3.5inch_Arduino_Display-UNO

that leads to http://www.lcdwiki.com/res/Program/Arduino/3.5inch/UNO_8BIT_ILI9486_MAR3501_V1.1/3.5inch_Arduino_8BIT_Module_ILI9486_MAR3501_V1.1.zip

And yeah, it contains some STM32 instruction…

So it compiles with platformio.ini:

[env:nucleo_f103rb]
platform = ststm32
board = nucleo_f103rb
framework = arduino
lib_deps = 
	https://github.com/nopnop2002/Arduino-STM32-8bitTFT
	https://github.com/adafruit/Adafruit-GFX-Library
    https://github.com/rogerclarkmelbourne/Arduino_STM32
	Wire
	SPI

The program is uploaded to the board, and the monitor spits gibberish.
Now, i’m hooking up the shield as required.
to be continued…

Regarding pinout, PA2 and PA3 are also connected to STLink on this bord. This explains the random data on the monitor. So I have changed the mapping like following:

#define TFT_DATA       GPIOA
#define TFT_D0         LL_GPIO_PIN_0
#define TFT_D1         LL_GPIO_PIN_1
#define TFT_D2         LL_GPIO_PIN_12 //was LL_GPIO_PIN_2
#define TFT_D3         LL_GPIO_PIN_11 //was LL_GPIO_PIN_3
#define TFT_D4         LL_GPIO_PIN_4
#define TFT_D5         LL_GPIO_PIN_5
#define TFT_D6         LL_GPIO_PIN_6
#define TFT_D7         LL_GPIO_PIN_7

And now, the monitor gives data, and debugger is working!
:grinning:

But the screen remains white…

I’m not sure how pin number can be translated into pin name and actual pin on the board.
Can I say that LL_GPIO_PIN_12 is PA12?

But this is also mentioned in STM32_TFT_8bit/examples/LCD_ID_Reader at master · nopnop2002/STM32_TFT_8bit · GitHub

(*2)By several boards, This port is used as JTAG.
You need remap.
afio_cfg_debug_ports(AFIO_DEBUG_NONE)

But yeah if it’s used by the STLink then it’s better to use other pins entirely.

Which sketch have you uploaded? Does the LCD reader show some non-zero good information finally?

LL_GPIO_PIN_12 (low-level GPIO pin 12) just means that, Pin number 2. The call where TFT_D7 is used also uses the TFT_DATA macro which contains the GPIO bank, which is GPIOA. So together that makes PA12. So LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_12); would toggle PA12 but LL_GPIO_TogglePin(GPIOB, LL_GPIO_PIN_12); would toggle PB12.

Got it.

The LCD reader show some non zero value. Not sure about their meaning.

reg(0x0000) 00 00       ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 54 80 66 Manufacturer ID
reg(0x0009) 00 00 61 00 00      Status Register
reg(0x000A) 00 08       Get Powsr Mode
reg(0x000C) 00 66       Get Pixel Format
reg(0x0061) 00 00       RDID1 HX8347-G
...

I have tried the GraphicsTest_320x480_SMT32.ino. The program runs several tests, output timings, but the screen remains white.
I need to double check my wiring.

What’s the output for reg(0x00D3)?

Here is the complete output

reg(0x0000) 00 00       ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 54 80 66 Manufacturer ID
reg(0x0009) 00 00 61 00 00      Status Register
reg(0x000A) 00 08       Get Powsr Mode
reg(0x000C) 00 66       Get Pixel Format
reg(0x0061) 00 00       RDID1 HX8347-G
reg(0x0062) 00 00       RDID2 HX8347-G
reg(0x0063) 00 00       RDID3 HX8347-G
reg(0x0064) 00 00       RDID1 HX8347-A
reg(0x0065) 00 00       RDID2 HX8347-A
reg(0x0066) 00 00       RDID3 HX8347-A
reg(0x0067) 00 00       RDID Himax HX8347-A
reg(0x0070) 00 00       Panel Himax HX8347-A
reg(0x00A1) 00 93 30 93 30      RD_DDB SSD1963
reg(0x00B0) 00 00       RGB Interface Signal Control
reg(0x00B4) 00 00       Inversion Control
reg(0x00B6) 00 02 02 3B 3B      Display Control
reg(0x00B7) 00 06       Entry Mode Set
reg(0x00BF) 00 00 00 00 00 00   ILI9481, HX8357-B
reg(0x00C0) 00 0E 0E 0E 0E 0E 0E 0E 0E  Panel Control
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00      GAMMA
reg(0x00CC) 00 04       Panel Control
reg(0x00D0) 00 00 00    Power Control
reg(0x00D2) 00 00 00 00 00      NVM Read
reg(0x00D3) 00 00 94 86 ILI9341, ILI9488
reg(0x00DA) 00 54       RDID1
reg(0x00DB) 00 80       RDID2
reg(0x00DC) 00 66       RDID3
reg(0x00E0) 00 0D 29 38 0F 07 04 77 FE 64 0B 01 00 1F 21 08     GAMMA-P
reg(0x00E1) 00 09 10 04 06 0A 00 13 B0 1B 0C 05 01 35 19 0D     GAMMA-N
reg(0x00EF) 00 80 00 10 60 40   ILI9327
reg(0x00F2) 00 18 A3 12 02 B2 12 FF 10 00 00 00 Adjust Control 2
reg(0x00F6) 00 54 80 66 Interface Control

Yep the 00 00 94 86 outputting 0x9486 is a clear indication that generally talking to the device is working… No idea why it’s showing a white screen for you though. Power problems with the backlight?