Hello.
What is the difference between in dealing with serial port directly and
through a driver.
For example, I want to accept data periodically through one serial port, and
irregularly with the other serial port. Then which way is good?
Does the driver deal with interrupt from serial port directly or should I
make ISR for that?
Thanks.
Pasus
Hi,
Pasus <pasus@mail.nu> wrote in article <9u11rs$2gt$1@inn.qnx.com>…
Hello.
What is the difference between in dealing with serial port directly and
through a driver.
If you are using the driver you have to start driver. The driver creats /dev/ser1 file (for
example). You could open this file and write()/read() to/from the file. It’s very easy. It’s
portable way - the driver take care about hardware differences.
For example, I want to accept data periodically through one serial port, and
irregularly with the other serial port. Then which way is good?
Regardless periodically or not you want to accept data, I think the driver is preferable way for
you. There are few reasons to work with port directly. For example, you need to have non-standard
speed/protocol. From top of my head, we have external rs232/rs485 interface converter. The signals
on RTS and CTS lines are used for supply of first cascade of converter, the RX/TX lines are
supplied from external power block (the simplest way to decouple supply powers). Result: I have to
set the state of RTS/CTS lines and it should be constantly during messages exchange. Additionly, I
don’t know the speed of the external device. I only know it uses Break Detect to set predefined
speed (2400) for a one message exchange. So, I have to set up RX line to low state (send break
signal), then I send the command “How fast are you?”(on 2400), then I get answer “I’m 115200” (on
2400). Finally I have to set speed to 115200 and continue… Do you need such tricks?
Does the driver deal with interrupt from serial port directly
Yes, the driver does. It is a next argument for you to use the driver.
Eduard.
or should I
make ISR for that?
Thanks.Pasus
The driver uses interrupts.
Unless you have a really, Really, REALLY good reason not to use it, use it.
–
Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net
“Pasus” <pasus@mail.nu> wrote in message news:9u11rs$2gt$1@inn.qnx.com…
Hello.
What is the difference between in dealing with serial port directly and
through a driver.
For example, I want to accept data periodically through one serial port,
and
irregularly with the other serial port. Then which way is good?
Does the driver deal with interrupt from serial port directly or should I
make ISR for that?
Thanks.Pasus
Hello,
Thanks for reply.
If the driver takes care of interrupt from serial port, how can I deal with
data with periodic fashion ?
Does read() have also block and unblock function for synchronization?
Pasus.
Hi,
Pasus <> pasus@mail.nu> > wrote in article <9u11rs$2gt$> 1@inn.qnx.com> >…
Hello.What is the difference between in dealing with serial port directly and
through a driver.If you are using the driver you have to start driver. The driver creats
/dev/ser1 file (for
example). You could open this file and write()/read() to/from the file.
It’s very easy. It’s
portable way - the driver take care about hardware differences.For example, I want to accept data periodically through one serial port,
and
irregularly with the other serial port. Then which way is good?Regardless periodically or not you want to accept data, I think the driver
is preferable way for
you. There are few reasons to work with port directly. For example, you
need to have non-standard
speed/protocol. From top of my head, we have external rs232/rs485
interface converter. The signals
on RTS and CTS lines are used for supply of first cascade of converter,
the RX/TX lines are
supplied from external power block (the simplest way to decouple supply
powers). Result: I have to
set the state of RTS/CTS lines and it should be constantly during messages
exchange. Additionly, I
don’t know the speed of the external device. I only know it uses Break
Detect to set predefined
speed (2400) for a one message exchange. So, I have to set up RX line to
low state (send break
signal), then I send the command “How fast are you?”(on 2400), then I get
answer “I’m 115200” (on
2400). Finally I have to set speed to 115200 and continue… Do you need
such tricks?Does the driver deal with interrupt from serial port directly
Yes, the driver does. It is a next argument for you to use the driver.
Eduard.
or should I
make ISR for that?
Thanks.Pasus
Pasus <pasus@mail.nu> wrote:
Hello,
Thanks for reply.
If the driver takes care of interrupt from serial port, how can I deal with
data with periodic fashion ?
Does read() have also block and unblock function for synchronization?Pasus.
Take a look at the help for open(). There are all sorts of interesting
flags like O_NONBLOCK. You can also use fcntl() to set flags on existing
file descriptors.
Cheers,
Kris
Hi,
Pasus <> pasus@mail.nu> > wrote in article <9u11rs$2gt$> 1@inn.qnx.com> >…
Hello.What is the difference between in dealing with serial port directly and
through a driver.If you are using the driver you have to start driver. The driver creats
/dev/ser1 file (for
example). You could open this file and write()/read() to/from the file.
It’s very easy. It’s
portable way - the driver take care about hardware differences.For example, I want to accept data periodically through one serial port,
and
irregularly with the other serial port. Then which way is good?Regardless periodically or not you want to accept data, I think the driver
is preferable way for
you. There are few reasons to work with port directly. For example, you
need to have non-standard
speed/protocol. From top of my head, we have external rs232/rs485
interface converter. The signals
on RTS and CTS lines are used for supply of first cascade of converter,
the RX/TX lines are
supplied from external power block (the simplest way to decouple supply
powers). Result: I have to
set the state of RTS/CTS lines and it should be constantly during messages
exchange. Additionly, I
don’t know the speed of the external device. I only know it uses Break
Detect to set predefined
speed (2400) for a one message exchange. So, I have to set up RX line to
low state (send break
signal), then I send the command “How fast are you?”(on 2400), then I get
answer “I’m 115200” (on
2400). Finally I have to set speed to 115200 and continue… Do you need
such tricks?Does the driver deal with interrupt from serial port directly
Yes, the driver does. It is a next argument for you to use the driver.
Eduard.
or should I
make ISR for that?
Thanks.Pasus
\
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“Computer science is no more about computers than astronomy is about telescopes”
–E.W.Dijkstra
“Pasus” <pasus@mail.nu> wrote in message news:9u35ad$gkq$1@inn.qnx.com…
Hello,
Thanks for reply.
If the driver takes care of interrupt from serial port, how can I deal
with
data with periodic fashion ?
If you want to time stamp the data, that is indeed a problem. But in your
case
it doesn’t really matter, data will come in a a fix rate. Using dev_read
and its timeout capability will allow you to sync with the data.
Does read() have also block and unblock function for synchronization?
Pasus.
Hi,Pasus <> pasus@mail.nu> > wrote in article <9u11rs$2gt$> 1@inn.qnx.com> >…
Hello.What is the difference between in dealing with serial port directly
and
through a driver.If you are using the driver you have to start driver. The driver creats
/dev/ser1 file (for
example). You could open this file and write()/read() to/from the file.
It’s very easy. It’s
portable way - the driver take care about hardware differences.For example, I want to accept data periodically through one serial
port,
and
irregularly with the other serial port. Then which way is good?Regardless periodically or not you want to accept data, I think the
driver
is preferable way for
you. There are few reasons to work with port directly. For example, you
need to have non-standard
speed/protocol. From top of my head, we have external rs232/rs485
interface converter. The signals
on RTS and CTS lines are used for supply of first cascade of converter,
the RX/TX lines are
supplied from external power block (the simplest way to decouple supply
powers). Result: I have to
set the state of RTS/CTS lines and it should be constantly during
messages
exchange. Additionly, I
don’t know the speed of the external device. I only know it uses Break
Detect to set predefined
speed (2400) for a one message exchange. So, I have to set up RX line to
low state (send break
signal), then I send the command “How fast are you?”(on 2400), then I
get
answer “I’m 115200” (on
2400). Finally I have to set speed to 115200 and continue… Do you need
such tricks?Does the driver deal with interrupt from serial port directly
Yes, the driver does. It is a next argument for you to use the driver.
Eduard.
or should I
make ISR for that?
Thanks.Pasus
\
Mario, I think we just determined (in a different thread that dev_read() was
a QNX4 function and that there is a new QNX6 equivlent.
Pasus, do you want to check your data periodicly or will the sender send it
periodicly?
There are several options available to you. You can use select() to be
informed whren and one of several events happen. You can use a seperate
thread that just sits there and waits for incomming data. Or you can use (I
think) condread() (which replaces the QNX4 dev_read()).
–
Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net
“Mario Charest” <mcharest@clipzinformatic.com> wrote in message
news:9u37r1$i7a$1@inn.qnx.com…
“Pasus” <> pasus@mail.nu> > wrote in message news:9u35ad$gkq$> 1@inn.qnx.com> …
Hello,
Thanks for reply.
If the driver takes care of interrupt from serial port, how can I deal
with
data with periodic fashion ?If you want to time stamp the data, that is indeed a problem. But in your
case
it doesn’t really matter, data will come in a a fix rate. Using dev_read
and its timeout capability will allow you to sync with the data.Does read() have also block and unblock function for synchronization?
Pasus.
Hi,Pasus <> pasus@mail.nu> > wrote in article <9u11rs$2gt$> 1@inn.qnx.com> >…
Hello.What is the difference between in dealing with serial port directly
and
through a driver.If you are using the driver you have to start driver. The driver
creats
/dev/ser1 file (for
example). You could open this file and write()/read() to/from the
file.
It’s very easy. It’s
portable way - the driver take care about hardware differences.For example, I want to accept data periodically through one serial
port,
and
irregularly with the other serial port. Then which way is good?Regardless periodically or not you want to accept data, I think the
driver
is preferable way for
you. There are few reasons to work with port directly. For example,
you
need to have non-standard
speed/protocol. From top of my head, we have external rs232/rs485
interface converter. The signals
on RTS and CTS lines are used for supply of first cascade of
converter,
the RX/TX lines are
supplied from external power block (the simplest way to decouple
supply
powers). Result: I have to
set the state of RTS/CTS lines and it should be constantly during
messages
exchange. Additionly, I
don’t know the speed of the external device. I only know it uses Break
Detect to set predefined
speed (2400) for a one message exchange. So, I have to set up RX line
to
low state (send break
signal), then I send the command “How fast are you?”(on 2400), then I
get
answer “I’m 115200” (on
2400). Finally I have to set speed to 115200 and continue… Do you
need
such tricks?Does the driver deal with interrupt from serial port directly
Yes, the driver does. It is a next argument for you to use the driver.
Eduard.
or should I
make ISR for that?
Thanks.Pasus
\
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:9u3c9t$l64$1@inn.qnx.com…
Mario, I think we just determined (in a different thread that dev_read()
was
a QNX4 function and that there is a new QNX6 equivlent.
Oups sorry about that, I meant condread(). Old habit are hard to shake 
Hello.
Thanks, Mario and Bill for answer to my questions.
I have two senders. One sender sends data periodically, the other does
inregularly.
I am reading the interrupt part of QNX docu, which says that I can get data
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.
Pasus
Mario, I think we just determined (in a different thread that dev_read()
was
a QNX4 function and that there is a new QNX6 equivlent.Pasus, do you want to check your data periodicly or will the sender send
it
periodicly?There are several options available to you. You can use select() to be
informed whren and one of several events happen. You can use a seperate
thread that just sits there and waits for incomming data. Or you can use
(I
think) condread() (which replaces the QNX4 dev_read()).–
Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net
“Mario Charest” <> mcharest@clipzinformatic.com> > wrote in message
news:9u37r1$i7a$> 1@inn.qnx.com> …“Pasus” <> pasus@mail.nu> > wrote in message
news:9u35ad$gkq$> 1@inn.qnx.com> …
Hello,
Thanks for reply.
If the driver takes care of interrupt from serial port, how can I deal
with
data with periodic fashion ?If you want to time stamp the data, that is indeed a problem. But in
your
case
it doesn’t really matter, data will come in a a fix rate. Using
dev_read
and its timeout capability will allow you to sync with the data.Does read() have also block and unblock function for synchronization?
Pasus.
Hi,Pasus <> pasus@mail.nu> > wrote in article <9u11rs$2gt$> 1@inn.qnx.com> >…
Hello.What is the difference between in dealing with serial port
directly
and
through a driver.If you are using the driver you have to start driver. The driver
creats
/dev/ser1 file (for
example). You could open this file and write()/read() to/from the
file.
It’s very easy. It’s
portable way - the driver take care about hardware differences.For example, I want to accept data periodically through one serial
port,
and
irregularly with the other serial port. Then which way is good?Regardless periodically or not you want to accept data, I think the
driver
is preferable way for
you. There are few reasons to work with port directly. For example,
you
need to have non-standard
speed/protocol. From top of my head, we have external rs232/rs485
interface converter. The signals
on RTS and CTS lines are used for supply of first cascade of
converter,
the RX/TX lines are
supplied from external power block (the simplest way to decouple
supply
powers). Result: I have to
set the state of RTS/CTS lines and it should be constantly during
messages
exchange. Additionly, I
don’t know the speed of the external device. I only know it uses
Break
Detect to set predefined
speed (2400) for a one message exchange. So, I have to set up RX
line
to
low state (send break
signal), then I send the command “How fast are you?”(on 2400), then
I
get
answer “I’m 115200” (on
2400). Finally I have to set speed to 115200 and continue… Do you
need
such tricks?Does the driver deal with interrupt from serial port directly
Yes, the driver does. It is a next argument for you to use the
driver.Eduard.
or should I
make ISR for that?
Thanks.Pasus
\
Hi,
Pasus <pasus@mail.nu> wrote in article <9u3jpp$q0l$1@inn.qnx.com>…
Hello.
Thanks, Mario and Bill for answer to my questions.
I have two senders. One sender sends data periodically, the other does
inregularly.
I am reading the interrupt part of QNX docu, which says that I can get data
using interrupt call.
I don’t think it says you must use 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.
Perhaps I missed something fundamental in your task. If you have two senders, probably, you’ll have
the setup part (config file or interactive menu) of you program: COM1->sender1, COM2->sender2 (or
vise verso). So, you know the bahaviour of /dev/ser1 and /dev/ser2. Take a look at select()
function.
There is good example here
http://qdn.qnx.com/support/docs/neutrino_2.11_en/lib_ref/s/select.html
If you will check ports periodically then you’ll have periodically notified about data for reading
by sender 1. And you will inperiodically notified about data for reading by sender 2
This example has nothing to do with interrupts You have to change ‘/dev/con1’ to ‘/dev/ser2’
in docu’s example.
Best regards.
Eduard.
Bill Caroselli <qtps@earthlink.net> wrote in article <9u3c9t$l64$1@inn.qnx.com>…
Or you can use (I
think) condread() (which replaces the QNX4 dev_read()).
Heh, it was not easy to find this link
http://qdn.qnx.com/support/docs/neutrino_2.11_en/lib_ref/r/readcond.html
Really great function!
Regards,
Eduard.
“Pasus” <pasus@mail.nu> wrote in message news:9u3jpp$q0l$1@inn.qnx.com…
Hello.
Thanks, Mario and Bill for answer to my questions.
I have two senders. One sender sends data periodically, the other does
inregularly.
I am reading the interrupt part of QNX docu, which says that I can get
data
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
(almost)
Going through the drivers adds a little overhead, but is way way more
flexible, portable.
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
detect timeout.
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.
Hi…
ed1k wrote:
…
http://qdn.qnx.com/support/docs/neutrino_2.11_en/lib_ref/r/readcond.html
Really great function!
Agree, but it is not portable. Any suggestions on how to implement
something similar but in Linux, for example? I have a some ideas, but
not very elegant ones…
Bests…
Miguel.
Regards,
Eduard.
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com
“Miguel Simon” <simon@ou.edu> wrote in message
news:3C067A3B.54B009A1@ou.edu…
Hi…
ed1k wrote:
…
http://qdn.qnx.com/support/docs/neutrino_2.11_en/lib_ref/r/readcond.html
Really great function!
Agree, but it is not portable. Any suggestions on how to implement
something similar but in Linux, for example? I have a some ideas, but
not very elegant ones…
I don’t think there is any “elegant” method. The source to readcond() shows
it’s a special extension to the IO_READ command. I was hoping for readcond()
to be based on POSIX functions ;-|
Bests…
Miguel.
Regards,
Eduard.–
my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com
Miguel Simon <simon@ou.edu> wrote in article <3C067A3B.54B009A1@ou.edu>…
Hi…
ed1k wrote:
…
http://qdn.qnx.com/support/docs/neutrino_2.11_en/lib_ref/r/readcond.html
Really great function!
Agree, but it is not portable. Any suggestions on how to implement
something similar but in Linux, for example? I have a some ideas, but
not very elegant ones…
I think the answer is in help page (see link above):
“Thus, readcond() can be used as a higher speed alternative to consecutive calls of tcgetattr(),
tcsetattr(), and read() when dealing with RAW terminal I/O.”
All these functions are in Linux (at least in my Red Hat 7.0 machine, try ‘man termios’).
I believe you could write readcond() under Linux and your QNX stuff become portable
Eduard.