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

Hi, I wrote a small program that has one task. I Preinitialize that task's stack to a known value (dec 177) that did not appear in that stack output previously. When that task completes, I output the task stack's contents. I notice that bytes 13-15 and from 36 on appear to be unused, but experimentation has shown me that 43 bytes of stack is the least I can get by with. The obvious question is why do I need bytes 36+, but I would also like to know what is going on with 13-15, is it wasted ram? Also, I notice that as I increase the stack size up to available memory, the program may or may not work. I am using 3 files, one for the main program section, one for the task and the third is SerialPort.bas from Peter Anderson's web site. Does the order I list these files in the project>files window matter? I have tried a few different orderings and have not noticed any program operation difference. If it matters, what order should they be in? I will email the program files upon request. Thanks, Kurt Stevens >>>>>>>>>>>>> program output <<<<<<<<<<<<<<<<< *** Opening file: C:\Program Files\BasicX Environment\tst\test.bxb *** Downloading File Locked, Status: 0C *** Finished Downloading Program start... Starting tasks... Task 1 started. Output from task1 1 Output from task1 2 Output from task1 3 Output from task1 4 Output from task1 5 Output from task1 6 Output from task1 7 Output from task1 8 Output from task1 9 Output from task1 10 Output from task1 11 Output from task1 12 Output from task1 13 Output from task1 14 Output from task1 15 byte 1 255 byte 2 0 byte 3 0 byte 4 0 byte 5 0 byte 6 176 byte 7 1 byte 8 194 byte 9 1 byte 10 62 byte 11 3 byte 12 0 byte 13 177 byte 14 177 byte 15 177 byte 16 18 byte 17 0 byte 18 79 byte 19 117 byte 20 116 byte 21 112 byte 22 117 byte 23 116 byte 24 32 byte 25 102 byte 26 114 byte 27 111 byte 28 109 byte 29 32 byte 30 116 byte 31 97 byte 32 115 byte 33 107 byte 34 49 byte 35 32 byte 36 177 byte 37 177 byte 38 177 byte 39 177 byte 40 177 byte 41 177 byte 42 177 byte 43 177 Done. Program halted.

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

Hi Kurt ... I got exactly the same results that you did ... surprise, surprise! Made as many experimental changes as I could think of ... float Sleep to integer Sleep, Do While to Do Until, etc. ... all without learning a thing. My only thought is that a task can NOT be allowed to "run off the end", but I can't find any reference to a "kill task" command in the documentation. It looks like some help from NetMedia is needed! Chris? Jack? Frank? BTW, Frank Manning has fixed some bugs in SerialPort.bas. The new version is available at http://www.onelist.com/files/basicx/BX01/ If you find the answer off list, please let me know. Good luck, - Nick - "Stevens, Kurt" wrote: > > Hi, > I wrote a small program that has one task. I Preinitialize that > task's stack to a known value (dec 177) that did not appear in that stack > output previously. When that task completes, I output the task stack's > contents. I notice that bytes 13-15 and from 36 on appear to be unused, but > experimentation has shown me that 43 bytes of stack is the least I can get > by with. The obvious question is why do I need bytes 36+, but I would also > like to know what is going on with 13-15, is it wasted ram? Also, I notice > that as I increase the stack size up to available memory, the program may or > may not work. > > I am using 3 files, one for the main program section, one for the > task and the third is SerialPort.bas from Peter Anderson's web site. Does > the order I list these files in the project>files window matter? I have > tried a few different orderings and have not noticed any program operation > difference. If it matters, what order should they be in? > > I will email the program files upon request. > > Thanks, > > Kurt Stevens > > >>>>>>>>>>>>> program output <<<<<<<<<<<<<<<<< > *** Opening file: C:\Program Files\BasicX Environment\tst\test.bxb > > *** Downloading File > Locked, Status: 0C > *** Finished Downloading > Program start... > Starting tasks... > Task 1 started. > Output from task1 1 > Output from task1 2 > Output from task1 3 > Output from task1 4 > Output from task1 5 > Output from task1 6 > Output from task1 7 > Output from task1 8 > Output from task1 9 > Output from task1 10 > Output from task1 11 > Output from task1 12 > Output from task1 13 > Output from task1 14 > Output from task1 15 > byte 1 255 > byte 2 0 > byte 3 0 > byte 4 0 > byte 5 0 > byte 6 176 > byte 7 1 > byte 8 194 > byte 9 1 > byte 10 62 > byte 11 3 > byte 12 0 > byte 13 177 > byte 14 177 > byte 15 177 > byte 16 18 > byte 17 0 > byte 18 79 > byte 19 117 > byte 20 116 > byte 21 112 > byte 22 117 > byte 23 116 > byte 24 32 > byte 25 102 > byte 26 114 > byte 27 111 > byte 28 109 > byte 29 32 > byte 30 116 > byte 31 97 > byte 32 115 > byte 33 107 > byte 34 49 > byte 35 32 > byte 36 177 > byte 37 177 > byte 38 177 > byte 39 177 > byte 40 177 > byte 41 177 > byte 42 177 > byte 43 177 > Done. > Program halted.

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

