does not linking with the driver ILI9488.

[SkyFort]

Мой английский очень посредственен. Поэтому вначале на русском потом google translate....

Пытаюсь собрать проект RAW32 ILI9488. Получаю ошибку линковки: undefined symbol gdisp_lld_draw_pixel referenced by symbol GDISPVMT_OnlyOne (section .rodata.GDISPVMT_OnlyOne in file gdisp_lld_ILI9488.o) Сборка с тестовым драйвером ("TestStub") завершается успешно. Не могу понять где я ошибаюсь, на какой стадии.

My English is very mediocre. Therefore, first in Russian then Google translate....

I'm trying to build a RAW32 ILI9488 project. I get a linking error: undefined symbol gdisp_lld_draw_pixel referenced by symbol GDISPVMT_OnlyOne (section .rodata.GDISPVMT_OnlyOne in file gdisp_lld_ILI9488.o) The build with the test driver (“TestStub”) completes successfully. I can’t understand where I’m wrong, at what stage.

[Joel Bodenmann]

Hello & Welcome to the µGFX Community!

Unfortunately, we don't speak Russian. I hope that google translate will work for you. I will try to use simple wording.

Can you please show the complete compilation output when you do a clean build?

[SkyFort]

Segger Embedded Studio for ARM. "TestStub":

Building ‘uGFX_Probe’ from solution ‘STM32F1’ in configuration ‘Debug’
  Compiling ‘system_stm32f10x.c’
  Compiling ‘main.c’
  Assembling ‘SEGGER_THUMB_Startup.s’
  Assembling ‘stm32f10x_md_vl_Vectors.s’
  Assembling ‘STM32F1xx_Startup.s’
  Compiling ‘gdisp_lld_TestStub.c’
  Compiling ‘gdisp.c’
  Compiling ‘gdriver.c’
  Compiling ‘gos_raw32.c’
    GOS: Raw32 - Make sure you initialize your hardware and the C runtime before calling gfxInit() in your application!
  Compiling ‘gos_x_heap.c’
  Compiling ‘gos_x_threads.c’
  Compiling ‘gfx.c’
  Linking uGFX_Probe.elf
Build complete
 

Segger Embedded Studio for ARM. "ILI9488":

Building ‘uGFX_Probe’ from solution ‘STM32F1’ in configuration ‘Debug’
  Compiling ‘system_stm32f10x.c’
  Compiling ‘main.c’
  Assembling ‘SEGGER_THUMB_Startup.s’
  Assembling ‘stm32f10x_md_vl_Vectors.s’
  Assembling ‘STM32F1xx_Startup.s’
  Compiling ‘gdisp_lld_ILI9488.c’
  Compiling ‘gdisp.c’
  Compiling ‘gdriver.c’
  Compiling ‘gos_raw32.c’
    GOS: Raw32 - Make sure you initialize your hardware and the C runtime before calling gfxInit() in your application!
  Compiling ‘gos_x_heap.c’
  Compiling ‘gos_x_threads.c’
  Compiling ‘gfx.c’
  Linking uGFX_Probe.elf
    undefined symbol gdisp_lld_draw_pixel referenced by symbol GDISPVMT_OnlyOne (section .rodata.GDISPVMT_OnlyOne in file gdisp_lld_ILI9488.o)
    Build failed
Build failed

[Joel Bodenmann]

I am a bit confused by this error. The ILI9488 driver does not implement gdisp_lld_draw_pixel() which is correct. However, the GDISP API should not call that if it's not available.

Some questions:

• Can the compiler/linker tell you the file & linenumber where this reference occurs?
• Are you calling gdisp_lld_draw_pixel() manually in your application code?
• Does your main() do anything (µGFX related) other than gfxInit()?
• Did you modify the ILI9488 configuration file?
• Are you using the latest master branch of the µGFX git repository?

[SkyFort]

I'm not a programming professional, it's my hobby. Therefore, it is easier for me to use IDE than Make way.

