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 all, I am having trouble with a program and any help would be very welcome. My program jumps between subroutines that represent different options on a menu. Each subroutine puts a string on the LCD using com3. The problem I get is that after an exact number of LCD updates the program either just hangs or resets itself. The number of updates varies from about 8 to 21 and seems to be affected by the size of queue defined for com3out. If you take a different path through my menu the problem still occurs after the same number of updates. I am writing to the LCD using putqueuestr(com3out, ...). I have tried the following - with no effects whatsoever on the problem; 1. Flushing and priming com3 before writing to it (using some code I found in the files section on this site) 2. Sticking in delays and sleeps before/after com3 commands Am I overloading a buffer ? Thanks for any help you can give me, CharlieM

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

You might want to look at another part of your program. If you are using a lot of subroutines and they call each other then you may be running out of stack space and that would cause the program to hang. Just a thought. Harry -----Original Message----- From: charliem101101 [mailto:] Sent: Wednesday, October 08, 2003 6:38 AM To: Subject: [BasicX] Program hanging/resetting after a number of LCD com3 string outputs Hi all, I am having trouble with a program and any help would be very welcome. My program jumps between subroutines that represent different options on a menu. Each subroutine puts a string on the LCD using com3. The problem I get is that after an exact number of LCD updates the program either just hangs or resets itself. The number of updates varies from about 8 to 21 and seems to be affected by the size of queue defined for com3out. If you take a different path through my menu the problem still occurs after the same number of updates. I am writing to the LCD using putqueuestr(com3out, ...). I have tried the following - with no effects whatsoever on the problem; 1. Flushing and priming com3 before writing to it (using some code I found in the files section on this site) 2. Sticking in delays and sleeps before/after com3 commands Am I overloading a buffer ? Thanks for any help you can give me, CharlieM [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 )

Hi Guys I am experiencing exactly the same problem. I have a device with two seriial LCDs and a RS485 link, so I am using three different com3 ports. Likewise I've tried numerous fixes but still get a rest about 2-3 times a day. I don't have any tasking or interrupts, and nowhere do I call a subroutine from within another subroutine. My prgram consists of a main loop, which calls a number of subroutines. the problem is definetly in the swapping between conm3 ports and writing to com3, but at this atge I'm not sure where. In order to wiat until a queue was empty I used : dowhile statusqueue (outwardbuffer) loop but this made things worse, which puzzled me. i now have a short delay after each coms routine, but that's clumsy. Shall we swap code Charlie and compare? neil Harry J. White wrote: > You might want to look at another part of your program. If you are > using a > lot of subroutines and they call each other then you may be running out of > stack space and that would cause the program to hang. Just a thought. > Harry > > -----Original Message----- > From: charliem101101 [mailto:] > Sent: Wednesday, October 08, 2003 6:38 AM > To: > Subject: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > Hi all, > > I am having trouble with a program and any help would be very > welcome. My program jumps between subroutines that represent > different options on a menu. Each subroutine puts a string on the LCD > using com3. > > The problem I get is that after an exact number of LCD updates the > program either just hangs or resets itself. The number of updates > varies from about 8 to 21 and seems to be affected by the size of > queue defined for com3out. If you take a different path through my > menu the problem still occurs after the same number of updates. > > I am writing to the LCD using putqueuestr(com3out, ...). > > I have tried the following - with no effects whatsoever on the > problem; > > 1. Flushing and priming com3 before writing to it (using some code I > found in the files section on this site) > > 2. Sticking in delays and sleeps before/after com3 commands > > Am I overloading a buffer ? > > Thanks for any help you can give me, > > CharlieM > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > ADVERTISEMENT > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=1706554205:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogyo?YH=3707890&yhad=1595053 > > >. [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 )

Neil, In addition to just waiting for the queues to empty, you also have to wait for the UART to finish pushing the byte out and down the wire before you float that com port away to another pin. I'll bet your reset is due to that. You move that com3 three away before transmission is completed fully. I have some code I will post. See if it fits your needs. It works for any pin, any queue. Give me a bit to pull from CD and strip out unrelated code. .db. -----Original Message----- From: Neil Jepsen [mailto:] Sent: Wednesday, October 08, 2003 12:43 PM To: Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 string outputs Hi Guys I am experiencing exactly the same problem. I have a device with two seriial LCDs and a RS485 link, so I am using three different com3 ports. Likewise I've tried numerous fixes but still get a rest about 2-3 times a day. I don't have any tasking or interrupts, and nowhere do I call a subroutine from within another subroutine. My prgram consists of a main loop, which calls a number of subroutines. the problem is definetly in the swapping between conm3 ports and writing to com3, but at this atge I'm not sure where. In order to wiat until a queue was empty I used : dowhile statusqueue (outwardbuffer) loop but this made things worse, which puzzled me. i now have a short delay after each coms routine, but that's clumsy. Shall we swap code Charlie and compare? neil Harry J. White wrote: > You might want to look at another part of your program. If you are > using a > lot of subroutines and they call each other then you may be running out of > stack space and that would cause the program to hang. Just a thought. > Harry > > -----Original Message----- > From: charliem101101 [mailto:] > Sent: Wednesday, October 08, 2003 6:38 AM > To: > Subject: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > Hi all, > > I am having trouble with a program and any help would be very > welcome. My program jumps between subroutines that represent > different options on a menu. Each subroutine puts a string on the LCD > using com3. > > The problem I get is that after an exact number of LCD updates the > program either just hangs or resets itself. The number of updates > varies from about 8 to 21 and seems to be affected by the size of > queue defined for com3out. If you take a different path through my > menu the problem still occurs after the same number of updates. > > I am writing to the LCD using putqueuestr(com3out, ...). > > I have tried the following - with no effects whatsoever on the > problem; > > 1. Flushing and priming com3 before writing to it (using some code I > found in the files section on this site) > > 2. Sticking in delays and sleeps before/after com3 commands > > Am I overloading a buffer ? > > Thanks for any help you can give me, > > CharlieM > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > ADVERTISEMENT > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy o?YH=3707890 <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy o?YH=3707890&yhad=1595053> &yhad=1595053 > > >. [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy o?YH=3707890&yhad=1595053> Click Here! <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai l/S=:HM/A=1595053/rand=135759174> > . [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 )