Kurt ... further playing with multitasking using your programs yields yet more problems with stack size! Increasing stack size above 45 bytes also causes the program to crash. Further, stack size may be reduced to 17 bytes if a second task is added and the total of the two stacks is between 43 and 45 bytes! The second task is not called so it doesn't do anything except take up space. Yet another further: If another global variable is declared, then the magic 43 to 45 number changes! It appears that there is a bug in the BasicX operating system's allocation of variable space! Let's hope that the guys at NetMedia can deal with this soon. I'm almost afraid to start looking at multitasking on the BX-24. - Nick -

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

Kurt ... I moved over to the BX-24 to do more testing of multitasking and stack size using NetMedia's Buttons.bas as a starting point. Here's what I found: (1) I needed to halt the tasks to be able to dump the stacks. (2) bytes 13, 14, & 15 are always unused in all the routines I tried. (3) There was NO problem with decreasing stack size to the exact size needed. (4) Was able to increase stack size up to the point that there was not enough room for variables before it failed. In a couple of days I'll try your program on the BX-24 and then go back onto the BX-01. - Nick - "Stevens, Kurt" wrote: > > Hi, > I wrote a small program that has one task. I Preinitialize that > task's stack to a known value (dec 177) that did not appear in that stack > output previously. When that task completes, I output the task stack's > contents. I notice that bytes 13-15 and from 36 on appear to be unused, but > experimentation has shown me that 43 bytes of stack is the least I can get > by with. The obvious question is why do I need bytes 36+, but I would also > like to know what is going on with 13-15, is it wasted ram? Also, I notice > that as I increase the stack size up to available memory, the program may or > may not work. > > I am using 3 files, one for the main program section, one for the > task and the third is SerialPort.bas from Peter Anderson's web site. Does > the order I list these files in the project>files window matter? I have > tried a few different orderings and have not noticed any program operation > difference. If it matters, what order should they be in? > > I will email the program files upon request. > > Thanks, > > Kurt Stevens > > >>>>>>>>>>>>> program output <<<<<<<<<<<<<<<<< > *** Opening file: C:\Program Files\BasicX Environment\tst\test.bxb > > *** Downloading File > Locked, Status: 0C > *** Finished Downloading > Program start... > Starting tasks... > Task 1 started. > Output from task1 1 > Output from task1 2 > Output from task1 3 > Output from task1 4 > Output from task1 5 > Output from task1 6 > Output from task1 7 > Output from task1 8 > Output from task1 9 > Output from task1 10 > Output from task1 11 > Output from task1 12 > Output from task1 13 > Output from task1 14 > Output from task1 15 > byte 1 255 > byte 2 0 > byte 3 0 > byte 4 0 > byte 5 0 > byte 6 176 > byte 7 1 > byte 8 194 > byte 9 1 > byte 10 62 > byte 11 3 > byte 12 0 > byte 13 177 > byte 14 177 > byte 15 177 > byte 16 18 > byte 17 0 > byte 18 79 > byte 19 117 > byte 20 116 > byte 21 112 > byte 22 117 > byte 23 116 > byte 24 32 > byte 25 102 > byte 26 114 > byte 27 111 > byte 28 109 > byte 29 32 > byte 30 116 > byte 31 97 > byte 32 115 > byte 33 107 > byte 34 49 > byte 35 32 > byte 36 177 > byte 37 177 > byte 38 177 > byte 39 177 > byte 40 177 > byte 41 177 > byte 42 177 > byte 43 177 > Done. > Program halted.

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