2 hours ago, Joel Bodenmann said:

Can the compiler/linker tell you the file & linenumber where this reference occurs?

I studied the *.map file of the linker, tried to find it in the project "GDISPVMT_OnlyOne" - no result.

2 hours ago, Joel Bodenmann said:

Are you calling gdisp_lld_draw_pixel() manually in your application code?

No!

 

2 hours ago, Joel Bodenmann said:

Does your main() do anything (µGFX related) other than gfxInit()?

No! My Main.c:

int main(void) {
  int i;
 SystemCoreClockUpdate();
 SysTick_Config(SystemCoreClock /1000);

 gfxInit();

  for (i = 0; i < 100; i++) {
    printf("Hello World %d!\n", i);
  }
  do {
    i++;
  } while (1);
}

2 hours ago, Joel Bodenmann said:

Did you modify the ILI9488 configuration file?

No, it is original.

 

2 hours ago, Joel Bodenmann said:

Are you using the latest master branch of the µGFX git repository?

uGFX downloading from this site.

 

there was an attempt run uGFX with KS0108. Unsuccessful. Ihave HardFault becouse of problem memory allocation. There wasn't enough time to figure it out - the display went to repair the old industrial control unit. I think we should try to start the project from scratch. It will take some time to reconcile the library files with my IDE.

 

Edited February 11 by SkyFort

[Joel Bodenmann]

5 hours ago, SkyFort said:

uGFX downloading from this site.

Before we move any further, can you try using the latest `master` branch from the µGFX git repository?   https://git.ugfx.io/ugfx/ugfx

[inmarket]

Check your gfxconf.h file. Make sure it is not defining GDISP_PIXELFORMAT

[SkyFort]

18 hours ago, Joel Bodenmann said:

Before we move any further, can you try using the latest `master` branch from the µGFX git repository?   https://git.ugfx.io/ugfx/ugfx

I did it. Got "master" branch from repository and replace files in project. No effect, error repeats.

[SkyFort]

15 hours ago, inmarket said:

Check your gfxconf.h file. Make sure it is not defining GDISP_PIXELFORMAT

Checked.  Fragment of my "gfxconf.h":

//#define GDISP_DRIVER_LIST                            GDISPVMT_Win32, GDISPVMT_Win32
//    #ifdef GDISP_DRIVER_LIST
//        // For code and speed optimization define as GFXON or GFXOFF if all controllers have the same capability
//        #define GDISP_HARDWARE_STREAM_WRITE          GFXOFF
//        #define GDISP_HARDWARE_STREAM_READ           GFXOFF
//        #define GDISP_HARDWARE_STREAM_POS            GFXOFF
//        #define GDISP_HARDWARE_DRAWPIXEL             GFXOFF
//        #define GDISP_HARDWARE_CLEARS                GFXOFF
//        #define GDISP_HARDWARE_FILLS                 GFXOFF
//        #define GDISP_HARDWARE_BITFILLS              GFXOFF
//        #define GDISP_HARDWARE_SCROLL                GFXOFF
//        #define GDISP_HARDWARE_PIXELREAD             GFXOFF
//        #define GDISP_HARDWARE_CONTROL               GFXOFF
//        #define GDISP_HARDWARE_QUERY                 GFXOFF
//        #define GDISP_HARDWARE_CLIP                  GFXOFF

//        #define GDISP_PIXELFORMAT                    GDISP_PIXELFORMAT_RGB888
//    #endif

All lines commented....

Edited February 12 by SkyFort

[SkyFort]

The project is compiled and linked!

Thank you very much Joel and his team for we help and participation in solving the problem. This is not a bug in the library code. This is a surprise from the IDE I use.

Deleting files from the project inside the IDE was not enough. For some unknown reason, the remnants of the old code for the KS0108 driver were pulled up during compilation and linking in silent mode.... Physical deletion of KS0108 driver files from HDD helped.

