EmbDev.net

Forum: ARM programming with GCC/GNU tools Variable storage and Linker Scripts


von Jim K. (ancaritha)


Rate this post
useful
not useful
I'm using an AT91SAM7A3 to control (among other things) a User Interface
that has a number of different text strings, fonts, a few graphics, etc.
I believe these are currently being stored in RAM, and although I still
have about 10K of RAM left, I'd like to be able to store these in flash
to free up some extra room just incase.

I have a whole lot of things like:
static const char s_szConstRemainingText[] = "Remaining Time %dm";

My question is, where are 'static const' stored and used in the lnker
script?  .text? .data? .bss?

Would I be able to add the __attribute tag to all of these to make them
stored in a specific place that would put them in Flash, and which tag
would I need to use?

Thanks for any help!

von Jim K. (ancaritha)


Rate this post
useful
not useful
I wish I new how to edit posts, so sorry for the double post.

Anywho, I somehow missed
"*(.rodata)                 /* read-only data (constants) */"

So I'm assuming a static const would be stored in .rodata, which I
believe is stored in the ROM.  Suppose I didn't have a static const
though, which attribute tag would I want to use to store stuff in flash?

von Jim K. (ancaritha)


Rate this post
useful
not useful
I was going through the .map file when I ran along the following:

 .bss           0x00202ca0      0xbbc .out/BaoUserInterfaceMgr.o
                0x00202cb8
BaoUserInterfaceMgr::m_nRefreshDisplayTimerHandle
                0x00202ca8
BaoUserInterfaceMgr::m_nCurrentPage
                0x00202ca4
BaoUserInterfaceMgr::m_nDisplayHeight
                0x00202d05
BaoUserInterfaceMgr::m_nLineBlinkState
                0x00202cc4
BaoUserInterfaceMgr::m_szResourcesRemaining
                0x00202ce4
BaoUserInterfaceMgr::m_szFuelCellState
                0x00202cb0
BaoUserInterfaceMgr::m_nPrevButtonState
                0x00202d0e
BaoUserInterfaceMgr::m_nInverseBlinkTimerID
                0x00202ca0
BaoUserInterfaceMgr::m_nDisplayWidth
                0x00202cac
BaoUserInterfaceMgr::m_nNumPages
                0x00202cbc
BaoUserInterfaceMgr::m_nFuelRemaining
                0x00202cb4
BaoUserInterfaceMgr::m_pButtonMgr
                0x00202d04
BaoUserInterfaceMgr::m_bDebugMode
                0x00202d10
BaoUserInterfaceMgr::m_nFuelDisplayState
                0x00202da7                gs_index
                0x00202d11
BaoUserInterfaceMgr::m_nErrorDisplayState
                0x00202d93                gs_string
                0x00202cc0
BaoUserInterfaceMgr::m_nBatteryRemaining
                0x00202d13
BaoUserInterfaceMgr::m_pszCurrentErrors
                0x00202d12
BaoUserInterfaceMgr::m_nNumberOfErrors
 .bss           0x0020385c       0x30 .out/LCD.o
                0x0020385c                LCD::s_nBacklight
                0x0020386c                LCD::s_writeCCb
                0x00203860                LCD::s_nWidth
                0x0020385e                LCD::s_nContrast
                0x00203874                LCD::s_init
                0x00203864                LCD::s_lines
                0x00203862                LCD::s_freezeOn
                0x00203868                LCD::s_nNumLines
                0x00203870                LCD::s_displaySetupCCb
                0x00203861                LCD::s_blinkOn

Between the BaoUserInterfaceMgr variables and the LCD variables is a gap
of 0xB49, almost 3k of space.  Does anyone know what might cause
something like this and how to fix it?

von Jim K. (ancaritha)


Rate this post
useful
not useful
Jim Kaz wrote:
> I was going through the .map file when I ran along the following:
>
>  .bss           0x00202ca0      0xbbc .out/BaoUserInterfaceMgr.o

So later I realized that the 0xbbc here was saying its total size, which
explains for the extra space missing.  Why its taking up this space if
all the functions are declared in the .text and are taking up an equal
amount of space there, I dunno... But on to the next question..

 .text          0x00005588       0x60 .out/InterruptServicer.o
                0x000055b8
InterruptServicer::Interrupt_ID_SYS()
                0x00005588
InterruptServicer::Interrupt_ID_US0()

Interrupt_ID_SYS and US0 are both interrupts (as the name might suggest)
declared in a fashion similar too AT91F_AIC_ConfigureIt(AT91C_BASE_AIC,
AT91C_ID_SYS, INTERRUPT_PRIORITY_SEVEN,
AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL, InterruptServicer::Interrupt_ID_SYS);

In the make file I have the following lines:
RUN_MODE=ROM_RUN
VECTOR_LOCATION=VECTORS_RAM
CDEFS +=  -D$(RUN_MODE) -D$(VECTOR_LOCATION)

Soooooooo shouldn't those interrupts be declared in a RAM section, and
not the flash?


My apologies for the vast amounts of posts I'm making to myself, but I'm
just kinda of posting as I need to know stuff, just so I don't forget to
post it all later, heh.

von Martin Thomas (Guest)


Rate this post
useful
not useful
>Suppose I didn't have a static const
>though, which attribute tag would I want to use to store stuff in flash?

Probably an variable-attribute "section" (see gcc-manual variable
attributes). And place this section inside the linker-script. I have not
tried this for variables but use the section attribute for functions
quite often (i.e. for "RAM-functions").

> In the make file I have the following lines:
> RUN_MODE=ROM_RUN
> VECTOR_LOCATION=VECTORS_RAM
> CDEFS +=  -D$(RUN_MODE) -D$(VECTOR_LOCATION)

The definitions are just "text" (better: expand to macro defintions). I
use these in my WinARM example-template but even if you pass the
defintions to the compiler-frontend (CDEFS) this does not guarantee that
this fill functions as expected the linker-script and the source-code
have to take the defintions into account. My intention with this defines
is to control the placement of the ARM exceptions-vectors not the
Interrupt-Handlers to which they point to. If you'd like to place the
ISRs in RAM too: add a section attribute (this time a "function
attribute) and assign the section. Some of my examples demonstrate this
(look for the RAMFUNC or FASTRUN define).

Hope this helps,
Martin Thomas

von Jim K. (ancaritha)


Rate this post
useful
not useful
Martin Thomas wrote:
> Hope this helps,
> Martin Thomas

Yup!  Thanks Martin.

von Jim K. (ancaritha)


Rate this post
useful
not useful
Martin Thomas wrote:
> The definitions are just "text" (better: expand to macro defintions). I
> use these in my WinARM example-template but even if you pass the
> defintions to the compiler-frontend (CDEFS) this does not guarantee that
> this fill functions as expected the linker-script and the source-code
> have to take the defintions into account. My intention with this defines
> is to control the placement of the ARM exceptions-vectors not the
> Interrupt-Handlers to which they point to. If you'd like to place the
> ISRs in RAM too: add a section attribute (this time a "function
> attribute) and assign the section. Some of my examples demonstrate this
> (look for the RAMFUNC or FASTRUN define).
>
> Hope this helps,
> Martin Thomas

I finally got the time to go investigate your RAMFUNC and FASTRUN
macros.  I was able to get them copied over to and running in my project
and it works like a charm.  Thanks!

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.