Thank you for replying, but I am not satisfied with this Jack. What you say about bytes 13-15 makes sense, and sounds reasonable. I am glad that you will look into reclaiming this for tasks. What I am concerned about are the results of my particular program and the almost total unpredictability. I can't see any unpredictable decisions that my task can make and I can't get near to using a stack size reasonable to what my task uses. Please look at my program, try it out and see what results you get and what you think. I believe there is something further that is wrong with either my code or NetMedia's system for the BX01. I emailed my code to your support address and I will send it to you, if you like. Thanks, Kurt Stevens > ---------- > From: Jack Schoof[SMTP:] > Sent: Saturday, December 04, 1999 10:39 AM > To: > Subject: Re: [BasicX] BX01 Stack > > From: "Jack Schoof" <> > > We have done extensive testing of multitasking and have had no problems. > I > have successfully run test programs with 100+ tasks on a BX1 with RAM > without any problems. > > Bytes 13, 14 & 15 are used for the return address when the routine is > called > as a subroutine. When it is a task, they are not used. Since we do not > know ahead of time whether you will call the routine or calltask the > routine, we allocate the space anyway. We will look into reducing this > ram > usage if possible. > > There should be no problem using a stack of the exact size. Just keep in > mind that different code paths will cause different stack usage. If your > program takes a code path once for an error condition or a rare event, > this > could blow your stack. These are the kind of bugs that kill space > missions > and other critical systems since all code paths are not checked out. We > recommend at least a 10% margin for the stack. > > Also dont forget that the main program has its own stack which is from the > end of global variables upward. If it runs out of stack space, then the > whole world will crash. > > If a task runs off the end and hits the end sub, then it will be removed > from the list of tasks and you can reclaim and reuse the stack memory, or > start another task using that stack memory. > > Jack > > -----Original Message----- > From: Nick Taylor <> > To: <> > Date: Friday, December 03, 1999 3:51 AM > Subject: Re: [BasicX] BX01 Stack > >From: Nick Taylor <> > > > >Kurt ... I moved over to the BX-24 to do more testing of multitasking > >and stack size using NetMedia's Buttons.bas as a starting point. > >Here's what I found: > > > >(1) I needed to halt the tasks to be able to dump the stacks. > >(2) bytes 13, 14, & 15 are always unused in all the routines I tried. > >(3) There was NO problem with decreasing stack size to the exact > > size needed. > >(4) Was able to increase stack size up to the point that there was > > not enough room for variables before it failed. > > > >In a couple of days I'll try your program on the BX-24 and then go > >back onto the BX-01. > > > > - Nick - > > > > > >"Stevens, Kurt" wrote: > >> > >> Hi, > >> I wrote a small program that has one task. I Preinitialize that > >> task's stack to a known value (dec 177) that did not appear in that > stack > >> output previously. When that task completes, I output the task stack's > >> contents. I notice that bytes 13-15 and from 36 on appear to be unused, > but > >> experimentation has shown me that 43 bytes of stack is the least I can > get > >> by with. The obvious question is why do I need bytes 36+, but I would > also > >> like to know what is going on with 13-15, is it wasted ram? Also, I > notice > >> that as I increase the stack size up to available memory, the program > may > or > >> may not work. > >> > >> I am using 3 files, one for the main program section, one for > the > >> task and the third is SerialPort.bas from Peter Anderson's web site. > Does > >> the order I list these files in the project>files window matter? I have > >> tried a few different orderings and have not noticed any program > operation > >> difference. If it matters, what order should they be in? > >> > >> I will email the program files upon request. > >> > >> Thanks, > >> > >> Kurt Stevens > >> > >> >>>>>>>>>>>>> program output <<<<<<<<<<<<<<<<< > >> *** Opening file: C:\Program Files\BasicX Environment\tst\test.bxb > >> > >> *** Downloading File > >> Locked, Status: 0C > >> *** Finished Downloading > >> Program start... > >> Starting tasks... > >> Task 1 started. > >> Output from task1 1 > >> Output from task1 2 > >> Output from task1 3 > >> Output from task1 4 > >> Output from task1 5 > >> Output from task1 6 > >> Output from task1 7 > >> Output from task1 8 > >> Output from task1 9 > >> Output from task1 10 > >> Output from task1 11 > >> Output from task1 12 > >> Output from task1 13 > >> Output from task1 14 > >> Output from task1 15 > >> byte 1 255 > >> byte 2 0 > >> byte 3 0 > >> byte 4 0 > >> byte 5 0 > >> byte 6 176 > >> byte 7 1 > >> byte 8 194 > >> byte 9 1 > >> byte 10 62 > >> byte 11 3 > >> byte 12 0 > >> byte 13 177 > >> byte 14 177 > >> byte 15 177 > >> byte 16 18 > >> byte 17 0 > >> byte 18 79 > >> byte 19 117 > >> byte 20 116 > >> byte 21 112 > >> byte 22 117 > >> byte 23 116 > >> byte 24 32 > >> byte 25 102 > >> byte 26 114 > >> byte 27 111 > >> byte 28 109 > >> byte 29 32 > >> byte 30 116 > >> byte 31 97 > >> byte 32 115 > >> byte 33 107 > >> byte 34 49 > >> byte 35 32 > >> byte 36 177 > >> byte 37 177 > >> byte 38 177 > >> byte 39 177 > >> byte 40 177 > >> byte 41 177 > >> byte 42 177 > >> byte 43 177 > >> Done. > >> Program halted. > >> > > > > > >

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

