I'm trying to adapt source code and create a makefile accordingly to the explanation below. The code used to be compiled with gcc 3.3.1, used at the time with Keil (just as IDE), and also *.s and *.ld files from Keil. Currently, I have gcc 4.3.3 compiler and Eclipse IDE, still the same *.s and *.ld files from Keil and I also had to create a makefile. The makefile was created accordingly with the previous compiler/assembler control strings from Keil options screen. Although, some strings had to be added or changed to match the new compiler version. The source code was also adapted to match the new compiler version. The result is that I can only get "some life signals" with no optimization level (with gcc 3.3.1 I was using O1), but: - The memory occupied is almost 50% larger then with gcc 3.3.1 compilation and Keil IDE. - The program runs something like 4 times slower (related with PLL?) - Not everything works, such as the LCD. The uC is the LPC2106 and I'm using Yagarto toolchain. Any clues? Thanks in advance! danr
First of all search for missing volatiles. Most but not all problems seen when higher optimization levels are enabled are caused by missing volatiles (in empty loops or when accessing data from ISRs and the "main-thread"). Maybe the LCD does not work since delay-loops are used which get "optimized away". Try to add volatile to the loop-counter declaration if not already there. Do you used stdio? IRC the Keil 3.3.1 GNU package uses a different libc and different lowlevel interface than most other GNU packages which usually use newlib (like Yagarto). The PLL-configuration should be independent from any optimization settings. How are ISRs declared? Do you use the GCC IRQ attribute, nacked attribute with inline-assembler entry/exit code or an assembler-wrapper for IRQs?
Regarding 'volatile' read this: http://www.embedded.com/columns/beginerscorner/9900209 GCC 4.x performs stronger optimisation than 3.x. I would be surprised if it optimised away a variable access when no optimisation was set. That said, I would not be surprised if some latent bug or flaw in your code manifested itself differently when built with a diferent compiler - you'll just have to debug it, because the problem is most likly with your code rather then the tool. Are you using the same CRT start-up code? If not, does the new code set the PLL up differently? I have seen vastly differing performance between newlib builds for code using floating-point. You should avoid using floating-point in any case. Clifford
Hi, @mthomas All the behaviours mentioned above are for no optimization level. stdio is being used. ISR attributes are declared like this:
1 | |
@clifford I'm using the same start-up code (*.s) and the same file for memory and sections definitions (*.ld) as before. Thanks you both, I've now some topics to explore. Cheers.