SV: [Icc-avr] Freeing static variables

David Brown david_brown at hotpop.com
Mon Oct 22 13:17:44 PDT 2007


Richard wrote:
> If you really must. Don't blame me if your program gets non-readable:
> 
> In a .s file,
>         .area bss
> _name1::
> _name2::
> ...
>         .blkb 2
> 
> 
> now in C,
> extern unsigned name1, name2;
> 

It would be safer and more readable (or at least less unreadable!) to 
use a union - sharing memory is one of the reasons it exists.  If it 
makes your code hard to read because your variables are now part of a 
union of structures, you can use #define to give short names.

Thus instead of an int called "calibrationCount", you have a union:

union {
	struct {
		int calibrationCount_;
		// ...
	} calData;
	struct { ... } runData;
} shared;

with access as shared.calData.calibrationCount_, or with

#define calibrationCount shared.calData.calibrationCount

and access as before.


#define names can also be used to give a single variable two completely 
different names, so that your code can look normal, but share the data 
space.  They can also be used with typecasts to share data with 
different types:

int calibrationCount;
#define runByteA (*((unsigned char*) &calibrationCount))
#define runByteB (*(((unsigned char*) &calibrationCount) + 1))


Of course, you code gets a bit messy, and it's hard to debug or to 
inspect the generated assembly.


And yes, malloc will work (or should - I've never used it with iccavr). 
  But it's seldom advisable to use dynamic memory on a small micro in an 
embedded system - only use it if it is the least bad solution to your 
problem.

mvh.,

David



> Both will have the same address.
> 
> Yes, malloc does work
> 
> At 02:38 AM 10/22/2007, Bengt Ragnemalm wrote:
>> The purpose is just to use less RAM. My problem is that I must run this
>> during the normal execution of the full program and not just prior 
>> starting.
>>
>> I can see several solutions to this but none that I can call well written
>> code.
>>
>> Would malloc even work in ICCAVR? I have no idea how it works but I am 
>> aware
>> of the function.
>>
>> /Bengt
>>
>> > -----Ursprungligt meddelande-----
>> > Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr-
>> > bounces at imagecraft.com] För David Brown
>> > Skickat: den 22 oktober 2007 11:27
>> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need
>> > tosubscribe to icc-announce if you are a member of this.
>> > Ämne: Re: [Icc-avr] Freeing static variables
>> >
>> >
>> > By their very definition, "static" variables are allocated a fixed
>> > address in memory by the linker, and cannot be "freed".  You have to
>> > figure out why you might want to re-use the space they take - if you 
>> are
>> > using heap-allocated dynamic memory (a terrible idea on most embedded
>> > systems!), for example, then you could use malloc and free for the
>> > calibration data.  If you need it for other specific purposes after
>> > calibration, you could do something like define a union containing a
>> > calibration data structure and a run-time data structure, as long as 
>> you
>> > are careful to track which one is valid.
>> >
>> > mvh.,
>> >
>> > David
>> >
>> >
>> > Bengt Ragnemalm wrote:
>> > > Is there any intelligent way to release the memory used by a static
>> > > variable?
>> > >
>> > >
>> > >
>> > > I have a calibration routine that is run the first loops of the 
>> program.
>> > > If the calibration was done in a separate function , I could just use
>> > > temporary variables but as this is run in the entire normal 
>> program loop
>> > > I can not see any other way than to use statics for my temporary
>> > > variables in the calibration routine.
>> > >
>> > >
>> > >
>> > > But after the calibrating is done, it would have been nice to free 
>> the
>> > > space used by the static variables.
>> > >
>> > >
>> > >
>> > > Maybe there is some better way to do this so any suggestions are
>> > welcome.
>> > >
>> > >
>> > >
>> > > Regards,
>> > >
>> > > Bengt
> 
> // richard (This email is for mailing lists. To reach me directly, 
> please use richard at imagecraft.com)
> 
> _______________________________________________



More information about the Icc-avr mailing list