> From: "Stevens, Kurt" <> > > Thank you for replying, but I am not satisfied with this Jack. What > you say about bytes 13-15 makes sense, and sounds reasonable. I am > glad that you will look into reclaiming this for tasks. What I am > concerned about are the results of my particular program and the > almost total unpredictability. I can't see any unpredictable > decisions that my task can make and I can't get near to using a > stack size reasonable to what my task uses. Please look at my > program, try it out and see what results you get and what you think. > I believe there is something further that is wrong with either my > code or NetMedia's system for the BX01. I emailed my code to your > support address and I will send it to you, if you like. > > [...] I took a look at the program, and I think I see the problem. In task OutputTask1 a variable-length string is declared: Dim mesg as string A variable-length string always uses a constant 66 bytes of storage, which consists of a 2 byte string descriptor plus 64 bytes for characters. But the stack for this task is 43 bytes, so the stack gets blown right away as soon as the task starts. I'm surprised the program runs at all. The reason a blown stack was not apparent in the stack dump was that only 18 characters of the string are actually used, which get assigned in this statement: mesg = "Output from task1 " But the remaining 46 bytes are never initialized, so they stay at their pre-initialized value of 177. As you can see, it's dicey to rely solely on numeric values in a task stack as a means of judging how much of the stack is actually used. It's interesting that if you look at the stack dump you can see the contents of the string. Byte 16 is the string length (18), byte 17 is the string type, and bytes 18 to 35 contain the string itself: byte 16 18 = string length byte 17 0 = string type (variable length) byte 18 79 = "O" byte 19 117 = "u" byte 20 116 = "t" byte 21 112 = "p" byte 22 117 = "u" byte 23 116 = "t" byte 24 32 = <blank> [...] byte 32 115 = "s" byte 33 107 = "k" byte 34 49 = "1" byte 35 32 = <blank> I did try minimizing the string lengths to String*1. Even then, the stack needs to be at least 85 bytes long. Probably SerialPort module is using up most of the stack -- not surprising, since formatted numeric I/O tends to be expensive in any langage. -- Frank Manning -- NetMedia, Inc.

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

