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

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 )

-----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

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