I'm moving on. The road obeys the one who walks....

Best regards! Sky.

Edited February 13 by SkyFort

[Joel Bodenmann]

Glad to hear that you got it working! Thank you for reporting back

[SkyFort]

Hello gentlemens!

Once again I want to thank you for your support and attention to my problem.  However, I encountered some difficulties when trying to run the driver. The solutions of which required changing the module code gdisp_lld_ILI9488.c. Initially I had a white screen and the display showed no response. The problem is not only mine, so I carefully readed the topic: https://community.ugfx.io/topic/4360-white-screen-on-ili9488/. Using Joel’s advice, I connected a logic analyzer, reduced the SPI exchange rate to a minimum and made sure that the transmitted data was correct. Armed with patience and a datasheet on the ili9488, I began to analyze the code of the gdisp_lld_init() function.

Problem point#1:

/* Hardware reset */
	setpin_reset(g, gTrue);
	gfxSleepMilliseconds(2);
  setpin_reset(g, gFalse);
  gfxSleepMilliseconds(10);
  setpin_reset(g, gTrue); !!!!!!!!!!!!!!!!!!!!!
  gfxSleepMilliseconds(120);

We do a hardware reset and press the reset pin to the ground again. For what? For this reason, the controller simply ignores the following commands. Typically, the active level of the reset signal is low. If there are devices with high reset rates, might it make sense to do conditional compilation? The problem is small but it took time. I just commented out this line. The controller began to respond to commands, but the screen remained white, just blinking briefly after initialization was completed.

To eliminate doubts about the serviceability of the display module, I put together a demo project provided by http://www.lcdwiki.com. Got the image. The display is OK. I tried to apply the solution from the topic to which I referred above. Unfortunately it didn't work for me. Comparing the init procedures used by the lcdwiki and in By PaulyLV, I paid attention to the parameter that determines the data bit depth.

Problem point#2:

write_index(g, 0x3A); 
write_data(g, 0x55);  !

According to the datasheet this defines 16 bits/pixel.  By changing the parameter to 18 bits/pixel (0x66) I achieved the first screen reaction.

It became clear that I was on the right path. Since the data format was changed, it was necessary to adjust the recording function as suggested by PaulyLV.

Problem point#3:

function:

LLDSPEC	void gdisp_lld_write_color(GDisplay *g) {
		 write_data(g, gdispColor2Native(g->p.color));
	}

must be brought to the form:

LLDSPEC	void gdisp_lld_write_color(GDisplay *g) {
    write_data(g, (gU8)((gdispColor2Native(g->p.color) & 0x0003F000) >> 10));
    write_data(g, (gU8)((gdispColor2Native(g->p.color) & 0x00000FC0) >> 4));
    write_data(g, (gU8)((gdispColor2Native(g->p.color) & 0x0000003F) << 2));
	}

And here is the final result, I am satisfied:

[SkyFort]

The post turned out to be big . I'll add it here. Taking into account that the module was obtained from Aliexpress and is widely distributed, I think that this information will help someone else get started with uGFX.

[inmarket]

It sounds like you got the panel working for you in 18bit mode. I am currently using the original code on a Ili9488 in RGB565 mode (16bit) without change. Looking at your photo the board even looks the same!

This is a common problem with the Ili series of controllers. Often chips with the same part numbers behave quite differently depending on the source of the chip. Add to that different ways the panel can be attached to the controller, and then the pixel format you want to use for the application, all mean that the initial sequence often needs to be customised. Seemingly identical boards can sometimes behave differently. I even heard of one case of this happening from a single supplier.

With regard to the reset function, the gTrue was supposed to mean the reset was asserted (i.e active low for most boards). As there were a number of different programmers who wrote the different drivers, for some drivers that meaning got transposed and the gTrue was taken to mean pin high instead. It looks like the ili9488 driver is one of those. It is something we are fixing for uGFX v3 but can't change for v2 without breaking someone's already working code.

Nice job on working it out!