Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Dear BasicX fiends, I'm working with a project involving a multitasking with three main task: - Read 3 analog inputs. - Write a Com 3 output to a serial LCD Display. - Send a serial stream of 160 bits, using 20 consecutive ShiftOut procedures. I have a lot of troubles because ShitOut task is critically time dependent and there is a real source of conflict between ShiftOut And Com3 output ( I think that is because their share Timer1 as a common resource) In short: When I invoke a ShiftOut task, Basic X reinitialize timer's parameters and some characters from Com3 become truncated . Some tricks using semaphores, flags and task locks don't appear fix my problem. Locking Com3 task with some added delay, give me a clean output, but put a very noticeable jitter in my ShiftOut task. Theoretically, when StatusQueue = False means there is not more info to send out. Some times, in practice, StatusQueue return a empty queues status, but still there's some characters travelling from com3 output pin. It is possible to know when Com3 PHYSICALLY flush ALL data from it programmed output Pin? There exist some bit or register I can Peek to know, when a output string procedure to Com3 finish completely ? Using COM1 instead COM3 fix my problem. Unfortunately, for me I, need COM1 for high speed communication with a host. All answer, suggestions or tricks from same o similar situation experiences, are welcome. Than you, Albert Tugar

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

I think I have similar problems. I have a BX24 in a system that is receiving data at 1200bds over a radio link from two other remote stations. The coms receive routine ( see below) is the same in all three stations. I found that I need to have a 10-20ms sleep in the routine in order for the rouitine to work reliably, but am puzzled as to why. I am not using tasking . my receive data is 15 bytes long looks like this: 55, 55, 55, slaveID,aa,dd,dd,dd,dd,dd,dd,dd,dd,CRC2,CRC2 where 55 = 3 leadin bytes slave ID = destination address aa = source address dd = data CRC2 = msbyte CRC CRC1 = lsbyte CRC The receive routine checks that the first 3 bytes are 55, and tosses them out if not so. Similarly if the 4th byte is not the correct address. The next 13 bytes are accepted, a CRC calculated on 13 bytes and the calculated CRC compared with the CRC appended to the received message in positiions 14 & 15. What I want know is why is it necessary to add the sleep(10). This can vary from about 5 to 20. Outside of this range and the receive routine starts missing characters. The routine works well, and if the radio mute is opened, because most random noise doesn't have 3x 55's in sequence, n rarely gets past 2 and rarely 3. The whole code looks like this: '*************************************************** various dim's .. .. main() sleep(100) 'com3 defined here icom3 is 30 bytes long. 'rxdata is 30 long byte array n =0 'zero array pointer do other code do while statusqueue(icom3) n = n+1 rxdata(n) = 0 'clear receive array cellwise call getqueue(icom3,rxdata(n),1) 'fill array select case n case 1 to 3 if (rxdata(n)<>55 then 'ist 3 bytes are 55 exit do end if case 4 if rxdata(4)<> slaveID then 'check slave address exit do end if case 13 call calc_CRC 'calculate CRC on 1st 13 bytes case 15 if (rxdata(14)= cbyte(CRC\100) and _ ((rxdata(15) = cbyte(CRC - ((CRC\100)*100))) then debug.print "CRC correct" CRCstatus = true else debug.print "CRC incorrect" CRCstatus = false exit do end if case 16 to 255 exit do 'too long call save_data 'received data is saved here sleep(10) 'necessary delay. WHY!!!!!?? loop n=0 'clear array pointer other code loop '********************************* subroutines start here. '********************************* albertugar wrote: > Dear BasicX fiends, > > I'm working with a project involving a multitasking with three main > task: > - Read 3 analog inputs. > - Write a Com 3 output to a serial LCD Display. > - Send a serial stream of 160 bits, using 20 consecutive > ShiftOut procedures. > > I have a lot of troubles because ShitOut task is critically time > dependent and there is a real source of conflict between ShiftOut And > Com3 output ( I think that is because their share Timer1 as a common > resource) > > In short: When I invoke a ShiftOut task, Basic X reinitialize > timer's parameters and some characters from Com3 become truncated . > Some tricks using semaphores, flags and task locks don't appear fix > my problem. > > Locking Com3 task with some added delay, give me a clean output, but > put a very noticeable jitter in my ShiftOut task. > > Theoretically, when StatusQueue = False means there is not more > info to send out. > Some times, in practice, StatusQueue return a empty queues status, > but still there's some characters travelling from com3 output pin. > > It is possible to know when Com3 PHYSICALLY flush ALL data from it > programmed output Pin? > There exist some bit or register I can Peek to know, when a output > string procedure to Com3 finish completely ? > > Using COM1 instead COM3 fix my problem. Unfortunately, for me I, need > COM1 for high speed communication with a host. > > All answer, suggestions or tricks from same o similar situation > experiences, are welcome. > > Than you, > > Albert Tugar > > Yahoo! Groups Sponsor ADVERTISEMENT [Image] > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [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: "albertugar" <> > [...] > Theoretically, when StatusQueue = False means there is > not more info to send out. Some times, in practice, > StatusQueue return a empty queues status, but still > there's some characters travelling from com3 output pin. > > It is possible to know when Com3 PHYSICALLY flush ALL > data from it programmed output Pin? [...] Yes -- this is a re-post of code that does that for all 3 serial ports. -- Frank Manning -- NetMedia, Inc. '-------------------------------------------------------------- Public Sub PrimePort( _ ByVal PortNumber As Byte) ' This procedure should be called at least once before ' writing anything to Com1. ' ' Warning -- this procedure should not be called unless ' data is actually written to Com1. Otherwise the program ' may hang if you subsequently use bit TXC to judge ' whether a transmission is complete. ' UART Transmit Complete. Const TXC As Byte = bx0100_0000 If (PortNumber = 1) Then ' Clear TXC by writing 1 to it. Register.USR = Register.USR Or TXC End If End Sub '-------------------------------------------------------------- Public Sub FlushOutputBuffer( _ ByVal PortNumber As Byte, _ ByRef OutputQueue() As Byte) ' Returns as soon as all characters in the serial port ' output queue have been transmitted. ' For Com1 -- UART Transmit Complete. Const TXC As Byte = bx0100_0000 ' For Com2. Const OCIE1A As Byte = bx0100_0000 ' For Com3. Const Com3Status As Integer = 21 Const TXC3 As Byte = bx0100_0000 ' Wait until queue is empty. Do While StatusQueue(OutputQueue) Loop ' Wait for transmission to complete. Select Case PortNumber Case 1 Do Until ( (Register.USR And TXC) = TXC ) Loop Case 2 Do While ( (Register.TIMSK And OCIE1A) = OCIE1A ) Loop Case 3 Do While ( (RAMpeek(CuInt(Com3Status)) And TXC3) _ = TXC3 ) Loop End Select End Sub '--------------------------------------------------------------

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

Frank The good book warning says that statusqueue is not suitable for determining if a queue is empty, when using it for transmission purposes, as it way false an empty queue when that is not in fcat the case. Is it possible that the reverse also applies... that my use of statusqueue is telling me there is no received data, when in fact there is. This might explain an inconsistency i have with a receive routine. neil Frank Manning wrote: > From: "albertugar" <> > > > [...] > > Theoretically, when StatusQueue = False means there is > > not more info to send out. Some times, in practice, > > StatusQueue return a empty queues status, but still > > there's some characters travelling from com3 output pin. > > > > It is possible to know when Com3 PHYSICALLY flush ALL > > data from it programmed output Pin? [...] > > Yes -- this is a re-post of code that does that for all 3 serial > ports. > > -- Frank Manning > -- NetMedia, Inc. > > '-------------------------------------------------------------- > Public Sub PrimePort( _ > ByVal PortNumber As Byte) > > ' This procedure should be called at least once before > ' writing anything to Com1. > ' > ' Warning -- this procedure should not be called unless > ' data is actually written to Com1. Otherwise the program > ' may hang if you subsequently use bit TXC to judge > ' whether a transmission is complete. > > ' UART Transmit Complete. > Const TXC As Byte = bx0100_0000 > > If (PortNumber = 1) Then > > ' Clear TXC by writing 1 to it. > Register.USR = Register.USR Or TXC > End If > > End Sub > '-------------------------------------------------------------- > Public Sub FlushOutputBuffer( _ > ByVal PortNumber As Byte, _ > ByRef OutputQueue() As Byte) > > ' Returns as soon as all characters in the serial port > ' output queue have been transmitted. > > ' For Com1 -- UART Transmit Complete. > Const TXC As Byte = bx0100_0000 > > ' For Com2. > Const OCIE1A As Byte = bx0100_0000 > > ' For Com3. > Const Com3Status As Integer = 21 > Const TXC3 As Byte = bx0100_0000 > > ' Wait until queue is empty. > Do While StatusQueue(OutputQueue) > Loop > > ' Wait for transmission to complete. > Select Case PortNumber > Case 1 > Do Until ( (Register.USR And TXC) = TXC ) > Loop > Case 2 > Do While ( (Register.TIMSK And OCIE1A) = OCIE1A ) > Loop > Case 3 > Do While ( (RAMpeek(CuInt(Com3Status)) And TXC3) _ > = TXC3 ) > Loop > End Select > > End Sub > '-------------------------------------------------------------- > > Yahoo! Groups Sponsor ADVERTISEMENT [Image] > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [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: "Neil Jepsen" <> > The good book warning says that statusqueue is not > suitable for determining if a queue is empty, when > using it for transmission purposes, as it way false > an empty queue when that is not in fcat the case. > Is it possible that the reverse also applies... > that my use of statusqueue is telling me there is > no received data, when in fact there is. [...] Yes, but this is true for serial input in general. You can pretty much expect some nonzero latency between the time a byte is received and the time a program is able to respond and actually do something with the data. This is true of any machine, although some machines respond faster than others. -- Frank Manning -- NetMedia, Inc.

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

Thats not the problem. What I'm wondering is if statusqueue is telling me the receive buffer is empty, when in fact its not. In that case, my receive routine would stop looking. The problem i sometimes get is that the receive rouitine stops in the middle of a string of data. neil Frank Manning wrote: > From: "Neil Jepsen" <> > > > The good book warning says that statusqueue is not > > suitable for determining if a queue is empty, when > > using it for transmission purposes, as it way false > > an empty queue when that is not in fcat the case. > > Is it possible that the reverse also applies... > > that my use of statusqueue is telling me there is > > no received data, when in fact there is. [...] > > Yes, but this is true for serial input in general. You can pretty much > > expect some nonzero latency between the time a byte is received and > the time > a program is able to respond and actually do something with the data. > This > is true of any machine, although some machines respond faster than > others. > > -- Frank Manning > -- NetMedia, Inc. > > Yahoo! Groups Sponsor ADVERTISEMENT > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [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, I recall seeing registers that indicate UART direction movement and also the data byte. They were read only registers. Maybe code a routine to peek at the status of those registers in addition to StatusQueue( ). If data is in the lower levels of the hardware at the moment, the registers would reflect it. .db. -----Original Message----- From: Neil Jepsen [mailto:] Sent: Tuesday, January 15, 2002 9:07 PM To: Subject: Re: [BasicX] ShifOut Com3 Conflict Thats not the problem. What I'm wondering is if statusqueue is telling me the receive buffer is empty, when in fact its not. In that case, my receive routine would stop looking. The problem i sometimes get is that the receive rouitine stops in the middle of a string of data. neil Frank Manning wrote: > From: "Neil Jepsen" <> > > > The good book warning says that statusqueue is not > > suitable for determining if a queue is empty, when > > using it for transmission purposes, as it way false > > an empty queue when that is not in fcat the case. > > Is it possible that the reverse also applies... > > that my use of statusqueue is telling me there is > > no received data, when in fact there is. [...] > > Yes, but this is true for serial input in general. You can pretty much > > expect some nonzero latency between the time a byte is received and > the time > a program is able to respond and actually do something with the data. > This > is true of any machine, although some machines respond faster than > others. > > -- Frank Manning > -- NetMedia, Inc. > > Yahoo! Groups Sponsor ADVERTISEMENT > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [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: "Neil Jepsen" <> > Frank Manning wrote: > >> From: "Neil Jepsen" <> >> >>> The good book warning says that statusqueue is not >>> suitable for determining if a queue is empty, when >>> using it for transmission purposes, as it way false >>> an empty queue when that is not in fcat the case. >>> Is it possible that the reverse also applies... >>> that my use of statusqueue is telling me there is >>> no received data, when in fact there is. [...] >> >> Yes, but this is true for serial input in general. You >> can pretty much expect some nonzero latency between >> the time a byte is received and the time a program is >> able to respond and actually do something with the data. >> This is true of any machine, although some machines >> respond faster than others. >> > Thats not the problem. What I'm wondering is if > statusqueue is telling me the receive buffer is > empty, when in fact its not. In that case, my > receive routine would stop looking. The safe thing is to assume that StatusQueue tells you nothing whatsoever about lower level stuff like receive buffers. > The problem i sometimes get is that the receive > rouitine stops in the middle of a string of data. Well, I could see where that could easily happen if you happen to call StatusQueue after the previous byte was processed, but before the next one is completely received, and then immediately give up without allowing for a reasonable timeout. It's difficult to speculate without knowing more details. -- Frank Manning -- NetMedia, Inc.

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