Yeah I'm aware of that Dan but I'm only sending a few bytes, and I have tried a delay after the dowhile loop to empty the uart which seemed not to help too much. If I jerk the com3 away too quickly, then characters appear on the wrong LCD but it doesn't cause a crash. However I hope you are right . I presume the bit of code you refer to is do while ( rampeek(cuInt(Com3Status))and bx0100_0000)=bx0100_0000) loop I'll try it. neil Dan Bielecki wrote: > Neil, > > In addition to just waiting for the queues to empty, you also have to wait > for the UART to finish pushing the byte out and down the wire before you > float that com port away to another pin. I'll bet your reset is due to > that. You move that com3 three away before transmission is completed > fully. > > I have some code I will post. See if it fits your needs. > It works for any pin, any queue. > Give me a bit to pull from CD and strip out unrelated code. > > .db. > -----Original Message----- > From: Neil Jepsen [mailto:] > Sent: Wednesday, October 08, 2003 12:43 PM > To: > Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > Hi Guys > I am experiencing exactly the same problem. I have a > device with two seriial LCDs and a RS485 link, so I am using three > different com3 ports. Likewise I've tried numerous fixes but still get > a rest about 2-3 times a day. I don't have any tasking or interrupts, > and nowhere do I call a subroutine from within another subroutine. My > prgram consists of a main loop, which calls a number of subroutines. > the problem is definetly in the swapping between conm3 ports and writing > to com3, but at this atge I'm not sure where. In order to wiat until a > queue was empty I used : > dowhile statusqueue (outwardbuffer) > loop > but this made things worse, which puzzled me. i now have a short delay > after each coms routine, but that's clumsy. Shall we swap code Charlie > and compare? > neil > > Harry J. White wrote: > > > You might want to look at another part of your program. If you are > > using a > > lot of subroutines and they call each other then you may be running > out of > > stack space and that would cause the program to hang. Just a thought. > > Harry > > > > -----Original Message----- > > From: charliem101101 [mailto:] > > Sent: Wednesday, October 08, 2003 6:38 AM > > To: > > Subject: [BasicX] Program hanging/resetting after a number of LCD com3 > > string outputs > > > > > > Hi all, > > > > I am having trouble with a program and any help would be very > > welcome. My program jumps between subroutines that represent > > different options on a menu. Each subroutine puts a string on the LCD > > using com3. > > > > The problem I get is that after an exact number of LCD updates the > > program either just hangs or resets itself. The number of updates > > varies from about 8 to 21 and seems to be affected by the size of > > queue defined for com3out. If you take a different path through my > > menu the problem still occurs after the same number of updates. > > > > I am writing to the LCD using putqueuestr(com3out, ...). > > > > I have tried the following - with no effects whatsoever on the > > problem; > > > > 1. Flushing and priming com3 before writing to it (using some code I > > found in the files section on this site) > > > > 2. Sticking in delays and sleeps before/after com3 commands > > > > Am I overloading a buffer ? > > > > Thanks for any help you can give me, > > > > CharlieM > > > > > > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890 > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> &yhad=1595053> > > > > > > > > >. > > [Non-text portions of this message have been removed] > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> Click Here! > > <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai > l/S=:HM/A=1595053/rand=135759174> > > > . > > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=1706554205:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3614674&prop=egroupweb&pos=HM > > >. [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 )

Very similar. But I have a call to DELAY in there so that the BX task-swaps and the bxOS has a chance to do its thing during that time. I will post it tonight. .db. -----Original Message----- From: Neil Jepsen [mailto:] Sent: Wednesday, October 08, 2003 6:53 PM To: Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 string outputs Yeah I'm aware of that Dan but I'm only sending a few bytes, and I have tried a delay after the dowhile loop to empty the uart which seemed not to help too much. If I jerk the com3 away too quickly, then characters appear on the wrong LCD but it doesn't cause a crash. However I hope you are right . I presume the bit of code you refer to is do while ( rampeek(cuInt(Com3Status))and bx0100_0000)=bx0100_0000) loop I'll try it. neil Dan Bielecki wrote: > Neil, > > In addition to just waiting for the queues to empty, you also have to wait > for the UART to finish pushing the byte out and down the wire before you > float that com port away to another pin. I'll bet your reset is due to > that. You move that com3 three away before transmission is completed > fully. > > I have some code I will post. See if it fits your needs. > It works for any pin, any queue. > Give me a bit to pull from CD and strip out unrelated code. > > .db. > -----Original Message----- > From: Neil Jepsen [mailto:] > Sent: Wednesday, October 08, 2003 12:43 PM > To: > Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > Hi Guys > I am experiencing exactly the same problem. I have a > device with two seriial LCDs and a RS485 link, so I am using three > different com3 ports. Likewise I've tried numerous fixes but still get > a rest about 2-3 times a day. I don't have any tasking or interrupts, > and nowhere do I call a subroutine from within another subroutine. My > prgram consists of a main loop, which calls a number of subroutines. > the problem is definetly in the swapping between conm3 ports and writing > to com3, but at this atge I'm not sure where. In order to wiat until a > queue was empty I used : > dowhile statusqueue (outwardbuffer) > loop > but this made things worse, which puzzled me. i now have a short delay > after each coms routine, but that's clumsy. Shall we swap code Charlie > and compare? > neil > > Harry J. White wrote: > > > You might want to look at another part of your program. If you are > > using a > > lot of subroutines and they call each other then you may be running > out of > > stack space and that would cause the program to hang. Just a thought. > > Harry > > > > -----Original Message----- > > From: charliem101101 [mailto:] > > Sent: Wednesday, October 08, 2003 6:38 AM > > To: > > Subject: [BasicX] Program hanging/resetting after a number of LCD com3 > > string outputs > > > > > > Hi all, > > > > I am having trouble with a program and any help would be very > > welcome. My program jumps between subroutines that represent > > different options on a menu. Each subroutine puts a string on the LCD > > using com3. > > > > The problem I get is that after an exact number of LCD updates the > > program either just hangs or resets itself. The number of updates > > varies from about 8 to 21 and seems to be affected by the size of > > queue defined for com3out. If you take a different path through my > > menu the problem still occurs after the same number of updates. > > > > I am writing to the LCD using putqueuestr(com3out, ...). > > > > I have tried the following - with no effects whatsoever on the > > problem; > > > > 1. Flushing and priming com3 before writing to it (using some code I > > found in the files section on this site) > > > > 2. Sticking in delays and sleeps before/after com3 commands > > > > Am I overloading a buffer ? > > > > Thanks for any help you can give me, > > > > CharlieM > > > > > > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890 > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> &yhad=1595053> > > > > > > > > >. > > [Non-text portions of this message have been removed] > > Yahoo! Groups Sponsor > > ADVERTISEMENT <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> Click Here! <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai > l/S=:HM/A=1595053/rand=135759174> > > > . > > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? camp=556 <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? camp=556&lineid=3614674&prop=egroupweb&pos=HM> &lineid=3614674&prop=egroupweb&pos=HM > > >. [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy o?YH=3707890&yhad=1595053> Click Here! <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai l/S=:HM/A=1595053/rand=541078398> > . [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 )

