R2022022801: code optimization

[jg1uaa]

I saw build log of R2022022801 release (now too old!) on MCUXpresso IDE and I found following codes are compiled with -O0 option.

• drivers/fsl_common_arm.c
• drivers/fsl_dspi.c
• drivers/fsl_notifier.c
• drivers/fsl_pmc.c
• drivers/fsl_rcm.c
• drivers/fsl_rtc.c
• drivers/fsl_uart.c
• source/SeggerRTT/RTT/SEGGER_RTT.c
• source/SeggerRTT/RTT/SEGGER_RTT_printf.c
• source/SeggerRTT/Syscalls/SEGGER_RTT_Syscalls_GCC.c
• source/dmr_codec/codec_interface.c
• source/firmware.c
• source/main.c
• source/semihost_hardfault.c
• source/functions/hotspot.c (*)
• source/functions/sound.c
• source/hardware/SPI_Flash.c
• source/hardware/UC1701_transfer.c
• source/io/rotary_switch.c (*)
• source/interfaces/clockManager.c
• source/interfaces/gpio.c
• source/interfaces/interrupts.c
• source/interfaces/settingsStorage.c
• osa/fsl_os_abstraction_free_rtos.c
• startup/startup_mk22f51212.c

I think some codes can use -Os, especially marked with (*). Is this optimization setting as you expected?
(Now source code tree may be completely different due to supporting MD-UV380, so this topic might be out of date...)

[VK3KYY]

Its likely the current Beta already optimises as many code files as possible.

For unknown rrasons, the firmware did not work correctly if some files were set to be optimised.

This is caused by multiple reasons, including timing problems, and bugs in the manufactur's SDK.
Files related to the CODEC blob in the official firmware also can't be optimised, as the use of the CODEC blob is basically a unavoidable hack


Probably with infinite time and resources spent investigating this, then all files could be optimised, but frankly , life is too short to waste time on this.

[jg1uaa]

Files related to the CODEC blob in the official firmware also can't be optimised, as the use of the CODEC blob is basically a unavoidable hack

I modified codec_interface.c and it runs with -Os optimization. I could not attach the diff here, uploaded it at https://pastebin.com/rXrj2Q4W
I would send PR if the project were on GitHub!

Probably with infinite time and resources spent investigating this, then all files could be optimised, but frankly , life is too short to waste time on this.

Yes, life is too short.

Building OpenGD77 with MCUXpress takes five minutes every time, I have no time to waste (So I use Makefile based build environment still now). I found scanning directories to create Makefile is too slow, does anyone have any tweak to improve build speed?

[jg1uaa]

diff file is at http://uaa.org.uk/gomitext/2023/2023010 ... ace.c.diff

[jg1uaa]

I tested compiling following codes with -Os option on MCUXpressoIDE 11.6.1.
R2022022801 on DM-1801 looks stable, and code size is reduced (_etext at 0x4ad44 -> 0x4a760).

• source/dmr_codec/codec_interface.c (#)
• source/firmware.c
• source/semihost_hardfault.c
• source/functions/sound.c
• source/interfaces/interrupts.c
• source/interfaces/settingsStorage.c
• startup/startup_mk22f51212.c

(#)use diff previous posted

[S58SMS]

What will this code correction make better on FW?

[jg1uaa]

What will this code correction make better on FW?

reducing code size increases a chance to add new feature into small ROM.
reducing running unwanted binary saves battery waste.

I think "-O0 works good, but optimized code does not work" is something trouble is hidden, so fix this improves code/product quality.

[jg1uaa]

source/hardware/SPI_Flash.c needs adding some __DSB() (data synchronization barrier instruction) to use -Os optimization.
diff: http://www.uaa.org.uk/gomitext/2023/202 ... ash.c.diff

Other codes seems to work with -Os...

[jg1uaa]

void_spi_flash_disable() in source/hardware/SPI_Flash.c, set CS=high by PSOR register and immediately configure CS pin as input.
It looks curious. I think CS pin should be always configured as output.

Here is new diff, included previous __DSB() tweak. http://www.uaa.org.uk/gomitext/2023/202 ... h.c-2.diff

[VK3KYY]

void_spi_flash_disable() in source/hardware/SPI_Flash.c, set CS=high by PSOR register and immediately configure CS pin as input.
It looks curious. I think CS pin should be always configured as output.

Here is new diff, included previous __DSB() tweak. http://www.uaa.org.uk/gomitext/2023/202 ... h.c-2.diff

Read the data sheet on the flash chip

FYI.

I will not be merging any of your changes, because

1. Any changes require a huge amount of testing, which is all done by volunteers who have the 5 or more different hardware versions supported.
2. Your changes don't fix any known bugs
3. Your changes don't add any new features
4. Your changes could potentially add bugs related to code timing