Migrating code from legacy display to new displays

[negative13]

Hi,

My company has been using the uLCD-32PT-GFX for the past few years (bought ~100 just before they got replaced by the 32PTU and we are finally getting to the end of our stock).
Since these displays are no longer available, we are migrating to the uLCD-32PTU and need to migrate all of the 4XE/4FN that run from the display module's SD card.

I would like to automate this process somehow since we have a lot of executables that would need to be recompiled.

Is this just a simple recompile with the appropriate #platform definition or are there anything else under the hood that the IDE performs when specifying the target platform?
Doing this one at a time through the IDE would be awkward and tedious.

If the #platform definition is all that's required, then I could potentially just run a script that replaces the #platform definition in all the source files and then recompiles them with the command line compiler.

Thanks in advance!

[ESPsupport]

I would say, for a uLCD-32PT to uLCD-32PTU migration you don't even need to recompile, the executables should work without it.

You should be able to change it with a script and use the batch compiler if you really wanted to.

Maybe just use the script and wait til 'maintenance' recompiles them.

Of course you will need to test properly. eg has a PmmC revision fixed a bug that was 'exploited' in your code? which I/O lines are you using? (Some revisions of the PTU has some of the I/O pins 'used elsewhere')

[negative13]

Thanks for the quick reply!

So the #platform definition is inconsequential for these two displays?
What exactly does the #platform definition specify?
Is it actually relevant to the compiled code that EVE runs or is it just a flag for the IDE to present the appropriate tools/options (e.g. the nice little image of the display on the side)?
Does the PmmC take care of all the abstraction and all executables are cross-module (assuming it's the same chip and not trying to display an image larger than the resolution of the display)?

We use all the GPIO pins. We are currently testing on HW REV 13.0 which is supposed to have the I/O lines as GPIO by default instead of their other use (e.g. Frame Mark, Battery Status, etc.) so hopefully that won't be an issue.
No exploited bugs, more of workarounds for really old code that dealt with quirks of the language and internal functions at the time.
Stuff from back when 4DGL's switch statements were buggy and had to substitute if-elseif statements instead and back when mode 1 for gfx_LoadImageControl was buggy when loading multiple image controls so things had to be loaded with mode 0 instead.

[ESPsupport]

The #platform statement tells the compiler about the processor (Goldelox, Picaso, Diablo) and hence the functions and 'constants' applicable to the processor. At the model level it also defines constants applicable to that display (eg the registers on the physical display). Workshop uses it for syntax highlighting and the like. The display image is defined in the .4dViSi or .4dGenie file.

The 32PT and PTU use an identical file.