R2022022801: code optimization

Discussions related to the firmware code development
jg1uaa
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

R2022022801: code optimization

Post by jg1uaa » Sun Jan 08, 2023 9:47 am

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
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: R2022022801: code optimization

Post by VK3KYY » Sun Jan 08, 2023 8:04 pm

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
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

Re: R2022022801: code optimization

Post by jg1uaa » Mon Jan 09, 2023 6:45 am

VK3KYY wrote:
Sun Jan 08, 2023 8:04 pm
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
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

Re: R2022022801: code optimization

Post by jg1uaa » Mon Jan 09, 2023 11:00 am


jg1uaa
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

Re: R2022022801: code optimization

Post by jg1uaa » Tue Jan 10, 2023 12:36 pm

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
Posts: 153
Joined: Mon Dec 20, 2021 8:00 am

Re: R2022022801: code optimization

Post by S58SMS » Thu Jan 12, 2023 7:24 am

What will this code correction make better on FW?

jg1uaa
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

Re: R2022022801: code optimization

Post by jg1uaa » Thu Jan 12, 2023 8:38 am

S58SMS wrote:
Thu Jan 12, 2023 7:24 am
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
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

Re: R2022022801: code optimization

Post by jg1uaa » Thu Jan 12, 2023 8:44 am

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
Posts: 18
Joined: Mon Jun 28, 2021 10:41 am

Re: R2022022801: code optimization

Post by jg1uaa » Fri Jan 13, 2023 1:13 pm

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
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: R2022022801: code optimization

Post by VK3KYY » Sat Jan 14, 2023 12:46 am

jg1uaa wrote:
Fri Jan 13, 2023 1:13 pm
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

Post Reply