Are you sure the thread gets trigger every 13 ms (what if there is a harware problem and the serial port doesn
t see the sync pulse). Can you explain what this sync pulses consists of. If youve let the RS-422 port be handled by the serial driver, unless you have prevented the serial driver from also accessing the regular serial port, doing an InterruptAttachEvent on the IRQ is not a good idea. One reason is that interrupt will stay masked until the thread unmask it, this could mean lost of data because the serial driver will not get it’s interrupt. It`s even worst if you try to use a real ISR with InterruptAttach because both the driver and your software will access the serial port, not good.
How to you trigger the thread. If it
s via pulse the priority of the thread is irrelevent, its the priority of the pulse that matters.
Here is one much simpler way to do it.
ser = open( “/dev/ser1”…);
Qser = open( “/dev/ser2”,… );
read( ser, sync, 1 ); // wait for sync
read( QSwer, frame, …); // get frame
That being said it appears to me you don’t even need to way for the sync, just wait for the frame (unless the frame is build in such a way that it’s hard to figure out where is the beginning and the end)
Also note that if you do a read( DEVICE, buffer, 2048 ) and you have not open the serial port with the NON_BLOCKING flag the read call will NOT return unless there is 2048 byte in the buffer.
Furtermore asking for 2048 byte when the buffer of the serial driver is also 2048 is not a good idea, because it could mean the driver could miss some bytes, you are not leaving any room for the serial driver to breath