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

Hello, I have come across a problem which has me banging my head against a wall. I have two simple port monitoring tasks that start running in the background when the user passes in a string to the BX24 through the COM port. My program parses the string for a command and then parses out any parameters that may have been passed along and then runs the command (in a big case statement). When eliminate and multitasking (by commenting out all of my multi- tasking code), this works beautifully. The command and the parameters get parsed fine. However, when I do multitask, everything freezes and I need to reset tbe BX24-- even though I never really started the tasks. I though I was getting stack overflow, so I increased the stack size (to waaaay above what my little tasks should require) to no avail. Somehow I think multitasking is causing problems in a way that I can't explain via stack overflow or variable conflict. Here are my tasks.... dim monitor_switch0Stack(1 to 32) as byte ' dim monitor_nosepokeStack(1 to 32) as byte ' memory for the nosepoke task Dim PressedSwitch0 As Byte Dim IsInNosepokeHole As Byte ... main routine with the serial command parser and the big case statement...... Case CMD_START_SWITCH0_MONITOR_TASK callTask "monitor_switch0Task", monitor_switch0Stack blinkOK Case CMD_START_NOSEPOKE_MONITOR_TASK callTask "monitor_nosepokeTask", monitor_nosepokeStack blinkOK ...blah blah sub monitor_nosepokeTask() do IsInNosepokeHole = GetPin(NosePokePin) call sleep(refreshPeriod) loop end sub '--------------------------------------------------------------------- sub monitor_switch0Task() do PressedSwitch0 = GetPin(MFBSwitchPin) call sleep(refreshPeriod) loop end sub Does anyone have any ideas? Any help would be greatly appreciated! Stephen

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

(1 to 32) 32 is the min stack size. try something much larger for a test (1 to 50) or (1 to 75) --- "cowenowner <>" <> wrote: > Hello, I have come across a problem which has me banging my head > against a wall. > > I have two simple port monitoring tasks that start running in the > background when the user passes in a string to the BX24 through the > COM port. My program parses the string for a command and then parses > out any parameters that may have been passed along and then runs the > command (in a big case statement). > > When eliminate and multitasking (by commenting out all of my multi- > tasking code), this works beautifully. The command and the parameters > get parsed fine. However, when I do multitask, everything freezes and > I need to reset tbe BX24-- even though I never really started the > tasks. I though I was getting stack overflow, so I increased the > stack size (to waaaay above what my little tasks should require) to > no avail. Somehow I think multitasking is causing problems in a way > that I can't explain via stack overflow or variable conflict. Here > are my tasks.... > > dim monitor_switch0Stack(1 to 32) as byte ' > dim monitor_nosepokeStack(1 to 32) as byte ' memory for the nosepoke > task > Dim PressedSwitch0 As Byte > > Dim IsInNosepokeHole As Byte > ... > main routine with the serial command parser and the big case > statement...... > Case CMD_START_SWITCH0_MONITOR_TASK > > callTask "monitor_switch0Task", monitor_switch0Stack > blinkOK > > Case CMD_START_NOSEPOKE_MONITOR_TASK > > callTask "monitor_nosepokeTask", monitor_nosepokeStack > blinkOK > > ...blah blah > > sub monitor_nosepokeTask() > do > IsInNosepokeHole = GetPin(NosePokePin) > call sleep(refreshPeriod) > loop > end sub > > '--------------------------------------------------------------------- > sub monitor_switch0Task() > do > PressedSwitch0 = GetPin(MFBSwitchPin) > call sleep(refreshPeriod) > loop > end sub > > Does anyone have any ideas? Any help would be greatly appreciated! > > Stephen > > > __________________________________________________

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

Thanks. I tried that and I still get the problem. Now here's the kicker... The problem persists if I remove the calltask functions. I interpret this as indicating that just declaring the array (and not multitasking) caused some sort of corruption. Then I found a post (# 8507) in which Frank Manning pointed out a compiler bug that causes system crashes when byte arrays are declared in the following address range (for the BX24): 241 to 255, 497 to 511. Indeed, that was where my task byte array was being assigned (determined by looking at the .mpp file). Things were looking up, but alas, when I shuffled variables around so that the array was not declared in this range, the program still crashed and the problem was only resolved when I got rid of the arrays. Has anyone had problems declaring large byte arrays? Is there a no-mans memory land that I am not aware of? Thanks again for your help. Stephen --- In , Tony Brenke <trbrenke@y...> wrote: > (1 to 32) > > 32 is the min stack size. > try something much larger > for a test > (1 to 50) or (1 to 75) > --- "cowenowner <cowenowner@y...>" <cowenowner@y...> wrote: > > Hello, I have come across a problem which has me banging my head > > against a wall. > > > > I have two simple port monitoring tasks that start running in the > > background when the user passes in a string to the BX24 through the > > COM port. My program parses the string for a command and then parses > > out any parameters that may have been passed along and then runs the > > command (in a big case statement). > > > > When eliminate and multitasking (by commenting out all of my multi- > > tasking code), this works beautifully. The command and the parameters > > get parsed fine. However, when I do multitask, everything freezes and > > I need to reset tbe BX24-- even though I never really started the > > tasks. I though I was getting stack overflow, so I increased the > > stack size (to waaaay above what my little tasks should require) to > > no avail. Somehow I think multitasking is causing problems in a way > > that I can't explain via stack overflow or variable conflict. Here > > are my tasks.... > > > > dim monitor_switch0Stack(1 to 32) as byte ' > > dim monitor_nosepokeStack(1 to 32) as byte ' memory for the nosepoke > > task > > Dim PressedSwitch0 As Byte > > > > Dim IsInNosepokeHole As Byte > > ... > > main routine with the serial command parser and the big case > > statement...... > > Case CMD_START_SWITCH0_MONITOR_TASK > > > > callTask "monitor_switch0Task", monitor_switch0Stack > > blinkOK > > > > Case CMD_START_NOSEPOKE_MONITOR_TASK > > > > callTask "monitor_nosepokeTask", monitor_nosepokeStack > > blinkOK > > > > ...blah blah > > > > sub monitor_nosepokeTask() > > do > > IsInNosepokeHole = GetPin(NosePokePin) > > call sleep(refreshPeriod) > > loop > > end sub > > > > '----------------------------------------------------------------- ---- > > sub monitor_switch0Task() > > do > > PressedSwitch0 = GetPin(MFBSwitchPin) > > call sleep(refreshPeriod) > > loop > > end sub > > > > Does anyone have any ideas? Any help would be greatly appreciated! > > > > Stephen > > > > > > > > > > > > > > > > > > > > __________________________________________________

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