Neil, Heres what I use before I float away from the port: *** '--------------------------------------------------------------------------- -------- ' Project: AIUnit/OS ' AIUnit Operating System Library Object - WaitForTXC ' Version: 2.0 ' Created: April 2001 ' Revised: April 2002 ' Author: Dan Bielecki ' Studio.db. ' ' Syntax: Call WaitForTXC(port_number, queue_name) ' ' This utility waits for serial data to clear from the output ' queue and transmit out of the UART before returns to the caller. ' ' Copyright 2002 by Studio.db. and Dan Bielecki ' All rights Reserved. ' '--------------------------------------------------------------------------- --------- Attribute VB_Name = "WaitForTXC" Option Explicit '--------------------------------------------------------------------------- --------- Sub WaitForTXC(ByVal Parm1 As Byte, ByRef Parm2() As Byte) ' WAIT FOR QUEUE TO EMPTY Do While StatusQueue(Parm2) 'If data on the queue Call Delay(0.00) 'Let other tasks run Loop 'Until no data left on queue ' WAIT FOR DATA TO BE PUSHED OUT THE bxPORT UART Select Case Parm1 'Select the port number Case 1 'COM1 Port Do Until ((Register.USR And bx01000000) = bx01000000) 'bytes in UART? Call Delay(0.00) 'Let other tasks run Loop Case 2 'COM2 Port Do While ((Register.TIMSK And bx01000000) = bx01000000) 'bytes in UART? Call Delay(0.00) 'Let other tasks run Loop Case 3 'Com3 Port Do While ((RAMpeek(CuInt(21)) And bx01000000) = bx01000000) 'Bytes in UART? Call Delay(0.00) 'Let other tasks run Loop End Select End Sub ************* Hope this helps! .db. -----Original Message----- From: Neil Jepsen [mailto:] Sent: Wednesday, October 08, 2003 6:53 PM To: Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 string outputs Yeah I'm aware of that Dan but I'm only sending a few bytes, and I have tried a delay after the dowhile loop to empty the uart which seemed not to help too much. If I jerk the com3 away too quickly, then characters appear on the wrong LCD but it doesn't cause a crash. However I hope you are right . I presume the bit of code you refer to is do while ( rampeek(cuInt(Com3Status))and bx0100_0000)=bx0100_0000) loop I'll try it. neil Dan Bielecki wrote: > Neil, > > In addition to just waiting for the queues to empty, you also have to wait > for the UART to finish pushing the byte out and down the wire before you > float that com port away to another pin. I'll bet your reset is due to > that. You move that com3 three away before transmission is completed > fully. > > I have some code I will post. See if it fits your needs. > It works for any pin, any queue. > Give me a bit to pull from CD and strip out unrelated code. > > .db. > -----Original Message----- > From: Neil Jepsen [mailto:] > Sent: Wednesday, October 08, 2003 12:43 PM > To: > Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > Hi Guys > I am experiencing exactly the same problem. I have a > device with two seriial LCDs and a RS485 link, so I am using three > different com3 ports. Likewise I've tried numerous fixes but still get > a rest about 2-3 times a day. I don't have any tasking or interrupts, > and nowhere do I call a subroutine from within another subroutine. My > prgram consists of a main loop, which calls a number of subroutines. > the problem is definetly in the swapping between conm3 ports and writing > to com3, but at this atge I'm not sure where. In order to wiat until a > queue was empty I used : > dowhile statusqueue (outwardbuffer) > loop > but this made things worse, which puzzled me. i now have a short delay > after each coms routine, but that's clumsy. Shall we swap code Charlie > and compare? > neil > > Harry J. White wrote: > > > You might want to look at another part of your program. If you are > > using a > > lot of subroutines and they call each other then you may be running > out of > > stack space and that would cause the program to hang. Just a thought. > > Harry > > > > -----Original Message----- > > From: charliem101101 [mailto:] > > Sent: Wednesday, October 08, 2003 6:38 AM > > To: > > Subject: [BasicX] Program hanging/resetting after a number of LCD com3 > > string outputs > > > > > > Hi all, > > > > I am having trouble with a program and any help would be very > > welcome. My program jumps between subroutines that represent > > different options on a menu. Each subroutine puts a string on the LCD > > using com3. > > > > The problem I get is that after an exact number of LCD updates the > > program either just hangs or resets itself. The number of updates > > varies from about 8 to 21 and seems to be affected by the size of > > queue defined for com3out. If you take a different path through my > > menu the problem still occurs after the same number of updates. > > > > I am writing to the LCD using putqueuestr(com3out, ...). > > > > I have tried the following - with no effects whatsoever on the > > problem; > > > > 1. Flushing and priming com3 before writing to it (using some code I > > found in the files section on this site) > > > > 2. Sticking in delays and sleeps before/after com3 commands > > > > Am I overloading a buffer ? > > > > Thanks for any help you can give me, > > > > CharlieM > > > > > > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890 > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> &yhad=1595053> > > > > > > > > >. > > [Non-text portions of this message have been removed] > > Yahoo! Groups Sponsor > > ADVERTISEMENT <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> Click Here! <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai > l/S=:HM/A=1595053/rand=135759174> > > > . > > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? camp=556 <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? camp=556&lineid=3614674&prop=egroupweb&pos=HM> &lineid=3614674&prop=egroupweb&pos=HM > > >. [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy o?YH=3707890&yhad=1595053> Click Here! <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai l/S=:HM/A=1595053/rand=541078398> > . [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 )

They are the same. The important line is Do While ((RAMpeek(CuInt(21)) And bx01000000) = bx01000000) Dan Bielecki wrote: > Neil, Heres what I use before I float away from the port: > *** > '--------------------------------------------------------------------------- > -------- > ' Project: AIUnit/OS > ' AIUnit Operating System Library Object - WaitForTXC > ' Version: 2.0 > ' Created: April 2001 > ' Revised: April 2002 > ' Author: Dan Bielecki > ' Studio.db. > ' > ' Syntax: Call WaitForTXC(port_number, queue_name) > ' > ' This utility waits for serial data to clear from the output > ' queue and transmit out of the UART before returns to the caller. > ' > ' Copyright 2002 by Studio.db. and Dan Bielecki > ' All rights Reserved. > ' > '--------------------------------------------------------------------------- > --------- > Attribute VB_Name = "WaitForTXC" > Option Explicit > '--------------------------------------------------------------------------- > --------- > Sub WaitForTXC(ByVal Parm1 As Byte, ByRef Parm2() As Byte) > > ' WAIT FOR QUEUE TO EMPTY > Do While StatusQueue(Parm2) 'If data on the queue > Call Delay(0.00) 'Let other tasks run > Loop 'Until no data > left on > queue > > ' WAIT FOR DATA TO BE PUSHED OUT THE bxPORT UART > Select Case Parm1 'Select the port number > Case 1 'COM1 Port > Do Until ((Register.USR And bx01000000) = bx01000000) 'bytes in > UART? > Call Delay(0.00) 'Let other tasks run > Loop > Case 2 'COM2 Port > Do While ((Register.TIMSK And bx01000000) = bx01000000) > 'bytes > in UART? > Call Delay(0.00) 'Let other tasks run > Loop > Case 3 'Com3 Port > Do While ((RAMpeek(CuInt(21)) And bx01000000) = bx01000000) > 'Bytes in UART? > Call Delay(0.00) 'Let other tasks run > Loop > End Select > > End Sub > > ************* > Hope this helps! > > .db. > > > -----Original Message----- > From: Neil Jepsen [mailto:] > Sent: Wednesday, October 08, 2003 6:53 PM > To: > Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > Yeah I'm aware of that Dan but I'm only sending a few bytes, and I have > tried a delay after the dowhile loop to empty the uart which seemed > not to help too much. If I jerk the com3 away too quickly, then > characters appear on the wrong LCD but it doesn't cause a crash. > However I hope you are right . > I presume the bit of code you refer to is > do while ( rampeek(cuInt(Com3Status))and > bx0100_0000)=bx0100_0000) > loop > I'll try it. > neil > Dan Bielecki wrote: > > > Neil, > > > > In addition to just waiting for the queues to empty, you also have > to wait > > for the UART to finish pushing the byte out and down the wire before you > > float that com port away to another pin. I'll bet your reset is due to > > that. You move that com3 three away before transmission is completed > > fully. > > > > I have some code I will post. See if it fits your needs. > > It works for any pin, any queue. > > Give me a bit to pull from CD and strip out unrelated code. > > > > .db. > > > > > > -----Original Message----- > > From: Neil Jepsen [mailto:] > > Sent: Wednesday, October 08, 2003 12:43 PM > > To: > > Subject: Re: [BasicX] Program hanging/resetting after a number of > LCD com3 > > string outputs > > > > > > Hi Guys > > I am experiencing exactly the same problem. I have a > > device with two seriial LCDs and a RS485 link, so I am using three > > different com3 ports. Likewise I've tried numerous fixes but still get > > a rest about 2-3 times a day. I don't have any tasking or interrupts, > > and nowhere do I call a subroutine from within another subroutine. My > > prgram consists of a main loop, which calls a number of subroutines. > > the problem is definetly in the swapping between conm3 ports and writing > > to com3, but at this atge I'm not sure where. In order to wiat until a > > queue was empty I used : > > dowhile statusqueue (outwardbuffer) > > loop > > but this made things worse, which puzzled me. i now have a short delay > > after each coms routine, but that's clumsy. Shall we swap code Charlie > > and compare? > > neil > > > > > > > > Harry J. White wrote: > > > > > You might want to look at another part of your program. If you are > > > using a > > > lot of subroutines and they call each other then you may be running > > out of > > > stack space and that would cause the program to hang. Just a thought. > > > Harry > > > > > > -----Original Message----- > > > From: charliem101101 [mailto:] > > > Sent: Wednesday, October 08, 2003 6:38 AM > > > To: > > > Subject: [BasicX] Program hanging/resetting after a number of LCD com3 > > > string outputs > > > > > > > > > Hi all, > > > > > > I am having trouble with a program and any help would be very > > > welcome. My program jumps between subroutines that represent > > > different options on a menu. Each subroutine puts a string on the LCD > > > using com3. > > > > > > The problem I get is that after an exact number of LCD updates the > > > program either just hangs or resets itself. The number of updates > > > varies from about 8 to 21 and seems to be affected by the size of > > > queue defined for com3out. If you take a different path through my > > > menu the problem still occurs after the same number of updates. > > > > > > I am writing to the LCD using putqueuestr(com3out, ...). > > > > > > I have tried the following - with no effects whatsoever on the > > > problem; > > > > > > 1. Flushing and priming com3 before writing to it (using some code I > > > found in the files section on this site) > > > > > > 2. Sticking in delays and sleeps before/after com3 commands > > > > > > Am I overloading a buffer ? > > > > > > Thanks for any help you can give me, > > > > > > CharlieM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > > Yahoo! Groups Sponsor > > > ADVERTISEMENT > > > > > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > > > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > > o?YH=3707890 > > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > > > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > > o?YH=3707890&yhad=1595053> &yhad=1595053> > > > > > > > > > > > > >. > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > > Yahoo! Groups Sponsor > > > > ADVERTISEMENT > > > > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > > > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > > o?YH=3707890&yhad=1595053> Click Here! > > > > > <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai > > l/S=:HM/A=1595053/rand=135759174> > > > > > . > > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Sponsor > > > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 > 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? > camp=556 > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 > 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? > camp=556&lineid=3614674&prop=egroupweb&pos=HM> > &lineid=3614674&prop=egroupweb&pos=HM> > > > > > > > > >. > > [Non-text portions of this message have been removed] > > Yahoo! Groups Sponsor > > ADVERTISEMENT > > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=17065542 > 05:HM/A=1595053/R=0/SIG=124gf29oe/*http://ashnin.com/clk/muryutaitakenattogy > o?YH=3707890&yhad=1595053> Click Here! > > <http://us.adserver.yahoo.com/l?M=244522.3707890.4968055.1261774/D=egroupmai > l/S=:HM/A=1595053/rand=541078398> > > > . > > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=1706554205:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3614674&prop=egroupweb&pos=HM > > >. [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 )

