U
U
UporotayaPanda2017-04-19 16:13:58
.NET
UporotayaPanda, 2017-04-19 16:13:58

How to read data constantly coming through the com port?

Good day to all!
A small introduction:
There is a system that constantly sends messages about the state of the system itself and the elements that are included in it.
Let's conditionally call these messages "parcels". The parcel size is not fixed. All parcels consist of frames, each parcel can contain any number of frames, but the presence of a start and a final frame is mandatory. All types of frames have a strictly fixed length and a unique first byte.
Starting frame - 11.
Final frame - С9.
Now for some hardware:
Baud rate - 19200, start bits -1, stop bits - 2, parity - no. Between "parcels" there is a pause of 1.5 bytes. If during this interval the desired device did not send a message, the line is occupied by the next one after it.
Now the question itself:
How to accept the entire "sending" from pause to pause???
Tried several ways:
1. Just read the data through Read and write it to an array, and then already determine the known flags and divide into parcels and frames. But I don’t really like this method, because there is no information about the moment of pause in the transfer, and without it in the future it will not be possible to send data to the system.
2. Used port.DataReceived += new SerialDataReceivedEventHandler(DataReceviedHandler). All other attempts were made in this way. Only the logic of the DataReceviedHandler has changed.
I tested it on the console, outputting data from the buffer to a new line, but the messages are broken, for example, the end of the first one can be contained in the next line, and so on.
Port settings:

port.BaudRate = 19200;
port.DataBits = 8;
port.Parity = System.IO.Ports.Parity.None;            
port.StopBits = System.IO.Ports.StopBits.Two;

Tried changing other settings but no change. I couldn’t figure out how to process the start bit, since it didn’t exist in similar systems before, or everything worked without it, but I didn’t find such information on MDSN. I would also like to try changing ReadTimeout, but I could not figure out what value to set.
Here is an example of work. In the middle of the line we see flag 11 - this indicates the beginning of the starting frame, and, in fact, the beginning of the sending. There are no errors in the data, I check through the CRC calculation. After 8 bytes, the C9 flag goes - this is the final frame. But why does it end in the next premise??
2a122c18930e4ee09553045b8dc16038.PNG
I would appreciate and appreciate your help!

Answer the question

In order to leave comments, you need to log in

1 answer(s)
D
d-stream, 2017-04-19
@d-stream

Hm... if it weren't for the pause "1.5 bytes" - everything would be easy and good, but this is a somewhat unnatural use ... with all the consequences ...
If sclerosis does not deceive me - 8251 has a buffer within 15 bytes. That is, if the packet / frame is larger - it should be fragmented.
p / s / by delirium: fall a level or two lower to emulate 8251, turn off the buffer and catch data byte by byte and track pauses by timer ... only, I'm afraid, the first insurmountable rake will be partial interface emulation ...

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question