Thanks for looking at this, Frank. To paraphrase: You're telling me that a task can only allocate variable space from it's assigned stack? I guess I assumed that the stack space is for the task's context switch only, when calling functions. This would be an important learning for me. So what task1 is using for calling the serial functions is the unused string space, and this would explain why increasing or decreasing the stack space would cause failures. I was moving the context switch part of the stack around in a window of unused memory, and it would fail when I overlapped a changing byte. This might be good information for the instruction manual. The light dawns! Thanks, Frank. You have restored my confidence and increased my gratitude! Kurt Stevens > ---------- > From: Frank Manning[SMTP:] > Sent: Friday, December 03, 1999 4:13 PM > To: > Subject: [BasicX] RE: BX01 Stack > > From: "Frank Manning" <> > > > From: "Stevens, Kurt" <> > > > > Thank you for replying, but I am not satisfied with this Jack. What > > you say about bytes 13-15 makes sense, and sounds reasonable. I am > > glad that you will look into reclaiming this for tasks. What I am > > concerned about are the results of my particular program and the > > almost total unpredictability. I can't see any unpredictable > > decisions that my task can make and I can't get near to using a > > stack size reasonable to what my task uses. Please look at my > > program, try it out and see what results you get and what you think. > > I believe there is something further that is wrong with either my > > code or NetMedia's system for the BX01. I emailed my code to your > > support address and I will send it to you, if you like. > > > > [...] > > > > I took a look at the program, and I think I see the problem. In task > OutputTask1 a variable-length string is declared: > > Dim mesg as string > > A variable-length string always uses a constant 66 bytes of storage, which > consists of a 2 byte string descriptor plus 64 bytes for characters. > > But the stack for this task is 43 bytes, so the stack gets blown right > away > as soon as the task starts. I'm surprised the program runs at all. > > The reason a blown stack was not apparent in the stack dump was that only > 18 > characters of the string are actually used, which get assigned in this > statement: > > mesg = "Output from task1 " > > But the remaining 46 bytes are never initialized, so they stay at their > pre-initialized value of 177. As you can see, it's dicey to rely solely on > numeric values in a task stack as a means of judging how much of the stack > is actually used. > > It's interesting that if you look at the stack dump you can see the > contents > of the string. Byte 16 is the string length (18), byte 17 is the string > type, and bytes 18 to 35 contain the string itself: > > byte 16 18 = string length > byte 17 0 = string type (variable length) > byte 18 79 = "O" > byte 19 117 = "u" > byte 20 116 = "t" > byte 21 112 = "p" > byte 22 117 = "u" > byte 23 116 = "t" > byte 24 32 = <blank> > [...] > byte 32 115 = "s" > byte 33 107 = "k" > byte 34 49 = "1" > byte 35 32 = <blank> > > I did try minimizing the string lengths to String*1. Even then, the stack > needs to be at least 85 bytes long. Probably SerialPort module is using up > most of the stack -- not surprising, since formatted numeric I/O tends to > be > expensive in any langage. > > -- Frank Manning > -- NetMedia, Inc. > >

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

