SerialPort.Read()

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello

I have a question regarding the serialport.read() method.
SerialPort.Read Method (Byte[], Int32, Int32)
(http://msdn2.microsoft.com/en-us/library/ms143549.aspx).

Given that this method is called twice consequtively reading 4 bytes
each time:

_serialport.Read(buffer, 0, 4);
_serialport.Read(buffer, 0, 4);

Is it theoretically possible in this case that the 4 bytes read and
placed in the byte array 'buffer' the second time is the same as the
ones read the first time, or will the 4 bytes read the second time
for sure be 4 new bytes?

Given that the byte stream sent into the serial port is the following 8 bytes:
[A B C D A B C D]
and assume that the first Read() sets buffer= [A B C D].
Is it then possible for the second Read() to cause buffer=[B C D A] ?
(That is, for the Read() operation to cause only one new byte to be read; a
shift
by only one byte with respect to the input stream).

In case this is actually possible, how can one make certain that 4 new bytes
are read the second time?


Appreciate all the help I can get.
 
As I understand it the 1st Read will populate your buffer starting at
postion 0. The same would be true of your 2nd read. So the end result
would be buffer = [A B C D].
 
Note that this assumes that 4 bytes will actually *be received* in the
second (or first, for that matter), call. It's quite possible that only 3
bytes or 2 might be received in any given call. It's going to depend on the
configuration of the port, the time-outs, etc.

Paul T.
 
Anywhere from 0 to 4 NEW bytes will be read by the second statement. This
depends on how many bytes have been buffered by the SerialPort object.
Actually, you can make this same assertion about the 1ST statement. It also
will return 0 to 4 bytes, depending...

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
GT,
The 2nd read isn't reading the same bytes again. The 2nd read is
reading the 2nd group of [A B C D] bytes in the input buffer.

If your sender sent [A B C D A B C D] (and as others have pointed out
all those bytes are in the input buffer when you go to read) then the
1st read would read bytes 0, 1, 2, and 3 and those bytes would be
removed from the in buffer and the data those bytes hold (A B C D)
would be put in your "buffer" variable starting at position 0 .... now
the input buffer only holds [A B C D] and your second read would then
read bytes 0, 1, 2, and 3 and those bytes would be removed from the in
buffer and the data those bytes hold (A B C D) would be put in your
"buffer" variable starting at position 0.
 
Data are discarded when read. DiscardInBuffer gets rid of data that have
not yet been read.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
BTW, you might want to implement a file transfer protocol. I have a desktop
dll (XMCommCRCNET.dll) on my homepage that implements XMODEM file transfers.
The source code for it is on the CD ROM that accomanies my book. That CD
also has equivalent Compact Framework code -- the details are very slightly
different on the full framework, and the compact framework.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
Back
Top