Anyone seen strange behavior when porting serial-related code from 4.25 to
RTP?
I have a thread which reads raw data from the serial and parses it according
to a bit pattern. The code works fine under 4.25 but under RTP the port
seems to return garbage. As I just switched from 4.25, I am somewhat
confident that both the peripheral and connection are good and that the
correct data is coming in through the port.
While your program is running in qnx4, run “stty -a < COM_USE”. Repeat
the same command, while using RTP. The default modes of the serial
ports may be different. If in doubt, post the output here.
Anyone seen strange behavior when porting serial-related code from 4.25 to
RTP?
I have a thread which reads raw data from the serial and parses it according
to a bit pattern. The code works fine under 4.25 but under RTP the port
seems to return garbage. As I just switched from 4.25, I am somewhat
confident that both the peripheral and connection are good and that the
correct data is coming in through the port.
Thanks for the tip-- I wasn’t aware of stty until now. I didn’t actually
compare with 4.25 (I could still do that), but I did use stty to confirm I
was setting up the port correctly. I also did null connection tests to
ensure I am actually getting proper communication on the port.
The interesting thing is that the code runs just fine on RTP when I don’t
use any printf statements and just log the port to memory instead. I
suspect what is happening is that some of the time devc-ser8250 is just not
responding to the port, and I am losing data as a result. “ps -A -o
args,pri” shows priority 10 for all processes, including devc-ser8250-- this
is definitely different from 4.25 where the drivers had much higher
priority.
Is it possible that priority is the problem? If so, can I fix it by
starting the serial port driver with higher priority or calling it with
different args or something?
While your program is running in qnx4, run “stty -a < COM_USE”. Repeat
the same command, while using RTP. The default modes of the serial
ports may be different. If in doubt, post the output here.
Is it possible that priority is the problem? If so, can I fix it by
starting the serial port driver with higher priority or calling it with
different args or something?
I guess you have to run your program with higher priority. There is a clip of my discussion with
Xiaodan Tang below.
Eduard.
You want to take a look of system architecture. Topics like:
“priority inheritance”, “priority inversion”.
The quick answer is devc-ser8250 keeps on adjuest its priority according
the request it received.
Excuse my ignorance. You are right. devi-hirun does not restart of devc-ser8250. Ok.devi-hirun do
“renice” of devc-ser8250 somehow. (How is not interesting for me at this time. I hope I’ll have a
time to read docs). But I don’t understand why does devi-hirun do it? devc-ser8250 manages two
The document I point out explained “why”. “Priority inversion” is a
classic problem in Realtime processing.
In a short word, all the managers in QNX will “adujest” their priority
while service a client, the new “priority” is the same as the client’s
priority, otherwise, you could have a “low priority” client starve a
“high priroity” client, which brokes “high priority go first” golden
rule in Realtime System.
I am sorry that I don’t have detail information about your perticular
problem (unwanted mouse event…)
I guess you have to run your program with higher priority. There is a clip
of my discussion with
Xiaodan Tang below.
Eduard.
Thanks. I actually found the problem and it was slightly different than I
expected:
I was making calls to read() which I expected to either block or return with
data. Hence I did not even check the return value of read(). The rest of
the code I was working with gets an interrupt-based wakeup every ms, and I
think this is why read() was sometimes returning without data. To solve the
problem I simply checked the return value of read() to make sure I had a
character.
Dave
You want to take a look of system architecture. Topics like:
“priority inheritance”, “priority inversion”.
The quick answer is devc-ser8250 keeps on adjuest its priority
according
the request it received.
Excuse my ignorance. You are right. devi-hirun does not restart of
devc-ser8250. Ok.devi-hirun do
“renice” of devc-ser8250 somehow. (How is not interesting for me at this
time. I hope I’ll have a
time to read docs). But I don’t understand why does devi-hirun do it?
devc-ser8250 manages two
The document I point out explained “why”. “Priority inversion” is a
classic problem in Realtime processing.
In a short word, all the managers in QNX will “adujest” their priority
while service a client, the new “priority” is the same as the client’s
priority, otherwise, you could have a “low priority” client starve a
“high priroity” client, which brokes “high priority go first” golden
rule in Realtime System.
I am sorry that I don’t have detail information about your perticular
problem (unwanted mouse event…)