Kurt: In most languages, such as C and others the stack is used for passing variables to routines and housekeeping by the operating system and other items. Usually you dont think about the stack because you only have one stream and it doesnt get in the way. What makes the BasicX unique is that you can assign multiple stacks to multiple running pieces of the code. Each one is like a little mini basicx processor. Sorry for the confusion. I hope that it is clearer than mud now. I wish we had more memory in the Atmel 8515 or 8535 devices, because in the BX1 with 64K to play with you can do some really cool stuff with 20 or 30 tasks! If you use global memory, then the stack is not consumed with local variables. Of course it is harder to structure your code with globals, but you can get many tasks to run using the same code space too. What I mean is that you can call multiple instances of the same subroutine. Example: Dim glob(1 to 3) as byte dim stack1(1 to 32) as byte dim stack2(1 to 32) as byte dim stack3(1 to 32) as byte dim i as byte sub main() i = 1 calltask "dowork",stack1 i = 2 calltask "dowork",stack2 i = 3 calltask dowork do loop 'just hang here then end sub sub dowork() dim myglob as byte myglob = i 'remember which one I am do glob(myglob) = glob(myglob) + 1 'just something to do loop end sub This is useful when you have common algorithms like a thermostat where you can handle 2 or 3 thermostats simultaneously! Jack -----Original Message----- From: Stevens, Kurt <> To: ' <> Date: Friday, December 03, 1999 3:02 PM Subject: RE: [BasicX] RE: BX01 Stack >From: "Stevens, Kurt" <> > >Thanks for looking at this, Frank. > >To paraphrase: You're telling me that a task can only allocate variable >space from it's assigned stack? I guess I assumed that the stack space is >for the task's context switch only, when calling functions. This would be an >important learning for me. So what task1 is using for calling the serial >functions is the unused string space, and this would explain why increasing >or decreasing the stack space would cause failures. I was moving the context >switch part of the stack around in a window of unused memory, and it would >fail when I overlapped a changing byte. This might be good information for >the instruction manual. > > The light dawns! > > Thanks, Frank. You have restored my confidence and increased my >gratitude! > > Kurt Stevens > >> ---------- >> From: Frank Manning[SMTP:] >> Sent: Friday, December 03, 1999 4:13 PM >> To: >> Subject: [BasicX] RE: BX01 Stack >> >> From: "Frank Manning" <> >> >> > From: "Stevens, Kurt" <> >> > >> > Thank you for replying, but I am not satisfied with this Jack. What >> > you say about bytes 13-15 makes sense, and sounds reasonable. I am >> > glad that you will look into reclaiming this for tasks. What I am >> > concerned about are the results of my particular program and the >> > almost total unpredictability. I can't see any unpredictable >> > decisions that my task can make and I can't get near to using a >> > stack size reasonable to what my task uses. Please look at my >> > program, try it out and see what results you get and what you think. >> > I believe there is something further that is wrong with either my >> > code or NetMedia's system for the BX01. I emailed my code to your >> > support address and I will send it to you, if you like. >> > >> > [...] >> > >> >> I took a look at the program, and I think I see the problem. In task >> OutputTask1 a variable-length string is declared: >> >> Dim mesg as string >> >> A variable-length string always uses a constant 66 bytes of storage, which >> consists of a 2 byte string descriptor plus 64 bytes for characters. >> >> But the stack for this task is 43 bytes, so the stack gets blown right >> away >> as soon as the task starts. I'm surprised the program runs at all. >> >> The reason a blown stack was not apparent in the stack dump was that only >> 18 >> characters of the string are actually used, which get assigned in this >> statement: >> >> mesg = "Output from task1 " >> >> But the remaining 46 bytes are never initialized, so they stay at their >> pre-initialized value of 177. As you can see, it's dicey to rely solely on >> numeric values in a task stack as a means of judging how much of the stack >> is actually used. >> >> It's interesting that if you look at the stack dump you can see the >> contents >> of the string. Byte 16 is the string length (18), byte 17 is the string >> type, and bytes 18 to 35 contain the string itself: >> >> byte 16 18 = string length >> byte 17 0 = string type (variable length) >> byte 18 79 = "O" >> byte 19 117 = "u" >> byte 20 116 = "t" >> byte 21 112 = "p" >> byte 22 117 = "u" >> byte 23 116 = "t" >> byte 24 32 = <blank> >> [...] >> byte 32 115 = "s" >> byte 33 107 = "k" >> byte 34 49 = "1" >> byte 35 32 = <blank> >> >> I did try minimizing the string lengths to String*1. Even then, the stack >> needs to be at least 85 bytes long. Probably SerialPort module is using up >> most of the stack -- not surprising, since formatted numeric I/O tends to >> be >> expensive in any langage. >> >> -- Frank Manning >> -- NetMedia, Inc. >> >>

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

