equivalent of BytesAvailable in serialport?

Hi, I am trying to migrate from `serial` to serialport interface, and having a hard time accessing BytesAvailable in `serialport`. While using serial, I could access the input buffer and get all bytes using `serial.BytesAvailable` which by default is 512. So with `fread` I get a matrix of 512 *1. However, when using `serialport` interface, NumBytesAvailable does not give me the same info.

Could anyone help me please? Thanks!

Answer 1

[Poorna]

Hi Arthur,

It is to be noted that "BytesAvailable" and "NumBytesAvailable" behave the same way. They return the number of bytes available to read in the input buffer. When you say "I could access the input buffer and get all bytes using 'serial.BytesAvailable' which by default is 512", It is not true that the default value of the "BytesAvailable" is 512, the default value of the "BytesAvailable" property is 0. It is set to zero as soon you open the serial port by using the "fopen"' function.

It is difficult to understand what went wrong while you were using the "NumBytesAvailable" property of the "serialport" object without the actual code. Also, the "read" function is the equivalent of the "fread" function when you switch from "serial" to "serialport". Please refer to the following documentation about transitioning from "serial" to "serialport":

https://www.mathworks.com/help/instrument/transition-your-code-to-serialport-interface.html

To know more about "serial" and "serialport", refer to the below documentation:

https://www.mathworks.com/help/instrument/serial.html

https://www.mathworks.com/help/instrument/serialport.html

Hope this helps!

[Arthur Zhang]

Hi Poorna,

Thanks for your response.

Sorry for not making this clear enough, so when I say "when using `serialport` interface, NumBytesAvailable does not give me the same info" I meant NumBytesAvailable exceeds the input buffer size which by default is 512, i.e., i think it reads data directly from port, not just input buffer?

Port: "COM3"

BaudRate: 115200

NumBytesAvailable: 8053

ByteOrder: "little-endian"

DataBits: 8

StopBits: 1

Parity: "none"

FlowControl: "none"

Timeout: 1.0000e-03

Terminator: "LF"

BytesAvailableFcnMode: "off"

BytesAvailableFcnCount: 64

BytesAvailableFcn: []

NumBytesWritten: 1046

ErrorOccurredFcn: []

UserData: []

and when i use serial object, I get to read bytes ONLY from the input buffer, which max. is 512:

Serial Port Object : Serial-COM3

Communication Settings

Port: COM3

BaudRate: 115200

Terminator: 'LF'

Communication State

Status: open

RecordStatus: off

Read/Write State

TransferStatus: idle

BytesAvailable: 512

ValuesReceived: 512

ValuesSent: 324

I have read the documentation multiple times, but failed to find the explanation for this.

So I wonder if there is something i need to do in order to get access to input buffer using serialport object?

Thanks!

[Walter Roberson]

serialport() objects manage the buffer internally, adjusting the size as needed.

If you only need 512 bytes out of the 8053 currently available, then

read(OBJECT, min(512,OBJECT.NumBytesAvailable))

[Arthur Zhang]

Thanks Walter, I'll give it a try.

[Sam]

Hi @Walter Roberson, does this mean that the buffer stores all data you write to the serial object until you read it, regardless of how much data this is? Is there a maximum number of bytes the buffer will store? Thanks!

[Walter Roberson]

@Sam

Sorry, I do not know that.

I see that in https://www.mathworks.com/matlabcentral/answers/1953714-streaming-data-using-serialport#comment_2758899 I posted

The newer serialport() has no documented buffer size control. In practice, though, it has hidden user-settable properties InputBufferSize and OutputBufferSize . With the properties not being documented, I cannot promise that it will actually use the buffer size that is set.

Historically, Mathworks has occasionally created object properties that they intend to implement in future, but hard-coding behaviour for a while, or keeping the properties hidden until they are finished testing or finished getting bugs out to their satisfaction. So the fact that the properties exist does not mean that they are used or that they function properly at this point.