“Pasus” <email@example.com> wrote in message news:firstname.lastname@example.org…
Thanks, Mario and Bill for answer to my questions.
I have two senders. One sender sends data periodically, the other does
I am reading the interrupt part of QNX docu, which says that I can get
using interrupt call.
My confusion is that if I use driver (for serial port), how can I get
notified to get data periodically (for sender 1) or inperiodically (for
sender2), because driver deals with interupt from serial port.
Your description of the situation is pretty vague. If you want a clear
answer please provide a detail description of the task you wish to acheive.
What is this “two senders” thing exactly?
Roughly there is no difference if your program receives data from an
interrupt handler (meaning you handle the hardware directly) or receive
it via the driver. That’s important to understand, there is no difference
Going through the drivers adds a little overhead, but is way way more
The only important difference is that if you go though the driver
it’s close to impossible to time stamp the incomming data. That means
you can’t know precisely in time when a perticular byte was received
by the hardware. If you rely on this, you will have to go to the hardware
directly and install a interrupt handler.
Let’s assume that you are using an interrupt handler. Because of the
lack of information I will hypothesise… You have one sender sending
data at 100hz. The other sender send data at irregular interval.
The interrupt routine would receive the byte and store them in
a buffer. Some people write code that parse the incomming stream
inside the interrupt handler. In general that’s to be avoided as
it increase the duration of the ISR. The design choice that are left
are to: have the interrupt handler notify the application when
X number of bytes have come in or when a certain termination
character or byte sequence is received.
Once the notification (pulse) is received by the application, it then parse
the buffer to decided what to do. Each data may have been
time stamp by the interrupt to help the application know
when the data has come in.
It is still left to the applicaton to parse the data and figure out
if it came from “sender 1” or “sender 2”. It will also be left to
the application to handle timeout detection; did sender 1
sent the data at the expected 100Hz or not? How the application
decided if the data is from “sender 1” or “sender 2” is hard
to say here. I would try to find some sort of pattern
or difference in the format of the data sent by each sender.
If you cannot tell the difference then that’s where the time stamp
could help you. The application could have an algorithm that
could figure out what sender it is by using the time stamp.
If you take the driver approach, it’s pretty much the same.
Through the ionotify function or select() your application can
be told when there is data in the receive buffer of the serial
driver. Once you receive the notification you use
read() or condread() to pull the data out of the serial driver
buffer and then in your own buffer. They may be more then 1 byte
in the buffer though, you application must deal with that.
If your application is fast enough and runs at a priority
high enough, you may actually end up getting a notification
for every byte received (which when you thing about it
is pretty much like if you would be dealing with the
serial port interrupt and the hardware yourself…). If you
run very high priority (63) it’s would actually be possible
to time stamp the data. Precision isn’t great but given
the 100hz requirement, i don’t think that would be a problem.
The difference here is that there could be a delay between
the time the serial driver gets the data from the hardware
and the time your application gets notify. That delay
could be longer then two bytes (serial port time) if
your application is busy doing something else or
isn’t running because a higher priority process/thread
is running. But that’s ok you won’t loose any bytes,
the serial driver will buffer them.
The way I see it your problem has nothing to do
with interrupt versus driver. It has to do with how
to detect sender 1 versus sender 2 and how to
There are too many strategies to talk about that
in this already long post
If you could post the format of the data stream send
by sender 1 and sender 2, people in the newsgroup
will be in a better position to offer some helpfull hint.