Sign in

username:

password:



Not a member?

Search basicx



Search tips

Subscribe to basicx



basicx by Keywords

Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | BasicX | Again: Task Stacks Question

Discussion forum for the BasicX family of microcontroller chips.

Again: Task Stacks Question - George Chamilothoris - Feb 20 5:58:00 2001

Dear Netmedia people (Jack, Chris et al.)
A week ago i posted a call for help and information. It has failed to catch
your attention, for some reason. So i am repeating it here and address it
directly to you. Please respond.
Regards,
George.
===================================== earlier message, digest #503
Hello BXers,
I am looking for some insight on how tasks use the stack arrays
allocated to them. I have tried to run the taskexample on a BX24 - no
succes. I raised the stack lenghts to 50 or more - it ran OK.
Then i experimented with different lengths as descibed in the
documentation.
I am getting some outcomes i cannot explain. For instance: when i
print the stack contents i get different results in diferrent runs.
This may be because the instructions that print the stack run after
the tasks terminate, by which time the stack memory has been recycled
and put to use by some
other commands.
Then again, how can we really check the contents of the stack
precisely after a task terminates? And why should resetting the
processor result in diferent parts of the stack array beeing written
upon? (unless the operating system shifts memory addresses with every
run in order to spread eeprom wear more thinly).
Well, i am certainly missing something elementary here - so, please,
could someone explain?
Thanks in advance.
George Chamilothoris





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )


Re: Again: Task Stacks Question - Jack Schoof - Feb 20 13:23:00 2001


-----Original Message-----
From: George Chamilothoris <>
To: <>
Date: Tuesday, February 20, 2001 4:04 AM
Subject: [BasicX] Again: Task Stacks Question >Dear Netmedia people (Jack, Chris et al.)
>A week ago i posted a call for help and information. It has failed to catch
>your attention, for some reason. So i am repeating it here and address it
>directly to you. Please respond.
>Regards,
>George.
>===================================== earlier message, digest #503
>Hello BXers,
>I am looking for some insight on how tasks use the stack arrays
>allocated to them. I have tried to run the taskexample on a BX24 - no
>succes. I raised the stack lenghts to 50 or more - it ran OK.
>Then i experimented with different lengths as descibed in the
>documentation.
>I am getting some outcomes i cannot explain. For instance: when i
>print the stack contents i get different results in diferrent runs.
>This may be because the instructions that print the stack run after
>the tasks terminate, by which time the stack memory has been recycled
>and put to use by some
>other commands.

Stack usage will be dependent on timer ticks and how your program threads
through the processes that it needs to do.

>Then again, how can we really check the contents of the stack
>precisely after a task terminates? And why should resetting the
>processor result in diferent parts of the stack array beeing written
>upon? (unless the operating system shifts memory addresses with every
>run in order to spread eeprom wear more thinly).
>Well, i am certainly missing something elementary here - so, please,
>could someone explain?
>Thanks in advance.
>George Chamilothoris When task2 finishes, the memory in the stack provided to that task should
not now be used. You should be able to look at that stack and see where the
highest utilized memory location occured. I usually start by having the
main program fill the bytes of the task stack with something common like 99.
Then when the task is finished, I look from the end of the stack backwards
to see where the first non-99 byte occured. This will let you know the
extent of the stack for just that run. It could be more or less depending
on the path your program takes when running. Looking at the stack this way
is not a guarantee that you will find the largest stack utilization, but it
will at least give you a guide.

I do not understand why resetting should cause different parts of the stack
to be written upon. If you perform my filling of the bytes to be 99 from
the main program, you should find similarities between runs.

Jack


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )