> 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.
> 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.
Reply by CBFalconer●June 2, 20072007-06-02
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."
>> 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."
Reply by Hawker●June 1, 20072007-06-01
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
Reply by CBFalconer●June 1, 20072007-06-01
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.
> 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.
Reply by Not Really Me●June 1, 20072007-06-01
"Hawker" <Hawker{removethispart}@ashevillecommunity.org> wrote in message
news:5c95miF2vlidlU1@mid.individual.net...
> Forgive me for I have broken engineering rule 1037.42.878....
> For I am a hardware designer trying to write software.
>
> Now that we have that out of the way...
>
<SNIP>
Any hardware designer that can't write basic code to help debug their
designs should not have a job!
Thanks for learning. Keep up the good work.
Scott
Reply by Hawker●June 1, 20072007-06-01
On 6/1/2007 3:53 AM, The digits of Yvan BOURNE's hands composed the
following:
> "Hawker" <Hawker{removethispart}@ashevillecommunity.org> a �crit dans le
> message de news: 5c95miF2vlidlU1@mid.individual.net...
>> Forgive me for I have broken engineering rule 1037.42.878....
>> For I am a hardware designer trying to write software.
>>
>> Now that we have that out of the way...
>>
>> I am using CW 5.1 and targeting a HCS09AW16
>> If in my global var declaration section I have.
>> unsigned char GLOBAL_VAR = 0x00;
>> When I run the app GLOBAL_VAR is sometimes 00, but more often than not
>> something random and not as assigned.
>>
>> If I have
>> unsigned char GLOBAL_VAR = 0x00;
>> ........
>> void main(void) {
>> GLOBAL_VAR = 0x00;
>> .....
>> }
>>
>> Everything works fine.
>> It seems I shouldn't need
>> GLOBAL_VAR = 0x00;
>>
>> What am I missing?
>>
>> Thanx
>> Hawker
>
>
>
>
> Hi,
> You have to use the ANSI Initialization when you're creating your project.
> All the RAM area will be clear to zero BEFORE your main function, your
> future global variables and your future stack (local variables).
>
> Yvan
> http://www.ybdesign.fr
>
>
But wouldn't the fact that I assign the var to 0x00 when defined over
ride that need? 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.
Reply by Hawker●June 1, 20072007-06-01
On 5/31/2007 9:55 PM, The digits of Ali's hands composed the following:
> Maybe the name space conflict, use watch window to figure out the
> exact problem. Did you try to use name other than GLOBAL_VAR? I've
> never experienced such problem with CW.
Global Var was a made up name to simplify my explanation and not exactly
what I am doing.
The reality is I am having this issue with a few global vars.