From: Harry J. White <> > > From: charliem101101 [mailto:] > >> The problem I get is that after an exact number of LCD >> updates the program either just hangs or resets itself. >> The number of updates varies from about 8 to 21 and >> seems to be affected by the size of queue defined for >> com3out. If you take a different path through my >> menu the problem still occurs after the same number of >> updates. >> >> I am writing to the LCD using putqueuestr(com3out, ...). Well, if I were you I'd avoid using PutQueueStr unless there is a very good reason to use it, such as communicate to another task, or get the highest possible speed. PutQueueStr is expensive in RAM. > You might want to look at another part of your program. > If you are using a lot of subroutines and they call > each other then you may be running out of stack space > and that would cause the program to hang. Just a thought. This would be my guess, too. This problem (and Neil's) have the symptoms of a stack overflow. Flattening the call tree and avoiding local variables can sometimes work, depending on the overall program structure. More often, though, I think it makes more sense to minimize the use of static variables and use local variables as much as possible. As an example, if you have the new V2.1 IDE, try creating a new serial LCD project (menu New Project -- SerialLCD2x16). Module LCDSerialPort handles all 3 BasicX com ports and includes code that flushes the serial ports. It may be easy to adapt to your needs. The code also minimizes the use of static variables. The variables take up 30 bytes, which leaves 371 bytes for the main stack. When you call LCD code, maybe 88 bytes of that stack space is used. That sounds like a lot, except that whenever you return from that code, that leaves all 371 bytes available for whatever else you need to do. Listed below is an example program that illustrates how much stack is used by the LCD code: -- Frank Manning -- NetMedia, Inc. '----------------------------------------------- Option Explicit Private Const StackSize As Integer = 110 Private TaskStack(1 To StackSize) As Byte Private Done As Boolean '----------------------------------------------- Public Sub Main() Dim LimitFound As Boolean Dim N As Integer ' This is an example value to load into the ' task stack. For completeness, this test ' should be repeated as required with ' different random values. Const TestValue As Byte = 255 Done = False For N = 1 To StackSize TaskStack(N) = TestValue Next CallTask "Main2", TaskStack Do Until (Done) ' Null Loop ' This is in case the task isn't really done yet. LockTask Debug.Print Debug.Print Debug.Print "Stack use = "; LimitFound = False For N = StackSize To 1 Step -1 If (TaskStack(N) <> TestValue) Then Debug.Print CStr(N) & " bytes" LimitFound = True Exit For End If Next If (Not LimitFound) Then Debug.Print "*** Error ***" End If Debug.Print Debug.Print "Stack contents:" Debug.Print Debug.Print " Index Value" Debug.Print For N = 1 To StackSize Debug.Print " "; CStr(N); " "; Debug.Print CStr(TaskStack(N)) Next Debug.Print End Sub '----------------------------------------------- Private Sub Main2() Const PortNumber As Byte = 1 Dim Column As Byte Const Square As Byte = 219 Call LCDInitialize(PortNumber, 9600, 0, 0) Call LCDMoveCursor(1, 1) Call LCDPutStr(" LCD2x16") For Column = 1 To MaxColumn Call LCDMoveCursor(2, Column) Call LCDPutByte(Square) Call Delay(0.05) Next For Column = 1 To MaxColumn Call LCDMoveCursor(2, Column) Call LCDPutStr(" ") Call Delay(0.05) Next Done = True End Sub '-----------------------------------------------

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

From: Dan Bielecki <> > Very similar. But I have a call to DELAY in there > so that the BX task-swaps and the bxOS has a chance > to do its thing during that time. I'd be surprised if that makes a difference, since Neil is not using tasking. -- Frank Manning -- NetMedia, Inc.

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

Neil, Does it reset all on it own or hangs and you reset manually? If it hangs & you reset...Id say the queues are filling up and its in one of those queue-waits thats documented that you shouldn't do. If it resets all on its own it may just be the stacks. The thing blows out the stack, and has no place to go in code, so it resets and starts at the zero vector.... (same as if you performed a reset.) *** Something else to look at: When I first started playing with my BX back in '99 I mounted the chip and Dev board vertically in an old VIVA modem tower case. Just cuz the case was laying around. I gutted the modem and mounted the board in the case. Every so often, I would come upstairs and take a look at it and it would have reset just like you describe. I knew it reset because I have a clock function that places the current time on the LCD+. Since the BX cant save the RTC values, a reset always starts the RTC back at 00:00:00 and it would start the clock function again. I could tell how long ago the reset occurred based on the RTC values. 01:11:25 for example would be a reset that occurred 1 hour, 11 minutes and 25 seconds ago. Id resync the clock to current time and it would run fine again for awhile. For the life of me I could not figure out why the thing was resetting (sound familiar?). Turns out, the VIVA modem case is about 1 1/2 inches wide and one day I just happened to peer inside and noticed that it seemed warmer then usual. I figured that because of the close quarters of the VIVA case that it wasn't getting enough air flow across the actual chip. I went out and got a horizontal case instead the VIVA vertical one, and made sure it had more clearance and some vents for air. I swapped the cases and the random resets went away. I put it back in the VIVA case a few weeks later and the resets came back. Put it back in the newer case and the resets went away again. Its home for good is the horizontal case, not the vertical VIVA. I dont believe the horizontal vs vertical was the issue. I just think the VIVA didnt provide adequate air flow to draw the heat from the onboard regulator away. Now I just keep it in the horizontal case. That onboard regulator can toss out some heat, even at 9-volts in. I dont know if this would help you at all.....but it might be something to look into...since you are experiencing the reset off and on, without any rhyme or reason to. .db. -----Original Message----- From: Neil Jepsen [mailto:] Sent: Wednesday, October 08, 2003 8:33 PM To: Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 string outputs They are the same. The important line is Do While ((RAMpeek(CuInt(21)) And bx01000000) = bx01000000) [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 )

