1. Home
  2. Embedded Programming
  3. Uninitialized Variables in ARM RealView Tools

Uninitialized Variables in ARM RealView Tools

Howdy Y'all :

I just ported some code from Keil CARM to RealView V3 (whilst RV produces way more efficient code, the whole RV toolchain seems somewhat overblown - but that's another story).

I have an outstanding issue with locating arrays and variables into a non-volatile RAM and stopping the start up library from initializing these objects (i.e. the thing one did with #pragma USERCLASS and #pragma NOINIT in CARM)

Here's what I understand :

1 - Use #pragma arm section zidata = "NVRAM" 2 - Use a scatter description file to create an execution view region located at the correct place and use the UNINIT qualifier when defining it

Now, this works just fine for arrays bigger than 8 longs in size. For single variables and smaller arrays, the compiler includes them in rwdata rather than zidata (even though there is no explicit initializer in the source code)

Adding #pragma arm section rwdata = "NVRAM" to the source causes these objects to be located within the NVRAM, but still they are zeroed at start up.

At the moment my kludge is to make all my NVRAM objects big enough to find their way into zidata - if I can't find a better solution I'll try a single structure containing all my NV stuff.

Does anybody know how to a) make the compiler put all non-initialized objects (regardless of their size) in zidata or b) force rwdata objects to not be initialized ?

Thanks Gary

DOes antbody know if there's a way of achieving what the __task keyword did in CARM in RV ?

Reply to
Gary Pace
Loading thread data ...

8 bytes you mean, not 8 longs. Indeed the compiler groups objects together depending on their size. There is little difference between initialized and zero initialised data: int x means int x = 0 and so is treated like int x = C. Due to the compression algorithms used there is no cost in having zero and non-zero initialised data in the .data section.

Indeed, rwdata is always initialised by definition. Note you may prefer the GNU attribute syntax as that is closer to the CARM pragma.

A single structure is probably best if you really need to avoid initialization.

The FAQ deals with this, see

formatting link

The question is why do you want to avoid initialisation of small data in the first place? It's understandable if you have huge arrays (megabytes) as then startup could take a noticeable amount of time on a slow CPU, but for small data it doesn't matter.

You mean leaving out the entry/exit sequence? In what way is that useful?

Wilco

Reply to
Wilco Dijkstra

Thanks for the response. The faq completely describes what I am trying to do.

I need to avoid initialization because the objects are non-volatile (saved at power down), obviously, being cleared back to zero by the compiler at power up doesn't work

Leaving out the entry / exit sequence is useful within my scheduling code. Some functions enter but never exit, they either resume a pre-empted task or begin a new task. I have to add code (a call to an embedded assembler function) to reset the stack in this case. With CARM I just declared them as __task and this wasn't necessary. Also, obviously, task entry functions don't need the preamble. This isn't a problem as such, it was just a feature in CARM that's not there in RV

Reply to
Gary Pace

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.