Re: Bug Report: GLCD SSD1963 component generates [-Woverflow] warnings and fails on PIC32MX795F512L
Posted: Sun Aug 02, 2026 11:12 pm
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
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