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

Good evening, I am pleased to successfully multitask within a few minutes of trying, this system is very straightforward and simple! However, I lack understanding of the following: When declaring stacks, the total cannot exceed 400bytes due to RAM limitations. True so far? When attempting more, I get an error message, so this is true as far as I can tell. From the manual: "A simple task with no local variables, simple equations and comparisons, and no subprogram calls, could get away with a stack as small as 32 bytes. Other complex tasks might need more than 1000 bytes of stack space." So how can I assign a task 1000 bytes when the max available is 400bytes--Or is this saying I can't have a stack that large, and is worded unclearly? Thank you for your time and assistance. Have a pleasant evening, Paul

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

> From: "Paul J. Csonka" <> > [...] > From the manual: > "A simple task with no local variables, simple equations > and comparisons, and no subprogram calls, could get away > with a stack as small as 32 bytes. Other complex tasks > might need more than 1000 bytes of stack space." > > So how can I assign a task 1000 bytes when the max > available is 400bytes--Or is this saying I can't have a > stack that large, and is worded unclearly? [...] It's just that different BasicX systems have different amounts of RAM, so it depends on the system. BX-24 systems have 400 bytes, which is the upper limit. By contrast a BX-01 can have up to 64 KBytes of RAM, so multi-KByte stacks are realistic on those systems. -- Frank Manning -- NetMedia, Inc.

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

Aha, I see. Makes perfect sense, sometimes I forget the manual is not just for the BX-24! Thank you for your help again, Frank. Have a pleasant evening,Paul On Sun, 13 Feb 2000, Frank Manning wrote: > From: "Frank Manning" <> > > > From: "Paul J. Csonka" <> > > [...] > > From the manual: > > "A simple task with no local variables, simple equations > > and comparisons, and no subprogram calls, could get away > > with a stack as small as 32 bytes. Other complex tasks > > might need more than 1000 bytes of stack space." > > > > So how can I assign a task 1000 bytes when the max > > available is 400bytes--Or is this saying I can't have a > > stack that large, and is worded unclearly? [...] > > It's just that different BasicX systems have different amounts of RAM, so it > depends on the system. BX-24 systems have 400 bytes, which is the upper > limit. > > By contrast a BX-01 can have up to 64 KBytes of RAM, so multi-KByte stacks > are realistic on those systems. > > -- Frank Manning > -- NetMedia, Inc. > --------------------------- ONElist Sponsor ---------------------------- > > Get what you deserve with NextCard Visa. Rates as low as 2.9 percent > Intro or 9.9 percent Fixed APR, online balance transfers, Rewards > Points, no hidden fees, and much more. Get NextCard today and get the > credit you deserve. Apply now. Get your NextCard Visa at > <a href=" http://clickme.onelist.com/ad/NextcardCreative1CI ">Click Here</a> > > ------------------------------------------------------------------------

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

Just FYI, I've been messing with stack sizes a lot lately... :( I have a very simple task that increments 2 counters, compares both to a value, then writes a global flag if needed. This stack seems to require 19 bytes to run. However, dynamically measuring the stack size shows that only 13 bytes are being used. Task stack overflow seems to affect the variable directly after it in memory (see the MPP file). I have not been able to get useful information out of the stack pointer registers to this point. The MPP map file would seem to indicate that each function/subroutine call uses 8 bytes of stack without including local variables. I have not gotten confirmation of this from Netmedia, though. 8 bytes overhead seems like a lot for this processor. You can guestimate (fairly accurately) the stack size needed by determining the deepest call path in your program, i.e. which code path makes the most consecutive function/subroutine calls. For each function/subroutine called, add the call overhead plus the size of the local variables used. Functions also require stack for returning their values. The MPP file may show other temporary variables also being used for certain function/subroutines. Then throw in a fudge factor for the system calls your lowest function/subroutine makes. Then (probably) add another fudge factor. I know it's a lot of work, but if you only have 400 bytes RAM you may need it... :( I have seen several stack overflow failure modes in my project, not all of which were readily apparent: Box completely stops operating; box does a quick reset you might notice somehow; box will not power up at all; box seems to run one subroutine over and over; box will not completely initialize but otherwise seems fine; box returns incorrect data over the RS-232 link, but otherwise seems fine. The symptom will also likely change as the code changes. It makes life interesting! :) Good luck! Steve Stover -----Original Message----- From: Paul J. Csonka [mailto:] Sent: Sunday, February 13, 2000 11:07 PM To: Subject: [BasicX] Further stack question From: "Paul J. Csonka" <> Good evening, I am pleased to successfully multitask within a few minutes of trying, this system is very straightforward and simple! However, I lack understanding of the following: When declaring stacks, the total cannot exceed 400bytes due to RAM limitations. True so far? When attempting more, I get an error message, so this is true as far as I can tell. From the manual: "A simple task with no local variables, simple equations and comparisons, and no subprogram calls, could get away with a stack as small as 32 bytes. Other complex tasks might need more than 1000 bytes of stack space." So how can I assign a task 1000 bytes when the max available is 400bytes--Or is this saying I can't have a stack that large, and is worded unclearly? Thank you for your time and assistance. Have a pleasant evening, Paul

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