From: <> > [...] pointed out a compiler bug that causes system > crashes when byte arrays are declared in the > following address range (for the BX24): 241 to 255, > 497 to 511. [...] This bug was fixed, beginning with the V2.0 compiler. If you don't have this version, you can download it from here: http://www.basicx.com/transfer/ -- Frank Manning -- NetMedia, Inc.

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

Turns out that I am using V2.0. Darn, that was such a great theory. I am still getting strange/erratic results when I declare the global byte arrays (without multi-tasking) and everything works fine when I don't declare the arrays. Any clues? Thanks again for the help. This group is a wonderful resource. Stephen --- In , "Frank Manning" <fmanning@n...> wrote: > From: <cowenowner@y...> > > > [...] pointed out a compiler bug that causes system > > crashes when byte arrays are declared in the > > following address range (for the BX24): 241 to 255, > > 497 to 511. [...] > > This bug was fixed, beginning with the V2.0 compiler. If you don't > have this version, you can download it from here: > > http://www.basicx.com/transfer/ > > -- Frank Manning > -- NetMedia, Inc.

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

Frank, I have a BX01 development kit purchased about two years ago. I started to get into it but got derailed on other things. Well now I have the time and have already started working with a BX24 kit purchased from Peter Anderson. Anyhow, I'd like to start playing with the BX01 kit but I'm not sure of updates, etc. Is the chip the same today as it was two-three years ago? Do I need anyhthing besides a compiler update? Thanks in advance for the help, Bill -----Original Message----- From: Frank Manning [mailto:] Sent: Wednesday, January 01, 2003 12:09 PM To: Subject: Re: [BasicX] Re: multitasking wierdness From: <> > [...] pointed out a compiler bug that causes system > crashes when byte arrays are declared in the > following address range (for the BX24): 241 to 255, > 497 to 511. [...] This bug was fixed, beginning with the V2.0 compiler. If you don't have this version, you can download it from here: http://www.basicx.com/transfer/ -- Frank Manning -- NetMedia, Inc.

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

From: "BillandLeslie" <> > [...] > Anyhow, I'd like to start playing with the BX01 kit > but I'm not sure of updates, etc. Is the chip the > same today as it was two-three years ago? Do I > need anyhthing besides a compiler update? [...] No, the current version (V2.0) supports that BX-01, as does the beta test version of the next compiler (V2.1). The BX-01 downloader won't run on WinXP, however, because of problems with the parallel port driver. We're currently updating the driver to be compatible with WinXP. There should be no problems with the BX-01 downloader on Win95/98/ME/NT/2000. -- Frank Manning -- NetMedia, Inc.

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

Perhaps this is the problem... I am using 316K of RAM. If At the top of the .mpp file, it states that the main stack size is 85 bytes.... RAM available: 401 bytes RAM allocated: 316 bytes Main stack size: 85 bytes Am I correct in assuming that this means that I only have 85 bytes available for my local variables in the Main sub? I have a lot of variables in my main sub. Would this be corrected if I changed my global RAM variables into Persistent variables? Could this be the source of the erratic behavior? Stephen --- In , "cowenowner <cowenowner@y...>" <cowenowner@y...> wrote: > Turns out that I am using V2.0. Darn, that was such a great theory. I > am still getting strange/erratic results when I declare the global > byte arrays (without multi-tasking) and everything works fine when I > don't declare the arrays. Any clues? Thanks again for the help. This > group is a wonderful resource. > > Stephen > --- In , "Frank Manning" <fmanning@n...> wrote: > > From: <cowenowner@y...> > > > > > [...] pointed out a compiler bug that causes system > > > crashes when byte arrays are declared in the > > > following address range (for the BX24): 241 to 255, > > > 497 to 511. [...] > > > > This bug was fixed, beginning with the V2.0 compiler. If you don't > > have this version, you can download it from here: > > > > http://www.basicx.com/transfer/ > > > > -- Frank Manning > > -- NetMedia, Inc.

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

From: <> > Perhaps this is the problem... I am using 316K of RAM. > If At the top of the .mpp file, it states that the > main stack size is 85 bytes.... > RAM available: 401 bytes > RAM allocated: 316 bytes > Main stack size: 85 bytes > > Am I correct in assuming that this means that I only > have 85 bytes available for my local variables in the > Main sub? Yes, in the sense that the local variables would be allocated out of that 85 bytes. But there are other things that will eat up that 85 bytes, such as the task frame (15 bytes) plus any RAM used by subprograms called by Main. > I have a lot of variables in my main sub. Would this be > corrected if I changed my global RAM variables into > Persistent variables? Possibly, but you have to be careful of write cycle limits, as well as the time required to write to EEPROM, which is several ms per write. > Could this be the source of the erratic behavior? Possibly. Difficult to say without seeing the code. -- Frank Manning -- NetMedia, Inc.

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