Dan I have a 2sec watchdog. The unit is an indoor basketball remote control panel. It monitors the RTC, and sends the RTC, team scores fouls etc to a 10' x 6' remote LED large digit display via RS485.( one way only...there is no reverse data). In addition, there are two LCDs on the control panel which repeats the RTC and team scores etc. If I set the scores to a known number such as 1 2 3 4, if it watchdogs, the scores come back to 0 and the RTC is lost. If I leave the thing running, it watchdogs about once or twice a day, but sometimes ( like today) it will run for 2 days without failing. There are no tasks, and the program is v simple and about 500-600 lines. the main loop simply calls a number of subroutines, such as : do_setup set_clock do_clock do_scores read_IO read_RTC etc. All variables are global. There are no EEPROM writes, but several var are persistent, such as the set ups. I thinks you are on the right track becos do while ( status...) sleep(12) loop certainly was unreliable. Putting this back in decreased the reliability 10 fold. Today I included the RAMpeek etc code to monitor the UART so I'll need about 3 days to see if it has made any difference. neil Dan Bielecki wrote: > Neil, > > Does it reset all on it own or hangs and you reset manually? > > If it hangs & you reset...Id say the queues are filling up and its in > one of > those queue-waits thats documented that you shouldn't do. > > If it resets all on its own it may just be the stacks. > The thing blows out the stack, and has no place to go in code, so it > resets > and starts at the zero vector.... > (same as if you performed a reset.) > *** > Something else to look at: > > When I first started playing with my BX back in '99 I mounted the chip and > Dev board vertically in an old VIVA modem tower case. Just cuz the > case was > laying around. I gutted the modem and mounted the board in the case. > Every so often, I would come upstairs and take a look at it and it would > have reset just like you describe. I knew it reset because I have a clock > function that places the current time on the LCD+. Since the BX cant > save > the RTC values, a reset always starts the RTC back at 00:00:00 and it > would > start the clock function again. I could tell how long ago the reset > occurred based on the RTC values. 01:11:25 for example would be a reset > that occurred 1 hour, 11 minutes and 25 seconds ago. Id resync the > clock to > current time and it would run fine again for awhile. For the life of me I > could not figure out why the thing was resetting (sound familiar?). > > Turns out, the VIVA modem case is about 1 1/2 inches wide and one day > I just > happened to peer inside and noticed that it seemed warmer then usual. I > figured that because of the close quarters of the VIVA case that it wasn't > getting enough air flow across the actual chip. I went out and got a > horizontal case instead the VIVA vertical one, and made sure it had more > clearance and some vents for air. I swapped the cases and the random > resets > went away. > > I put it back in the VIVA case a few weeks later and the resets came back. > Put it back in the newer case and the resets went away again. Its > home for > good is the horizontal case, not the vertical VIVA. I dont believe the > horizontal vs vertical was the issue. I just think the VIVA didnt provide > adequate air flow to draw the heat from the onboard regulator away. Now I > just keep it in the horizontal case. That onboard regulator can toss out > some heat, even at 9-volts in. > > I dont know if this would help you at all.....but it might be something to > look into...since you are experiencing the reset off and on, without any > rhyme or reason to. > > .db. > > > -----Original Message----- > From: Neil Jepsen [mailto:] > Sent: Wednesday, October 08, 2003 8:33 PM > To: > Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > They are the same. The important line is > Do While ((RAMpeek(CuInt(21)) And bx01000000) = bx01000000) > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=1706554205:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3614674&prop=egroupweb&pos=HM > > >. [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 )

From: Dan Bielecki <> > If it hangs & you reset...Id say the queues are > filling up and its in one of those queue-waits > thats documented that you shouldn't do. [...] Could you be more specific? Do you mean GetQueue or a similar call? It's not clear what queue-wait you're referring to. -- Frank Manning -- NetMedia, Inc.

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

Lots of replies coming - thanks very much If I reduce the number of module level variables and therefore increase the stack size, the program will carry on for more steps until it hangs/resets. If I reduce the number of subroutines and just have more levels of loops then the same thing happens. People have mentioned that this could be down to a stack problem - what is a stack, how does it work and how will jumping from one subroutine to another upset things !? Thanks again for your replies all, CharlieM --- In , "Frank Manning" <fmanning@n...> wrote: > From: Dan Bielecki <Dan.Bielecki@A...> > > > If it hangs & you reset...Id say the queues are > > filling up and its in one of those queue-waits > > thats documented that you shouldn't do. [...] > > Could you be more specific? Do you mean GetQueue or a similar > call? > > It's not clear what queue-wait you're referring to. > > -- Frank Manning > -- NetMedia, Inc.

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

From: Dan Bielecki <> > In addition to just waiting for the queues to empty, > you also have to wait for the UART to finish pushing > the byte out and down the wire before you float that > com port away to another pin. I'll bet your reset > is due to that. This should not reset the processor. > You move that com3 three away before transmission > is completed fully. [...] This could definitely cause garbled communications, but the processor should not reset. If it does reset, there's probably a bug in either the BasicX compiler or engine. -- Frank Manning -- NetMedia, Inc.

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

From: charliem101101 <> > If I reduce the number of module level variables and > therefore increase the stack size, the program will > carry on for more steps until it hangs/resets. That's a step in the right direction. > If I reduce the number of subroutines and just have > more levels of loops then the same thing happens. It depends on what you're doing, but generally you want to increase, not decrease the number of subroutines. Not always, but usually. > People have mentioned that this could be down to a > stack problem - what is a stack, how does it work > and how will jumping from one subroutine to another > upset things !? A stack is an area of memory where most of the actual work is carried out by a program. The stack grows and shrinks depending on what the program is doing. When you call a subroutine, the stack grows by 9 bytes due to the subroutine's overhead. More memory is added to that 9 bytes if you declare local variables inside the subroutine. For example, if you declare a 32 bit integer as a local variable, the subroutine takes up 9 + 4 = 13 bytes. Depending on what the subroutine does, it may need even more memory. Other subroutines may be called, for example. If subroutine A calls B, then both are put on the stack. Overhead is 9 + 9 = 18, plus local variables and other stuff. Naturally, with all this overhead from subroutine calls and local variables, the obvious way to decrease stack use is to make everyting a global variable and call as few subroutines as possible, right? Not so fast. The key thing to remember is that when you return from a subroutine, that 9 bytes of overhead, plus all the other memory it uses, is reclaimed by the system and made available for other uses. Want to see how to process 600 bytes on a 400 byte machine? Check out messages 13934 and 13951. -- Frank Manning -- NetMedia, Inc.

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

>From Neil Jepsen <> > Frank Manning wrote: > >> From: Dan Bielecki <> >>> >>> You move that com3 three away before transmission >>> is completed fully. [...] >> >> This could definitely cause garbled communications, but >> the processor should not reset. If it does reset, >> there's probably a bug in either the BasicX compiler or >> engine. > > You are correct Frank. I have had this problem( briefly) > and all that happens is that tail end data intended for > LCD1 appears on LCD2. My problem is a bit more insidious. > It causes the processor to hang, and then the watchdog > resets. Disclaimer -- I don't have much experience with watchdogs. The main thing I'd ask is that if you have a 2 s watchdog in a loop of some kind, are you absolutely positive the loop never takes more than 2 s? If not, then adding a watchdog may add a failure mode, and a random one at that. In other words, the watchdog might end up reducing rather than increasing reliability. I should probably shut up at this point before my big mouth gets me in trouble. > What did you mean when you commented on my comment re > not calling any subroutines from within other > subroutines. this was not a deliberate decision. It > just worked out that way. In that case there's probably no problem. The concern was stack overflow, which I'm less worried about here, the more I think about it, since the program can run for long periods without problems. -- Frank Manning -- NetMedia, Inc.

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

