CodeWarrior not initializing Vars

Hawker wrote:
> On 6/1/2007 3:53 AM, The digits of Yvan BOURNE's hands composed the 
> following:

>> All the RAM area will be clear to zero BEFORE your main function, your 
>> future global variables and your future stack (local variables).

> But wouldn't the fact that I assign the var to 0x00 when defined over 
> ride that need? 

No.  Because that is not actually you assigning a value to the variable. 
  That's you telling the start-up code to _initialize_ the variable with 
that value.  Which means if you tell the start-up code not to do the job 
required of it by the C language, then the job won't be done.

> I'm using the quick start up, not ANSI because I need 
> the processor to start VERY fast so I want as little overhead as possible.

Well, you got exactly what you asked for --- computer have been known 
for that since before I was born.

You didn't quite get what you wanted, granted.  That happend because you 
didn't quite understand what you asked for.

Hans-Bernhard Br�ker wrote:
> Hawker wrote:
> 
... snip ...
> 
>> But wouldn't the fact that I assign the var to 0x00 when defined
>> over ride that need?
> 
> No.  Because that is not actually you assigning a value to the
> variable.  That's you telling the start-up code to _initialize_
> the variable with that value.  Which means if you tell the
> start-up code not to do the job required of it by the C language,
> then the job won't be done.

One method of initializing static variables is by loading them from
the executable file.  In embedded, you probably don't have such a
file, so initialization is not done on a restart.  In other cases
the start-up code may zero that memory.  If you restart (under a
debugger) that code isn't exercized.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

On 6/1/2007 4:41 PM, The digits of Hans-Bernhard Br�ker's hands composed 
the following:
> Hawker wrote:
>> On 6/1/2007 3:53 AM, The digits of Yvan BOURNE's hands composed the 
>> following:
> 
>>> All the RAM area will be clear to zero BEFORE your main function, 
>>> your future global variables and your future stack (local variables).
> 
>> But wouldn't the fact that I assign the var to 0x00 when defined over 
>> ride that need? 
> 
> No.  Because that is not actually you assigning a value to the variable. 
>  That's you telling the start-up code to _initialize_ the variable with 
> that value.  Which means if you tell the start-up code not to do the job 
> required of it by the C language, then the job won't be done.
> 
>> I'm using the quick start up, not ANSI because I need the processor to 
>> start VERY fast so I want as little overhead as possible.
> 
> Well, you got exactly what you asked for --- computer have been known 
> for that since before I was born.
> 
> You didn't quite get what you wanted, granted.  That happend because you 
> didn't quite understand what you asked for.

Gotcha.
Now I think I understand. I think I misunderstood a C command in 
essences. You are right. Unfortunatly given client schedules and budgets 
I more often then not have to just dive into a tool and guess than take 
the time to really get to know the tool. Then there is the issue of what 
disty owns a project (AKA politics). For example when it is an Avnet 
project we use TI MPS430s or ADI Blackfin, but this was a Future project 
so we had to use something else - Mot. It has been several years since I 
put a Mot - err Freescale processor on a board. Infact it was Motorola 
still last time.

Course I was always taught back in the Pascal days that defining a var 
and assigning it a value in the same place was not good coding practice 
anyway so that just means I need to assign a value to a var before I use 
it the first time. Not a big deal really.

Thanx

CBFalconer wrote:
> Hans-Bernhard Br�ker wrote:

>> Which means if you tell the start-up code not to do the job
>> required of it by the C language, then the job won't be done.

> One method of initializing static variables is by loading them from
> the executable file.  In embedded, you probably don't have such a
> file, so initialization is not done on a restart.

I'm surprised you would jump to such a conclusion.  The method is just 
the same in embedded, except instead of an executable file on some file 
system you have a code image with some extra segments sitting in flash 
or ROM.   The copying is basically a variant of "memcpy", i.e. it copies 
an image of the entire set of initial values from ROM to their position 
in RAM on start-up.

What the OP did was turn off an option in the tools described as 
"ANSI-compliant startup code".  Well, what that startup code would have 
done for him (if he hadn't turned it off) is to perform initialization 
of static variables as defined by the language, and expected by the OP. 
  I.e. he told the tools he didn't want initialization to take place, 
and ended up being surprised that variables weren't initialized.  As 
Homer Simpson would put it: "Duh."

Hans-Bernhard Br�ker wrote:
> CBFalconer wrote:
>> Hans-Bernhard Br�ker wrote:
> 
>>> Which means if you tell the start-up code not to do the job
>>> required of it by the C language, then the job won't be done.
> 
>> One method of initializing static variables is by loading them from
>> the executable file.  In embedded, you probably don't have such a
>> file, so initialization is not done on a restart.
> 
> I'm surprised you would jump to such a conclusion.  The method is just
> the same in embedded, except instead of an executable file on some file
> system you have a code image with some extra segments sitting in flash
> or ROM.   The copying is basically a variant of "memcpy", i.e. it copies
> an image of the entire set of initial values from ROM to their position
> in RAM on start-up.
> 
> What the OP did was turn off an option in the tools described as
> "ANSI-compliant startup code".  Well, what that startup code would have
> done for him (if he hadn't turned it off) is to perform initialization
> of static variables as defined by the language, and expected by the OP.
>   I.e. he told the tools he didn't want initialization to take place,
> and ended up being surprised that variables weren't initialized.  As
> Homer Simpson would put it: "Duh."

Not necessarily.  For example, the power on reset code clears all
memory and copies the code and non-zero initialized data over.  Now
the system runs.  Halting, and restarting at main, doesn't clear
memory.  All we know is that he is using an 'embedded system'.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:

> Not necessarily.  For example, the power on reset code clears all
> memory and copies the code and non-zero initialized data over.  Now
> the system runs.  Halting, and restarting at main, doesn't clear
> memory.

Which is why one should never just restart at main(), and that's not 
what any self-respecting tools would do.  Not in embedded systems, and 
not in hosted programming either.  You restart at the actual start-up 
vector, which will eventually call main() after all initialization has 
been done.  Tools will sometimes make it _apper_ like they restarted 
from main(), by running all the way to the beginning of main(), and 
stopping there.  But that's an option that can always be turned off.

In embedded toolchains, the re-start function is usually called "reset", 
because that's what it does: jump to the reset vector.  Some embedded 
debuggers offer an extra function to more completely simulate an actual 
hardware reset, for which they re-load all registers with their reset 
values.

Hans-Bernhard Br�ker wrote:
> CBFalconer wrote:
> 
>> Not necessarily.  For example, the power on reset code clears all
>> memory and copies the code and non-zero initialized data over. 
>> Now the system runs.  Halting, and restarting at main, doesn't
>> clear memory.
> 
> Which is why one should never just restart at main(), and that's not
> what any self-respecting tools would do.  Not in embedded systems, and
> not in hosted programming either.  You restart at the actual start-up
> vector, which will eventually call main() after all initialization has
> been done.  Tools will sometimes make it _apper_ like they restarted
> from main(), by running all the way to the beginning of main(), and
> stopping there.  But that's an option that can always be turned off.
> 
> In embedded toolchains, the re-start function is usually called "reset",
> because that's what it does: jump to the reset vector.  Some embedded
> debuggers offer an extra function to more completely simulate an actual
> hardware reset, for which they re-load all registers with their reset
> values.

IF everything is optimally set-up.  We don't know much about the
OPs systems, so I just stuck out another possibility.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com