MSComm
in [Visual Studio]
|
From: Henning on 26 May 2010 19:37 "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:apCdnd0bZ845PWDWnZ2dnUVZ_hydnZ2d(a)giganews.com... > Henning wrote: >> >> The Sleep version did not work for some reason. Sleep 2 was too >> small and Sleep 3 too large... >> I did call dummy = timeBeginPeriod(1) and dummy = >> timeEndPeriod(1). >> >> >> I had to change the loop value depending on the number of bytes to >> send. There can be 5,6,14 or 16 bytes in a packet. >> >> If Len(s) < 10 Then >> limit = 770000 >> Else >> limit = 1400000 >> End If >> >> ....... >> >> For i = 1 To limit '476800 >> ' DoEvents >> Next >> >> After this change everything is playing as it should. I can't >> figure out why the loopvalue has to be different for small or large >> packets, if the MSComm control is working as expected?? > > I'll bet the xmit FIFO is active, which would mean THRE would raise > (cause the OnComm) as soon as the last byte entered the queue. With a > full 14-byte FIFO, the transmit shift register (TSR) would take 140 > bit-times to empty. If your messages were less than 14 bytes, THRE > would come back instantly, but the TSR would take a variable amount of > time to empty. > > Apart from monitoring the TSR status directly, which we used to do in > the DOS days, there's no way to tell. You can probably still get it if > you use the .CommID property to request a DCB from the UART. > > You could use the comm port control panel / advanced to turn off the > xmit FIFO if you wanted to test the theory. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > Interesting thoughts, I'll see if IoDll can help in testing TSR and other bits. Maybe even let me setup my own Send routine in concurrency with MSComm for Receiving. Setting the FIFO to Low (1) didn't change the need for different loop values. Disabling the FIFO didn't change anything. /Henning
From: Henning on 26 May 2010 20:12 "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:apCdnd0bZ845PWDWnZ2dnUVZ_hydnZ2d(a)giganews.com... > Henning wrote: >> >> The Sleep version did not work for some reason. Sleep 2 was too >> small and Sleep 3 too large... >> I did call dummy = timeBeginPeriod(1) and dummy = >> timeEndPeriod(1). >> >> >> I had to change the loop value depending on the number of bytes to >> send. There can be 5,6,14 or 16 bytes in a packet. >> >> If Len(s) < 10 Then >> limit = 770000 >> Else >> limit = 1400000 >> End If >> >> ....... >> >> For i = 1 To limit '476800 >> ' DoEvents >> Next >> >> After this change everything is playing as it should. I can't >> figure out why the loopvalue has to be different for small or large >> packets, if the MSComm control is working as expected?? > > I'll bet the xmit FIFO is active, which would mean THRE would raise > (cause the OnComm) as soon as the last byte entered the queue. With a > full 14-byte FIFO, the transmit shift register (TSR) would take 140 > bit-times to empty. If your messages were less than 14 bytes, THRE > would come back instantly, but the TSR would take a variable amount of > time to empty. > > Apart from monitoring the TSR status directly, which we used to do in > the DOS days, there's no way to tell. You can probably still get it if > you use the .CommID property to request a DCB from the UART. > > You could use the comm port control panel / advanced to turn off the > xmit FIFO if you wanted to test the theory. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > Sadly, the TSR flag is not available in th 16550 compatible UART, only THR. /Henning
From: Jim Mack on 26 May 2010 21:08 Henning wrote: >> > > Sadly, the TSR flag is not available in th 16550 compatible UART, > only THR. Sure it is. Bit 6 of the line status register will be 1 if both THRE and TSRE are true (both the transmit holding and transmit shift registers are empty). Unfortunately for my first theory, when FIFO is enabled the 16550 logic is designed to signal THRE only when the transmit queue is completely empty. Since THRE is what raises OnComm, unless there's a fault the OnComm event should be a reliable signal that all data has been sent. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Henning on 27 May 2010 09:37 "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:ltOdnYFBGe1kWGDWnZ2dnUVZ_o-dnZ2d(a)giganews.com... > Henning wrote: >>> >> >> Sadly, the TSR flag is not available in th 16550 compatible UART, >> only THR. > > Sure it is. Bit 6 of the line status register will be 1 if both THRE > and TSRE are true (both the transmit holding and transmit shift > registers are empty). > > Unfortunately for my first theory, when FIFO is enabled the 16550 > logic is designed to signal THRE only when the transmit queue is > completely empty. Since THRE is what raises OnComm, unless there's a > fault the OnComm event should be a reliable signal that all data has > been sent. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > Your'e right, I was reading a little too fast. It was named TEMT (TSRE & THRE empty). Using IoDll to read the bit is working ok, now I can keep the loop value the same for long and short packets. This the working codesnippet. In MSComm1_OnCom(): With MSComm1 msg = .CommEvent If msg > 0 Then Select Case msg Case Is > 1000 If cmdLog2File.BackColor = vbGreen Then Print #fil, "CommError " & msg End If Case Is = comEvSend While Not GetPortBit(UART_LSR, TEMT) Wend TxOn = False End Select End If And in a module, Send(s As String): With frm_Main.MSComm1 If .PortOpen Then .InBufferCount = 0 RxSize = 0 .DTREnable = False '* Change RS485 to Tx DoEvents TxOn = True .Output = s While TxOn DoEvents Wend For i = 1 To limit '=300000 Next .DTREnable = True '* Change RS485 back to Rx DoEvents End If End With /Henning
First
|
Prev
|
Pages: 1 2 3 Prev: Identifying Modified Database Fields Next: Sort order multilanguage |