Opps here is the code again: Dim glob(1 to 3) as byte dim stack1(1 to 32) as byte dim stack2(1 to 32) as byte dim stack3(1 to 32) as byte dim i as byte sub main() i = 1 calltask "dowork",stack1 i = 2 calltask "dowork",stack2 i = 3 calltask "dowork",stack3 'fixed from previous message do loop 'just hang here then end sub sub dowork() dim myglob as byte myglob = i 'remember which one I am do glob(myglob) = glob(myglob) + 1 'just something to do loop end sub

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

We have done extensive testing of multitasking and have had no problems. I have successfully run test programs with 100+ tasks on a BX1 with RAM without any problems. Bytes 13, 14 & 15 are used for the return address when the routine is called as a subroutine. When it is a task, they are not used. Since we do not know ahead of time whether you will call the routine or calltask the routine, we allocate the space anyway. We will look into reducing this ram usage if possible. There should be no problem using a stack of the exact size. Just keep in mind that different code paths will cause different stack usage. If your program takes a code path once for an error condition or a rare event, this could blow your stack. These are the kind of bugs that kill space missions and other critical systems since all code paths are not checked out. We recommend at least a 10% margin for the stack. Also dont forget that the main program has its own stack which is from the end of global variables upward. If it runs out of stack space, then the whole world will crash. If a task runs off the end and hits the end sub, then it will be removed from the list of tasks and you can reclaim and reuse the stack memory, or start another task using that stack memory. Jack -----Original Message----- From: Nick Taylor <> To: <> Date: Friday, December 03, 1999 3:51 AM Subject: Re: [BasicX] BX01 Stack >From: Nick Taylor <> > >Kurt ... I moved over to the BX-24 to do more testing of multitasking >and stack size using NetMedia's Buttons.bas as a starting point. >Here's what I found: > >(1) I needed to halt the tasks to be able to dump the stacks. >(2) bytes 13, 14, & 15 are always unused in all the routines I tried. >(3) There was NO problem with decreasing stack size to the exact > size needed. >(4) Was able to increase stack size up to the point that there was > not enough room for variables before it failed. > >In a couple of days I'll try your program on the BX-24 and then go >back onto the BX-01. > > - Nick - >"Stevens, Kurt" wrote: >> >> Hi, >> I wrote a small program that has one task. I Preinitialize that >> task's stack to a known value (dec 177) that did not appear in that stack >> output previously. When that task completes, I output the task stack's >> contents. I notice that bytes 13-15 and from 36 on appear to be unused, but >> experimentation has shown me that 43 bytes of stack is the least I can get >> by with. The obvious question is why do I need bytes 36+, but I would also >> like to know what is going on with 13-15, is it wasted ram? Also, I notice >> that as I increase the stack size up to available memory, the program may or >> may not work. >> >> I am using 3 files, one for the main program section, one for the >> task and the third is SerialPort.bas from Peter Anderson's web site. Does >> the order I list these files in the project>files window matter? I have >> tried a few different orderings and have not noticed any program operation >> difference. If it matters, what order should they be in? >> >> I will email the program files upon request. >> >> Thanks, >> >> Kurt Stevens >> >> >>>>>>>>>>>>> program output <<<<<<<<<<<<<<<<< >> *** Opening file: C:\Program Files\BasicX Environment\tst\test.bxb >> >> *** Downloading File >> Locked, Status: 0C >> *** Finished Downloading >> Program start... >> Starting tasks... >> Task 1 started. >> Output from task1 1 >> Output from task1 2 >> Output from task1 3 >> Output from task1 4 >> Output from task1 5 >> Output from task1 6 >> Output from task1 7 >> Output from task1 8 >> Output from task1 9 >> Output from task1 10 >> Output from task1 11 >> Output from task1 12 >> Output from task1 13 >> Output from task1 14 >> Output from task1 15 >> byte 1 255 >> byte 2 0 >> byte 3 0 >> byte 4 0 >> byte 5 0 >> byte 6 176 >> byte 7 1 >> byte 8 194 >> byte 9 1 >> byte 10 62 >> byte 11 3 >> byte 12 0 >> byte 13 177 >> byte 14 177 >> byte 15 177 >> byte 16 18 >> byte 17 0 >> byte 18 79 >> byte 19 117 >> byte 20 116 >> byte 21 112 >> byte 22 117 >> byte 23 116 >> byte 24 32 >> byte 25 102 >> byte 26 114 >> byte 27 111 >> byte 28 109 >> byte 29 32 >> byte 30 116 >> byte 31 97 >> byte 32 115 >> byte 33 107 >> byte 34 49 >> byte 35 32 >> byte 36 177 >> byte 37 177 >> byte 38 177 >> byte 39 177 >> byte 40 177 >> byte 41 177 >> byte 42 177 >> byte 43 177 >> Done. >> Program halted. >

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