Frank, I mean ANY queue function. Lets say its a queue of 39 bytes in size for example. Nine of the bytes are the queue overhead bytes, that leaves 30 usable queue-bytes. If one were to put 31 bytes on the queue....with at PutQueueStr or a do loop with a PutQueue of one byte each cycle, the queue will bind up and the BX will hang....waiting for space on the queue to free up so it can put that 31st byte on it. If there is no function to remove the bytes...your dead, only a reset or a WatchDog timeout will save you. Same goes for a queue function that fetches data. If one were to put an integer on a queue and then later try to fetch a Single or Long type, for example, the queue will bind, waiting for the extra bytes. If the WatchDog function is active, the Processor will reset after the timeout. if any queue is in a bind. Sometimes this is desired, other times its not. That is the purpose of the WatchDog after all, to recover the MCU from these types of things and restart. Personally, I dont code using the WatchDog, but Neil says he has the function active. If he is writing persistent, which must be delayed, and also pushing data out a pin....it could be something as simple as a timing factor where the WatchDog is kicking in....like during the delay for the Persistent write. Could be that the bxOS is a little slow this cycle around moving the current queue-byte down from software to the UART-hardware level...the WatchDog kicks in and *poof* an unwanted system reset. Neil: What happens if you put logic in to reset the WatchDog, inside that Do Loop thats waiting for the UART to flush? That would be ensuring that the MCU isnt going to be reset while the UART is being flushed by the bxOS. Because the Queue-to-UART-hardware data movement can not be guaranteed to be fixed number of milliseconds for each byte being moved, one must account for this in logic. That each movement from the Application to the Queue to the bxOS to the UART and then out is always going to be a different timing value. This is the primary reason I make calls to DELAY with the 0.00 value. The MCU cycles the tasks during the call. Main( ) is just one task. You may not code Tasks...but you are at least running two of them....the bxOS and Main( ). If you have Main( ) doing all the work and not giving the bxOS enough cycle-time the bxOS suffers, the built in cycling kicks in and the bxOS overrides the Main( ) at some point to perform its internal functions. This task swap may happen at a time you, as a Developer, may not desire it to happen...like during a queue write or something critical. If Neil's Main( ) is pumping data out, and there's no designed trap door for the bxOS to perform internal tasks...at some point its gonna override the current Main( ) process and drop down into the bxOS to perform an internal function using the built-in trap door. By liberal use of DELAY calls of 0.00, the Developer controls the bxOS trap door to some degree, and according to the DELAY function, if there is nothing to swap, the current task returns and continues. Neil, try a reset to the WatchDog inside the loop waiting for the UART if you must use the WatchDog. If you dont really need the WatchDog, comment-out all the watchdog logic and tell us what happens. .db. -----Original Message----- From: Frank Manning [mailto:] Sent: Friday, October 10, 2003 8:49 AM To: Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 string outputs From: Dan Bielecki <> > If it hangs & you reset...Id say the queues are > filling up and its in one of those queue-waits > thats documented that you shouldn't do. [...] Could you be more specific? Do you mean GetQueue or a similar call? It's not clear what queue-wait you're referring to. -- Frank Manning -- NetMedia, Inc. Yahoo! Groups Sponsor <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? camp=556&lineid=3614674&prop=egroupweb&pos=HM> <http://us.adserver.yahoo.com/l?M=259395.3614674.4902533.1261774/D=egroupmai l/S=:HM/A=1524963/rand=924650807> > . [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 )

From: Dan Bielecki <> > [...] > Nesting subroutines is a basic form of good software > design. Agreed. > I dont believe the BX has any problem with nesting > routines, other then blowing out the stack space > overall by making too many levels or by recursion. > A sure fire way to do it on a BX is to make > recursive calls....where SubA() calls SubB() which > calls SubC() which in turn, makes a call to one of > the previous Subs....like SubA() or SubB(). That, > I have found will almost always blow out a at 2 or > 3 levels deep. Recursion is allowed on a BX, just > dont go more then 2 levels deep. [...] Well, that limit strongly depends on how much RAM is being used by other code and data. The theoretical upper limit is about 40 levels for a BX-24, considerably higher on a BX-01 with 64 KB RAM. The example program listed below goes 35 levels deep on a BX-24. The same program goes 7232 levels deep on a BX-01 with 64 KB RAM, which incidentally beats VB6 (6586 deep) on a Pentium. Check out message 10472. -- Frank Manning -- NetMedia, Inc. '-------------------------------------- Option Explicit Dim Counter As Integer '-------------------------------------- Sub Main() Counter = 0 Debug.Print "Start" Call Sub1 End Sub '-------------------------------------- Sub Sub1() DisplayCounter Counter = Counter + 1 Call Sub1 End Sub '-------------------------------------- Sub DisplayCounter() Debug.Print "Sub1:" & CStr(Counter) End Sub '--------------------------------------

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

wrote > Frank Manning wrote: > >> wrote >>> >>> You move that com3 three away before transmission >>> is completed fully. [...] >> >> This could definitely cause garbled communications, but >> the processor should not reset. If it does reset, >> there's probably a bug in either the BasicX compiler or >> engine. > > Can we quote you on that bug statement? You just did. > (Just kidding....) > > If one were to put an Integer onto a Queue, and it starts > the data movement from Application-to-OS-to-UART and > then the UART begins pumping the bits out with each > clock rise and fall......and during the rise of....lets > say....between the fifth and sixth clock rise/fall of > the second integer-byte.....that Com3 port is moved away > with logic...that port is not going to function > correctly, period. If that's true, the failure should be quite easy to reproduce. Do you have some code that demonstrates the problem? > [...] > And just for kicks: In doing so, by moving Com3 away > before transmissions are fully complete....do I > shorten the Pin-Life because of the aneurism? Other members of this forum have addressed the I/O pin life question much better than I can. Check out messages 14446 and 14455. -- Frank Manning -- NetMedia, Inc.

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

