Hello!

I use Eclipse, Yagarto ELF tool chain and a AT91SAM7X256.

My overall binary size is ~40 k and the linker script is named ROM.
In linker script it says that .text (actual code) goes into flash, while .bss and .data (unitialized / static data) are put to RAM.

This means, that code execution is fetched from Flash, which is quite slow compared to RAM, right?
But isnt't reading from flash awkward slow, so that CPU is always waiting for some code to be fetched?

Does running the whole prog from RAM instead of ROM _can_ give a significant boost?
What are disadvantages of running from RAM compared to ROM?

Thank you for reading,
FocusPaul

That depends on the MCK. as long as you don't need flash wait states the execution speed is similar.


as long as you have enough RAM there is no disadvantage.

regards
gerhard

Thank you!

I've read some more and under 19.2.2 it says, that up to 3 wait states are configured. At 47,923 MHz we need 1 waitstate, so that every access takes twice as long as RAM access - if accessing sequential memory locations, which are optimized by prefetch mechanism.

One last question: If I'd like to use RAM instead of ROM, my startup script has to load everything from Flash to RAM before doing the remap?

Are there any linker scripts/sources available yet?

One problem with running from RAM is that errant pointer or code, can trash the code you are attempting to run.

Consider splitting the app so you have a boot loader which is separate, and then compiling your app code with RAM addresses specified in your app linker script, ie shrink the RAM allocation, and redefine the ROM/FLASH address and size to that which you have carved out of the usable RAM. Subsequently you burn this application/payload code into the FLASH address the boot loader expects to find it. The boot loader copies this whole payload into RAM and jumps to it.

Another alternative is to use #pragma's or whatever, to direct the compiler to place specific subroutines into RAM.

Finally consider if your subroutine will be faster as 32-bit ARM code, rather than 16-bit Thumb. Remember Thumb#1 has a much narrower view of the register file, and the compiler can manage registers much less efficiently. You also lose conditional instruction execution features.