Great response Frank! Now I feel stupid for not seeing this myself when I realized that it was a variable allocation problem. You and Chris and Jack are doing a tremendous job with your on-line support of the BasicX devices! An excellent product with excellent support can't fail to attract customers. - Nick - Frank Manning wrote: > > > From: "Stevens, Kurt" <> > > > > Thank you for replying, but I am not satisfied with this Jack. What > > you say about bytes 13-15 makes sense, and sounds reasonable. I am > > glad that you will look into reclaiming this for tasks. What I am > > concerned about are the results of my particular program and the > > almost total unpredictability. I can't see any unpredictable > > decisions that my task can make and I can't get near to using a > > stack size reasonable to what my task uses. Please look at my > > program, try it out and see what results you get and what you think. > > I believe there is something further that is wrong with either my > > code or NetMedia's system for the BX01. I emailed my code to your > > support address and I will send it to you, if you like. > > > > [...] > > > > I took a look at the program, and I think I see the problem. In task > OutputTask1 a variable-length string is declared: > > Dim mesg as string > > A variable-length string always uses a constant 66 bytes of storage, which > consists of a 2 byte string descriptor plus 64 bytes for characters. > > But the stack for this task is 43 bytes, so the stack gets blown right away > as soon as the task starts. I'm surprised the program runs at all. > > The reason a blown stack was not apparent in the stack dump was that only 18 > characters of the string are actually used, which get assigned in this > statement: > > mesg = "Output from task1 " > > But the remaining 46 bytes are never initialized, so they stay at their > pre-initialized value of 177. As you can see, it's dicey to rely solely on > numeric values in a task stack as a means of judging how much of the stack > is actually used. > > It's interesting that if you look at the stack dump you can see the contents > of the string. Byte 16 is the string length (18), byte 17 is the string > type, and bytes 18 to 35 contain the string itself: > > byte 16 18 = string length > byte 17 0 = string type (variable length) > byte 18 79 = "O" > byte 19 117 = "u" > byte 20 116 = "t" > byte 21 112 = "p" > byte 22 117 = "u" > byte 23 116 = "t" > byte 24 32 = <blank> > [...] > byte 32 115 = "s" > byte 33 107 = "k" > byte 34 49 = "1" > byte 35 32 = <blank> > > I did try minimizing the string lengths to String*1. Even then, the stack > needs to be at least 85 bytes long. Probably SerialPort module is using up > most of the stack -- not surprising, since formatted numeric I/O tends to be > expensive in any langage. > > -- Frank Manning > -- NetMedia, Inc.

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