Reading binary data from serial port

[Russ Fisher]

Using VB I can read all the printable characters, but
apparently the MSComm tool is useless for binary data. I have
an application that needs to read 10 to 20 bytes of data and
display them as hex codes. Was hoping PB/DLL could do this but
so far no luck. The help file has this two line example:

Qty& = COMM(#hComm, RXQUE)
COMM RECV #hComm, Qty&, a$

In my programs Qty always gets only zero bytes. But I don't
understand RXQUE... what is it? I tried to declare it as an
integer etc. but no help. Also tried getting a byte or an
integer in lieu of the a$ string variable. The incoming data
for this app is at 19200 but repeated at a 10Hz rate so I could
poll a function continuously, getting one byte each time.

Any help is appreciated.

Russ


------------------
Russ

[Lance Edmonds]

RXQUE is a keyword, not a variable name, and you are using it correctly to query the receive data buffer size, then use COMM RECV to get the actual bytes in the queue.

The question in my mind is how have you set up the serial communication parameters? Possibly you are witnessing data loss because of a hand-shaking or missing comm parameter issue, but without seeing more of your code it is not possible to give you a precise answer.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Russ Fisher]

Oh, yes, of course I should have shown some code.

#COMPILE DLL
#INCLUDE "WIN32API.INC"
GLOBAL hComm AS LONG

SUB PORTSETTINGS EXPORT
hcomm = FREEFILE
COMM OPEN "COM1" AS #hComm
COMM SET #hComm, BAUD = 19200
COMM SET #hComm, BYTE = 8
COMM SET #hComm, PARITY = %False
COMM SET #hComm, STOP = 0 'One stop bit
COMM SET #hComm, TXBUFFER = 2048
COMM SET #hComm, RXBUFFER = 4096
COMM SET #hComm, XINPFLOW = 1
COMM SET #hComm, XOUTFLOW = 1
COMM CLOSE #hComm
END SUB

FUNCTION RCVCHAR () EXPORT AS BYTE
DIM x AS BYTE
DIM y AS STRING
hComm = FREEFILE
COMM OPEN "COM1" AS #hComm
'Original code had a while loop around the next statement
Qty& = COMM(#hComm,RXQUE)

COMM RECV #hComm,Qty&,x
FUNCTION = x
COMM CLOSE #hComm
END FUNCTION

I've tried to export it as a byte or integer etc. Found out
Qty& is always zero by exporting it to VB. Should have known
it was zero cause the computer locked up and had to exit VB by
using the three finger salute (cntrl-alt-delete).

Russ

------------------
Russ

[Lance Edmonds]

Is that the exact code you are using?

Four points to consider:

• As it stands, you have two exported Sub/Functions. The PortSettings SUB opens the port, sets the parameters, then closes it... settings are lost when the port is closed.
  
• The main function never configures up any comm settings for it's own session. Probably you'll want to take the parameter section from the SUB and paste it into the 'main' function.
  
• You will probably also want to set up a loop to read the data stream, since the COMM OPEN statement will likely flush the receive buffer.
  
• COMM RECV expects a string variable, not a byte variable.

COMM RECV #hComm, qty&, A$
FUNCTION = ASC(a$) ' return the 1st byte to the calling code

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Russ Srole]

Russ,

I use these PB functions all day long & they work just fine. One
of the things you must do is not only test for bytes in the
receive buffer, but if there arn't any, don't read the port. It
helps if you know how many you are expecting, but that's not always
the case. Lets say you do:

DO
     QTY& = COMM(#hComm, RXQUE)
     IF QTY& = 0 THEN ITERATE
     COMM RECV #hComm, Qty, a$
     rcv$ = rcv$ + a$
     SLEEP 10  (or something that works for you)
LOOP UNTIL LEN(rcv$) >= ExpectedLen

If you don't know the expected length then things can get messy.
If you are sending a command and waiting for a response then a
time out using GetTickCount works well. If you are simply polling
the port for bytes to come in then you should set up thread and pass
the results to a global buffer string or string array to pass it
back to the rest of your program. Without knowing more about what
you're doing, it's a bit hard to tell what the best approach is.

Best of luck,
Russ Srole

------------------

[John Hutchins]

I use the Comm port funtions with no handshaking for many
applications, and as yet have had no problems with anything.
The recieved data is best handled with its own thread.
If you are using binary, do'nt forget to set:

COMM SET #hComm, NULL = %FALSE



------------------

[Guest]

Russ, FYI, the mscomm control has an inputmode property.

[Russ Fisher]

Thank you Lance and Russ for your replies. I was able to get
a small program working good enough for a demo tomorrow! Gee
the customer will see a Windows program in lieu of a clunky DOS
program.

Also thanks to John and Ron for their help.


------------------
Russ