I'm using the mscomm32.ocx that is shipped with VB6 (SP3), to
send/receive binary data to an embedded uP.
On my system, the time it takes to receive one byte and immediately
transmit another byte is about 35 milliseconds (measuring on an
oscilloscope). Unfortunately this is not quick enough for me. Can
anyone suggest a way to decrease this time. Will a different control
eg. PDQComm, Greenleaf, etc. be better, or maybe the Windows API?....
Is this a Windows thing, is it the control, or a limitation of the
UART itself?
Nick
Code snippet is below:
Private Sub cmdOpenCom_Click()
With MSComm1
If .PortOpen Then .PortOpen = False
.CommPort = 1
.Settings = "1200,N,8,1"
.InputMode = comInputModeBinary
.NullDiscard = False
.InputLen = 1
.RThreshold = 1
.PortOpen = True
End With
End Sub
Private Sub MSComm1_OnComm()
Dim bytArr() As Byte
Dim vrnTemp As Variant
Select Case MSComm1.CommEvent
Case comEvReceive
vrnTemp = MSComm1.Input
bytArr = vrnTemp
MSComm1.Output = Chr(255 - bytArr(0))
End Select
End Sub
This 'delay' of 35ms appears to be dependant on the baud rate. At 9600bps it
reduces to just 5ms, so it must not be a windows/interrupt problem or a UART
speed problem, it must be related to the mscomm control and the clock/timer
used to sync the baud rate.
40ms / 5ms = 8
9600bps / 1200bps = 8
this surely isn't a coincidence...
Correct me if I'm wrong......
thanks
Nick
"Nick Ford" <nick...@injectronics.com.au> wrote in message
news:bf9c2c7c.03020...@posting.google.com...
How are you sending the data?
Dim Buffer As String
Dim I As Integer
For I = 0 to 255
Buffer = Buffer & Chr$(I)
Next I
MSComm1.Output = Buffer
At 9600 bps, all of the data (256 bytes) are sent in less than 300 mS. (a
somewhat variable statistic).
If, however, you attempt to loop through the data one byte at a time, you
WILL introduce latency, because MSComm Output blocks; MSComm does not
implement overlapped IO. None-the-less, even a control like Sax Comm
Objects, which does implement overlapped IO would still see some non-trivial
latency here.
Your software design is the most important cause of performance problems.
For lots more information, you may be interested in my book. See below. It
has a chapter on optimization and debugging.
--
Richard Grier (Microsoft Visual Basic MVP)
See www.hardandsoftware.net for contact information.
Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.
I was hoping you might spot this and reply...I have the 2nd ed of your book
and have got lots of good info from it.
I'm receiving data one byte at a time. The uP sends one byte and will not
send the next byte until it receives the complement of the byte that it just
sent. If it doesn't receive this complement within a certain amount of time
(<35ms) it resends the last byte.
I did a quick test using another PC and a null modem cable and sent one char
from the other PC using the windows terminal program. I receive the byte
(mybyt), and then immediately send (255 - mybyt) back.
I captured both the bytes on an oscilloscope (looked at pin2 and pin3 of
DB9) and measured the delay. ~40ms at 1200bps and ~5ms at 9600bps.
Unfortunately I can't change the baudrate so I am stuck with 1200.
Why does this latency decrease with higher baud rate?
thanks
Nick
Private Sub cmdOpenCom_Click()
With MSComm1
If .PortOpen Then .PortOpen = False
.CommPort = 1
.Settings = "1200,N,8,1"
.InputMode = comInputModeBinary
.NullDiscard = False
.InputLen = 1
.RThreshold = 1
.PortOpen = True
End With
End Sub
Private Sub MSComm1_OnComm()
Dim bytArr() As Byte
Select Case MSComm1.CommEvent
Case comEvReceive
bytArr = MSComm1.Input
MSComm1.Output = Chr(255 - bytArr(0))
End Select
End Sub
"Dick Grier" <dick_gri...@msn.com> wrote in message
news:eP0DVqHzCHA.2196@TK2MSFTNGP10...
>>
I'm receiving data one byte at a time. The uP sends one byte and will not
send the next byte until it receives the complement of the byte that it just
sent. If it doesn't receive this complement within a certain amount of time
(<35ms) it resends the last byte.
<<
Take a look at the optimization and debugging chapter.
What technique are you using to get (input) the data? To do what you want,
you SHOULD NOT use OnComm receive processing, but rather you should poll in
a DoEvents loop.
Make sure that you set both the Receive and Transmit FIFO settings (Control
Panel/System/Hardware/Device Manager/Port in question/Port
Settings/Advanced) to LOW (not the default, High). A 1-byte FIFO buffer
will make the interaction with the Windows serial port driver as speedy as
possible. This is not a problem at low serial port speeds, but can result
in data loss at higher settings. 1200 bps should not cause any trouble.
You should be able to observe less than 20 mS of total latency. Realize
that simply inputting and outputting a single character at 1200 bps takes
more than 17 mS in the hardware alone -- this is without any software
intervention.
I'll have a scan through the optimization section in your book and see if
that tells me anything.
Thanks
Nick
"Dick Grier" <dick_gri...@msn.com> wrote in message
news:uKFW0aUzCHA.1752@TK2MSFTNGP10...