Dan You said ".........Personally, I dont code using the WatchDog,....." Likewise I never begin code to include a watchdog, or use it to wall paper over a problem.Can cause more problems than it will solve. However in this case I had a problem that only happened once a day, and a processor hang would cause the untrained operator to start pushing buttons randomly. Because I had 4 of these units out there and they had to be delivered in time for a large tournament, I just didn't have the time(week) to locate the bug so the WD solved the problem in the short term. Now that the tournament is over i can get to the bottom of the bug. My main loop runs 2-3 times per second, and calls the 3 subroutines that open the three separate com3 loops. I like coding this way because by simply no-oping a call in the main() you can easily isolate a whole section of code. My WD is refreshed at the end of the main() See my reply to Frank . neil Dan Bielecki wrote: > Frank, I mean ANY queue function. > > Lets say its a queue of 39 bytes in size for example. > Nine of the bytes are the queue overhead bytes, that leaves 30 usable > queue-bytes. > > If one were to put 31 bytes on the queue....with at PutQueueStr or a > do loop > with a PutQueue of one byte each cycle, the queue will bind up and the BX > will hang....waiting for space on the queue to free up so it can put that > 31st byte on it. If there is no function to remove the bytes...your dead, > only a reset or a WatchDog timeout will save you. > > Same goes for a queue function that fetches data. If one were to put an > integer on a queue and then later try to fetch a Single or Long type, for > example, the queue will bind, waiting for the extra bytes. > > If the WatchDog function is active, the Processor will reset after the > timeout. if any queue is in a bind. Sometimes this is desired, other > times > its not. That is the purpose of the WatchDog after all, to recover > the MCU > from these types of things and restart. Personally, I dont code > using the > WatchDog, but Neil says he has the function active. > > If he is writing persistent, which must be delayed, and also pushing data > out a pin....it could be something as simple as a timing factor where the > WatchDog is kicking in....like during the delay for the Persistent write. > Could be that the bxOS is a little slow this cycle around moving the > current > queue-byte down from software to the UART-hardware level...the WatchDog > kicks in and *poof* an unwanted system reset. > > Neil: What happens if you put logic in to reset the WatchDog, inside that > Do Loop thats waiting for the UART to flush? That would be ensuring that > the MCU isnt going to be reset while the UART is being flushed by the > bxOS. > Because the Queue-to-UART-hardware data movement can not be guaranteed > to be > fixed number of milliseconds for each byte being moved, one must > account for > this in logic. That each movement from the Application to the Queue > to the > bxOS to the UART and then out is always going to be a different timing > value. This is the primary reason I make calls to DELAY with the 0.00 > value. The MCU cycles the tasks during the call. > > Main( ) is just one task. You may not code Tasks...but you are at least > running two of them....the bxOS and Main( ). If you have Main( ) > doing all > the work and not giving the bxOS enough cycle-time the bxOS suffers, the > built in cycling kicks in and the bxOS overrides the Main( ) at some point > to perform its internal functions. This task swap may happen at a > time you, > as a Developer, may not desire it to happen...like during a queue write or > something critical. > > If Neil's Main( ) is pumping data out, and there's no designed trap > door for > the bxOS to perform internal tasks...at some point its gonna override the > current Main( ) process and drop down into the bxOS to perform an internal > function using the built-in trap door. By liberal use of DELAY calls of > 0.00, the Developer controls the bxOS trap door to some degree, and > according to the DELAY function, if there is nothing to swap, the current > task returns and continues. > > Neil, try a reset to the WatchDog inside the loop waiting for the UART if > you must use the WatchDog. > If you dont really need the WatchDog, comment-out all the watchdog > logic and > tell us what happens. > > .db. > -----Original Message----- > From: Frank Manning [mailto:] > Sent: Friday, October 10, 2003 8:49 AM > To: > Subject: Re: [BasicX] Program hanging/resetting after a number of LCD com3 > string outputs > From: Dan Bielecki <> > > > If it hangs & you reset...Id say the queues are > > filling up and its in one of those queue-waits > > thats documented that you shouldn't do. [...] > > Could you be more specific? Do you mean GetQueue or a similar > call? > > It's not clear what queue-wait you're referring to. > > -- Frank Manning > -- NetMedia, Inc. > > Yahoo! Groups Sponsor > > <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17065542 > 05:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir? > camp=556&lineid=3614674&prop=egroupweb&pos=HM> > > <http://us.adserver.yahoo.com/l?M=259395.3614674.4902533.1261774/D=egroupmai > l/S=:HM/A=1524963/rand=924650807> > > > . > > > [Non-text portions of this message have been removed] > Yahoo! Groups Sponsor > ADVERTISEMENT > <http://rd.yahoo.com/M=244522.3707890.4968055.1261774/D=egroupweb/S=1706554205:HM/A=1595054/R=0/SIG=124ukap9t/*http://ashnin.com/clk/muryutaitakenattogyo?YH=3707890&yhad=1595054 > > >. [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 )

From: Dan Bielecki <> > [...] > Because the Queue-to-UART-hardware data movement can not be > guaranteed to be fixed number of milliseconds for each byte > being moved, one must account for this in logic. That each > movement from the Application to the Queue to the bxOS to > the UART and then out is always going to be a different > timing value. This is the primary reason I make calls to > DELAY with the 0.00 value. The MCU cycles the tasks during > the call. > > Main( ) is just one task. You may not code Tasks...but you > are at least running two of them....the bxOS and Main( ). If > you have Main( ) doing all the work and not giving the bxOS > enough cycle-time the bxOS suffers, the built in cycling > kicks in and the bxOS overrides the Main( ) at some point to > perform its internal functions. This task swap may happen at > a time you, as a Developer, may not desire it to > happen...like during a queue write or something critical. With the exception of the timeout version of GetQueue, the OS is designed so that a task swap is not allowed in the middle of a queue operation. The reason is that queues are intended for intertask communication. You don't want two or more tasks trying to read or write to a queue at the same time. > If Neil's Main( ) is pumping data out, and there's no > designed trap door for the bxOS to perform internal > tasks...at some point its gonna override the current Main( ) > process and drop down into the bxOS to perform an internal > function using the built-in trap door. By liberal use of > DELAY calls of 0.00, the Developer controls the bxOS trap > door to some degree, and according to the DELAY function, if > there is nothing to swap, the current task returns and > continues. There's one thing that I'm a bit confused about. If you're only running one task, what does it buy you to call Delay 0.0? Whenever you call Delay, there is additional overhead. Each call increases the program size, and also requires a small but nonzero amount of execution time. What specifically do you get in return? Is the overall performance higher? Is the reliability higher? I'm not sure I understand the rationale for executing a zero delay if you're not using multitasking. -- Frank Manning -- NetMedia, Inc.

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

I wrote: > With the exception of the timeout version of > GetQueue, the OS is designed so that a task > swap is not allowed in the middle of a queue > operation. [...] Correction -- this applies to both versions of GetQueue, including the timeout version. -- Frank Manning -- NetMedia, Inc.

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

From: Dan Bielecki > From: Frank Manning >> >> There's one thing that I'm a bit confused about. If you're >> only running one task, what does it buy you to call >> Delay 0.0? >> [...] >> I'm not sure I understand the rationale for executing a zero >> delay if you're not using multitasking. > [...] > When DELAY(0.0) is added, Main() now has the ability to tell > the OS to go check thru the task list and cycle thru each > task and if nothing else has precedence at this time, to > come back to this task and continue to execute. The very act > of doing so swaps out Main() logic and performs OS logic. > Now the OS has processor time, and does it's thing.... > shifting bytes, counting, looking around in memory > addresses.....whatever you guys have to do at the OS level. > [...] Which is what? That's the key question. I can't think of anything the OS is being somehow induced to do that it's not already doing. I also asked Jack, who originally wrote the code, and he agrees with this. If you want to call Delay 0.0 in a non-multitasking program, well, fine, it probably doesn't hurt. But we can't think of any specific, measurable benefits, and so far nobody's told us of any specific, measurable benefits. I will say there is one disadvantage to taking zero delays and sprinkling them around indiscriminately -- it may lead to a maintenance headache. Here's the problem -- let's say you write code for a general purpose library, and you use that code later in a multitasking program. Whenever a Delay (or Sleep) is executed, the calling task is unlocked. Now whenever you want to lock a task, you have to somehow remember which subprograms call Delay, because they automatically unlock the task. If you lock a task, then accidentally call a subprogram like that without realizing it, the resulting bug could be very difficult to track down. Now if somebody can tell me what benefits there are to zero delays in a single- tasking program, I'm all ears. Let us know what they are, show us the code, something. So far I haven't seen much persuasive evidence. -- Frank Mannnig -- NetMedia, Inc.

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

