Bug Report: GLCD SSD1963 component generates [-Woverflow] warnings and fails on PIC32MX795F512L

[r_teixeir]

Hi Martin,
Thank you for your response and for taking the time to look into the files.
I tested the modified project on the real hardware, but unfortunately, the physical screen and backlight are still completely dead. To find out why, I compiled the project and audited the generated raw .c file (SSD1963_Pic32_New_Teste_Component.c).
The code analysis proves that Flowcode 11 is completely ignoring our custom modifications. Inside LCD_Write_Reg and LCD_Write_Data, the compiler is still forcing the original, slow software-driven bit-banging routines (SET_PORT_PIN loops checking bit by bit) instead of deploying our hardware PMP instructions.
Looking at the generated code header, I found the exact reason why the bit-banging stays active: the compiler keeps fetching the source from the default system directory:
:Location: C:\ProgramData\MatrixTSL\FlowcodeV11\Components\gLCD_SSD1963.fcpx
If I try to manually delete the old gLCD_SSD1963 component from my 2D canvas to force the application to rely exclusively on your new file, the flowchart macros instantly lose their reference, breaking the application with an "Unknown or missing component" error.
It seems that because the high-level drawing macros still inherit their structure from the original driver background, Flowcode's code generator forces the default bit-banging library into the final build.
What should be the next step to completely decouple this project from the native driver cache so our custom register-level modifications can finally take over?
Best regards,
Rod

[mnfisher]

... The modified component code imports glcd_ssd1963 (parallel) and is using this for the read & write routines (and others).

So modifying this would be one way to go.

Alternatively - as a test - write a tiny component or program to test the display. This doesn't need to be very large - it needs WriteData, WriteCmd (and the underlying code to output). and Initialise (this is the key to the different displays - and after that 'most' use a very similar structure - SetWindow - WriteData..)

However - for a first step - you want to check that something is written to the display and usually initialising it and enabling the backlight is enough (and the display may be filled with random stuff)

This is for a different display (ssd1306) - but shows how little you need to add (and this has some print routines...)

Martin