It may be a coincidense but I also dynamically measured the stack size to 13 bytes. It seems there is an untouched byte there. I ended up measuring the stack size starting from the end instead giving me a much more reasonable result (51 bytes). Hakan Bastedt ----- Original Message ----- From: Steve Stover To: Sent: Monday, February 14, 2000 16:07 Subject: RE: [BasicX] Further stack question From: "Steve Stover" <> Just FYI, I've been messing with stack sizes a lot lately... :( I have a very simple task that increments 2 counters, compares both to a value, then writes a global flag if needed. This stack seems to require 19 bytes to run. However, dynamically measuring the stack size shows that only 13 bytes are being used. Task stack overflow seems to affect the variable directly after it in memory (see the MPP file). I have not been able to get useful information out of the stack pointer registers to this point. The MPP map file would seem to indicate that each function/subroutine call uses 8 bytes of stack without including local variables. I have not gotten confirmation of this from Netmedia, though. 8 bytes overhead seems like a lot for this processor. You can guestimate (fairly accurately) the stack size needed by determining the deepest call path in your program, i.e. which code path makes the most consecutive function/subroutine calls. For each function/subroutine called, add the call overhead plus the size of the local variables used. Functions also require stack for returning their values. The MPP file may show other temporary variables also being used for certain function/subroutines. Then throw in a fudge factor for the system calls your lowest function/subroutine makes. Then (probably) add another fudge factor. I know it's a lot of work, but if you only have 400 bytes RAM you may need it... :( I have seen several stack overflow failure modes in my project, not all of which were readily apparent: Box completely stops operating; box does a quick reset you might notice somehow; box will not power up at all; box seems to run one subroutine over and over; box will not completely initialize but otherwise seems fine; box returns incorrect data over the RS-232 link, but otherwise seems fine. The symptom will also likely change as the code changes. It makes life interesting! :) Good luck! Steve Stover -----Original Message----- From: Paul J. Csonka [mailto:] Sent: Sunday, February 13, 2000 11:07 PM To: Subject: [BasicX] Further stack question From: "Paul J. Csonka" <> Good evening, I am pleased to successfully multitask within a few minutes of trying, this system is very straightforward and simple! However, I lack understanding of the following: When declaring stacks, the total cannot exceed 400bytes due to RAM limitations. True so far? When attempting more, I get an error message, so this is true as far as I can tell. From the manual: "A simple task with no local variables, simple equations and comparisons, and no subprogram calls, could get away with a stack as small as 32 bytes. Other complex tasks might need more than 1000 bytes of stack space." So how can I assign a task 1000 bytes when the max available is 400bytes--Or is this saying I can't have a stack that large, and is worded unclearly? Thank you for your time and assistance. Have a pleasant evening, Paul ------------------------------------------------------------------------------ Please click above to support our sponsor ------------------------------------------------------------------------------ [Non-text portions of this message have been removed]

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