> Whenever a Delay (or Sleep) is executed, the calling task is > unlocked. Now whenever you want to lock a task, you have to > somehow remember which subprograms call Delay, because they > automatically unlock the task. If you lock a task, then > accidentally call a subprogram like that without realizing it, the > resulting bug could be very difficult to track down. There you go again. You keep thinking that the only way to multitask is to use the OS System Level commands like CALLTASK, the SEMIPHORE instructions, LOCK/UNLOCK task instructions..... You guys have already verified that Boolean instructions were atomic in nature awhile back. You may have unlocked the task from a system point of view based on the way you keep reading your logic......I know which task is active and which one I need active if it isnt. I have a boolean flag that tells me. The only one that is going to properly perform work in the MCU is the one that set the boolean flag on. Even if were to code something along the lines of what you are saying, Im not going to have a conflict with Task-B if Task-A is the "active" task at the moment. My method is similar to the SEMIPHORE instruction except that I dont have the overhead and the temp variables created by the compiler in determining and working out the SEMIPHORE evaluation. Eventually, the SEMIPHORE instruction goes down to the atomic level and the bit is evaluated on or off. I just perform my method at the application level and avoid the system call. These, Im setting true or false upfront, without the evaluation overhead. Because of this, I know that Task-B has the timeslice in the MCU. Even if the system cycles the tasks and you bring my Task-A into the forefront, my Task-A knows that Task-B is the active task, swaps out with the DELAY and you again cycle thru. At some point, my Task-B comes cycling back based on your tasking methods and it continues right where it left off. I recall you all saying it cycles in a round-robin type of method, so all tasks have an equal share of MCU timeslice. I dont round-robin. The most important task takes presidence. Could be an OS task, could be my Task-A or Task-B,C,D ect. Who ever needs the MCU at that moment is the task in the MCU. DELAY allows this if coded properly. No, offence or anything....but without the memory map of What and Where the bxOS is using in determining the current Round-Robin value, which stack- address to use for the moment or where the SEMIPHORE values are stored in order to inquire upon them and condiction logic with....one must make and map our own paths thru the BX land. In my case, I even need to go to the tasking engine map. I dont have one available from you guys anywhere in which to reference to I design my own. I was back at this logic writting stage back when I was asking if the boolean was at the atomic level. Im well past that now. I multi-task....just not in the manor you keep thinking. *** If your looking for what lines of code you are executing in the course of the DELAY in source....I dont know. I dont have bxEngine source. All I have what you all have issued. Atmel and BasicX docs. But just the very fact that IM at the OS level means that your code is active in the MCU. I dropped into it and it came to the fore, with the DELAY. And using the example code that I showed you this past weekend....your OS will swap when I say....(When the flag controlling the DO LOOP is TRUE) You keep thinking and looking at the DELAY source-code and the logic that the call is performing.... Im take advantage of what the BX engine does in order to even make the that DELAY call....not execute the actual instruction. That was the price...the ram price. The actual instruction is just the door and one must pay the price to use the door. Does this help ya in any way in understanding? .db.

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

That makes sence. Even according to the manuals the queue is the method that is prefered in inter-task communications. They would have to be secure between tasks. Now I have a question. If I put 5 bytes of data on a queue ("XXXXX") with PutQueueStr, do you lock once for all five bytes or 5 times, once for every byte. Im gonna first-guess ya here and say 5 times....that the PutQueueStr method actually performs the same instructions that PutQueue does....just surrounded by some string MID/LEN type logic and math to roll thru the string. Do you place all 5 and calc and move the pointer by the 5 address blocks, or place one-by-one and just let the low level logic built in to manage the pointers? .db.

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

> Now if somebody can tell me what benefits there are to zero delays > in a single- tasking program, I'm all ears. Let us know what they > are, show us the code, something. So far I haven't seen much > persuasive evidence. The benefit is that the bxTasking Engine is brought to the fore in the MCU. It has to be in order to check the round-robin pointer and see that it says "0" based on how you count multi-tasks. In order to even get the engine in there, the OS went thru all kinds of paces in Atmel in order to get it there. The Application logic is swapped. Because of this, now...the OS is the "active" task in the MCU. Now that the engine active it has the timeslice to go and do whatever it takes to smoothe out the timing hickup that randomly resets the processor. *** By the way....personally, I beleive that round-robin counter should actually read as "2". The OS and Main() since both these tasks are running and sharing the CPU 50-50. Then three, four, ect if CallTask is used. What is the Official Name of that round-robin counter...so I dont have to keep calling it that. Where's it at in bxMemory? (see?...Im gonna map that engine...a byte at a time if I have too...) .db.

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

> I think I understand what you're suggesting. > Please write two versions of a most simple example, perhaps a loop that > spins and inverts a pin, and write one that does that faster with your > technique. > As I recall, a simple loop can generate something like 8KHz. My counters > await your code. You do realize that the actual clock speed cant be increased by this method, dont you? (Say yes...) That is not what this is about. If a 8KHz clock is used and the Engine takes 50% and Main() takes 50% Thats 4KHz each. What using DELAY does is allow that 4KHz window of time to be sliced up and given away to another task. Lets say for example that Main() code only contains enough instructions to be performed in...hummm lets say 3KHz...That leaves 1KHz left over. Force Main to swap with a Delay at the point where you know its safe to do so, and that 1KHz now is given to the Engine. Now lets say that the engine relies on a full 4KHz time slice window. You just completed the Main() work in 3/4 of the time that the work would have been completed. And the Engine, uses the remaining 1KHz + 3 KHz of its normal secheduled timeslice. It still has a full 4KHz slice. It's done now and its transfers back to Main(). Main() now is in the OS timeslice if you were to diagram the actual slices. Example: E=Engine, M=Main() _=time slice...8 slices to the tick. _ _ _ _ _ _ _ _ M M M M E E E E Without Delay _ _ _ _ _ _ _ _ |_____________Master/Slave task swap 50-50 _ _ _ _ _ _ _ _ M M M E E E E M With Delay(0.00) _ _ _ _ _ _ _ _ |________________Cooperative Task Swap Main() now has the begining of the next instruction-set in core already -- on the last 8th-slice; of what would have been the Engine's last slice. Just because Main() didnt need the full slice in the beginning. The system clock is still ticking at 8MHz...total. Only a different timing crystle can change that. Its just that the OS isnt in total control of managing the slicing any more. It can be nudged into sharing the management. Then, depending on how you design the Main() management functions, determines the overall extent of the Cooperative Task Management. That DoLoop sample I posted last weekend shows how to grab about 99% of the management. Only thing left for the engines is that which is needed for the stack management. Let me think of something generic to post. You know by now how I feel about freebee code. I could make two objects to test, but you may not feel that the test is valid since, without looking at source.....I could design and cause one test to be slower then the other. (Never!) But the question could be raised as to what each program is actually doing and only source will show that. Give me some time to think of something to use as a generic working model for this. Its gonna have to be more then just some pin transitions. Those may be executable within 1 time slice of the full 4KHz for all I know. Maybe something that requires multiple time slices thru the engine. Frank? You still there in this thread? What is the longest BasicX instruction set generated by the compiler? Lets use that to start with....see if I can come up with a model using something like that. .db.

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

Now you have me puzzled. I thought you said you understood the keyboard graphic? Now you dont? I was this thinking this morning about some code to show the time-slice benifits...something you wanted to measure.....this is just off the cuff but you could try this: Create two task stacks. Stack A and stack B. Start the two tasks with CALLTASK. Task one logic is a doloop that sets on and off the red led. Task two logic is a doloop that sets on and off the green led. Make the code exactly the same in each task except for the led pin numbers (25 and 26) and a CALL DELAY(0.00) anytime you change the state of the green led. Run the code. Because the Green Task will give up its timeslice to the BX, it will be more active then the red task. The red one will change the state and then have to wait for the Engine to cycle the swap. The green led will change the state and swap. Hook up your monitoring equipment to the 25&26 pins and watch em. Because the red led has to wait for the entire bx-controlled timeslice it wont flash as often. Because the green led will change state and then give up the remaining time to the Engine, it should have a higher flash rate then the red one. With out the delay, both would be using the Engine controled swap and should be just the same if you measure the transistions. (At least you have me looking at the Moon. OW-OW OW-OOOOoooo) .db.

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

I knew it. I knew that you just didnt wanna key source. Give me a few days... I have to work. .db.

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