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

[r_teixeir]

Dear Martin and the MatrixTSL Engineering Team,
I would like to start by thanking Martin for his invaluable conceptual guidance. Your suggestion to strip down the workflow and focus exclusively on the core initialization routines (WriteCmd, WriteData, and backlight enabling)—as shown in your minimal template—gave us the exact direction we needed.
Following that design philosophy, we were resourceful enough to source Lucio's open-source hardware implementation files from GitHub (luciodj/PIC32MikromediaPlusCode). We carefully adapted his core display timings and register sequences to compile seamlessly under the Microchip XC32 toolchain within Flowcode V11. By merging your strategic guidelines with these adapted open-source parameters, we successfully drove the SSD1963 on the Mikromedia Plus PIC32MX7 board using a high-performance 16-bit PMP parallel link.
1. The Breakthrough (Hardware Status)After performing a full chip erase and flashing our standalone Flowcode V11 program, we achieved a massive milestone: the hardware initializes perfectly, the internal SSD1963 PWM backlight fires up reliably at maximum intensity, and our direct pixel flood test successfully drives the display, drawing a solid block on the real screen.This proves that our adapted low-level C timing sequences, JTAG overrides, and atomic 16-bit PMP writes are 100% physically accurate and stable on the actual hardware.
2. Where We Need MatrixTSL Expertise (The Simulation Stagnation)While our hardware implementation is completely functional, we have hit a wall attempting to make this custom workflow compatible with Flowcode V11's graphic simulation workspace.We decoupled the pins of a native gLCD_SSD1963 component by setting them to Unconnected to shield our high-speed 16-bit parallel bus from slow bit-banging overwrites. We then attempted to run simulation-only macros wrapped inside MX_SIM condition variables. Unfortunately, the PC simulation engine refuses to render the graphics updates, leaving the display object completely white during playback. It appears that feeding direct data streams causes the software's workspace render pipeline to stall or miss the screen update hooks.
3. The Next Step (Our Main Goal for Simulation and Physical Execution)Since we have already conquered the hardest part—achieving successful standalone hardware execution by smartly adapting open-source parameters to the XC32 compiler—our goal now is to establish a seamless workflow for both simulation testing and actual physical modification.Now that our core hardware initialization is fully operational, it should be highly straightforward to build upon the existing software framework. We are escalating this to the MatrixTSL team to ask for direct guidance on how to leverage the pre-developed Component Macros (such as print, line, and shape drawing functions) already built into Flowcode's library.
We want to be directed on how to correctly route these native high-level visual commands through our verified 16-bit parallel driver so that they work flawlessly both in the PC simulation workspace and when compiling to modify the actual physical screen, completely preventing the software from triggering any low-level bit-banging routines or pin overwrites.I am attaching our working project .fcfx file along with physical photos of the successful initialization for your technical review. We look forward to working with your engineering team to establish a proper development workflow for this hardware profile.
Best regards,
Rod

[BenR]

Hello,

I've taken your initialisation and your data / register commands and put them into a custom version of the SSD1963 component source.

You can add the component to your copy of Flowcode by copying this file here: C:\ProgramData\MatrixTSL\FlowcodeV11\Components

gLCD_SSD1963_Custom.fcpx

(18.31 KiB) Downloaded 2 times

The programdata folder is hidden by default so copy and paste the address into the file explorer address bar to get there.

Restart Flowcode and the new component should appear in the menu.

Screenshot 2026-09-21 111409.png (13.48 KiB) Viewed 178 times

Hopefully this should allow your display to work on hardware and also to allow it to be part of the simulation and display creator WYSIWYG eco systems.

https://www.flowcode.co.uk/wiki/index.p ... ay_Creator


Here is the component source if you want to make any additional changes, just use the File -> Export -> Export this project as a component. It should default to the right place on your hard drive.

GLCD_SSD1963_Custom.fcfx

(207.91 KiB) Downloaded 2 times

(view online)