Driver vs. Direct Access

Hi,

I’m debating writing a dedicated driver for a custom PC/104 A/D card or to
just access the card directly. The current software I have written uses the
I/O read & write to the hardware address and is attached to the dedicated
interrupt and the card works fine. I am currently revamping the software
and considering streamlining the interface part to use the /dev/* and file
I/O approach but speed is a major concern and I’m wondering about any trade
offs. Also, porting to Neutrino in the near future will be a concern…

Anything else I should consider???

Thanks…

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ http://www.michscimfd.com
~ mailto:<Lee.R.Copp@MichSciMfd.com>

“Lee R. Copp” wrote:

Hi,

I’m debating writing a dedicated driver for a custom PC/104 A/D card or to
just access the card directly. The current software I have written uses the
I/O read & write to the hardware address and is attached to the dedicated
interrupt and the card works fine. I am currently revamping the software
and considering streamlining the interface part to use the /dev/* and file
I/O approach but speed is a major concern and I’m wondering about any trade
offs. Also, porting to Neutrino in the near future will be a concern…

Going to a prefix namespace approach will not aid in porting the driver to
Neutrino; however, it will make the porting of the applications that use the
driver trivial (i.e. nothing but a re-compile).

As for speed, most (all ?) high performance data acquisition cards use DMA.
Therefore your driver sets up the DMA into some memory internal to the driver.
The clients issue read()s for the data they are interested in, when they are
ready for it. The approach I have used in the past, is to have an ioctl() that
establishes a percentage change that the client is interested in. The driver
(upon receiving the DMA interrupt) checks the clients desired exception levels
against the new data, and Triggers the clients select proxy when a new data
value has changed by an amount that exceeds the clients spec. Besides being
plenty fast enough for just about anything (except perhaps streaming to disk) it
makes writing clients much easier (they just do a select on the data they are
interested in).

It would also be good to have an ioctl() that allows the driver to do direct
streaming to disk (i.e. every DMA interrupt it copies all the channels to disk
with a timestamp). In the case where the only thing that is required is data
acquisition to disk, you would only need write a 2 line client to turn streaming
on or off.


A prototype will always be built, whether it is shipped, depends on how much
money is left in the budget.

As for speed, most (all ?) high performance data acquisition cards use
DMA.

We didn’t design DMA into this card but future versions will have it…The
ISA
transfers are pretty quick but it is definately a large chunk of the total
processing
time.

ready for it. The approach I have used in the past, is to have an ioctl()
that
establishes a percentage change that the client is interested in. The
driver

I will have to give this a try…

It would also be good to have an ioctl() that allows the driver to do
direct
streaming to disk (i.e. every DMA interrupt it copies all the channels to
disk
with a timestamp). In the case where the only thing that is required is
data
acquisition to disk, you would only need write a 2 line client to turn
streaming
on or off.

Sounds good. Thanks…

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ http://www.michscimfd.com
~ mailto:<Lee.R.Copp@MichSciMfd.com>

The I/O manager interface vs Custom interface issue was a red flag the
last time it was brought up, but I’ll venture a reply.

Portability-wise the I/O manager structure is much
more elegant. It will simplify porting your applications
anywhere else if that is an issue. Some would argue the use of a
standardized interface is worth whatever pain it might involve.
I agree in some cases, but not all.

However if you are porting from QNX 4 to Neutrino, a custom message
passing interface will port about as easily, and is easier to
set up.

Unless, and sometimes even if, you are talking about
speeds near the limit of your processor, using
a separate driver process will be the better choice.
If you describe what you are trying to do, this issue
could be addressed more directly.

Lee R. Copp <Lee.R.Copp@michscimfd.com> wrote:

Hi,

I’m debating writing a dedicated driver for a custom PC/104 A/D card or to
just access the card directly. The current software I have written uses the
I/O read & write to the hardware address and is attached to the dedicated
interrupt and the card works fine. I am currently revamping the software
and considering streamlining the interface part to use the /dev/* and file
I/O approach but speed is a major concern and I’m wondering about any trade
offs. Also, porting to Neutrino in the near future will be a concern…

Anything else I should consider???

Thanks…

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ > http://www.michscimfd.com
~ mailto:> <Lee.R.Copp@MichSciMfd.com>


Mitchell Schoenbrun --------- maschoen@pobox.com

“Lee R. Copp” <Lee.R.Copp@MichSciMfd.com> wrote in message
news:398f03a5$1_2@athena.netset.com

As for speed, most (all ?) high performance data acquisition cards use
DMA.

We didn’t design DMA into this card but future versions will have it…The
ISA
transfers are pretty quick but it is definately a large chunk of the total
processing
time.

Yike, reading over ISA is killing the processor, imagine a 300Mzh CPU
reading a value over the poor ISA, the CPU is waisting LOTS of cycles.
That’s where you main performance concern should be, not about
whether the data should be tranfer via IO calls or some custom
API that uses sharemem. It’s close to irrelevant unless you CPU is a
386 running at 16 Mzh :wink:

I would make the choice of resmgr versus custom API based upon
your own estimate of the gain in reduced maintenance and your own
knowledge of both technique.

Resmgr on nto are darn easy, on QNX4 I find they are not. On NTO I
would go for resmgr, on QNX4 I would probably stick with custom
interface.

Portability-wise the I/O manager structure is much
more elegant. It will simplify porting your applications

That is what I was thinking as well…

If you describe what you are trying to do, this issue
could be addressed more directly.

I have a data manager app which is currently directly reading
from an A/D card, converting 12 bit analog, scaling for each
channel, scaling into EU (i.e. temp, speed, psi) and then sending
a message containing the #, value, and time stamp to another
app which then converts it to save it to disk (i.e. time history,
histogram, etc.). It works pretty good as is but I’m still looking
for ways to speed up or streamline the process.

Thanks…

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ http://www.michscimfd.com
~ mailto:<Lee.R.Copp@MichSciMfd.com>

Mario Charest wrote:

Resmgr on nto are darn easy, on QNX4 I find they are not. On NTO I
would go for resmgr, on QNX4 I would probably stick with custom
interface.

Mario, have you looked at the iomanager3 library on quics. It is just
as simple to use as the resmgr lib on NTO.


A prototype will always be built, whether it is shipped, depends on how much
money is left in the budget.

Mario, have you looked at the iomanager3 library on quics. It is just
as simple to use as the resmgr lib on NTO.

Where at on QUICS? I can find IO and IO2 but no 3…???

Thanks…

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ http://www.michscimfd.com
~ mailto:<Lee.R.Copp@MichSciMfd.com>

Lee R. Copp <Lee.R.Copp@michscimfd.com> wrote:

I have a data manager app which is currently directly reading
from an A/D card, converting 12 bit analog, scaling for each
channel, scaling into EU (i.e. temp, speed, psi) and then sending
a message containing the #, value, and time stamp to another
app which then converts it to save it to disk (i.e. time history,
histogram, etc.). It works pretty good as is but I’m still looking
for ways to speed up or streamline the process.

What kind of data rate? How many channels? Can the data be
packetized? or must each reading be read by the application
the instant it arrives?



Thanks…

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ > http://www.michscimfd.com
~ mailto:> <Lee.R.Copp@MichSciMfd.com>


Mitchell Schoenbrun --------- maschoen@pobox.com

“Mitchell Schoenbrun” <maschoen@tsoft.com> wrote in message
news:sp0rfjbq63a50@corp.supernews.com

Lee R. Copp <> Lee.R.Copp@michscimfd.com> > wrote:

I have a data manager app which is currently directly reading
from an A/D card, converting 12 bit analog, scaling for each
channel, scaling into EU (i.e. temp, speed, psi) and then sending
a message containing the #, value, and time stamp to another
app which then converts it to save it to disk (i.e. time history,
histogram, etc.). It works pretty good as is but I’m still looking
for ways to speed up or streamline the process.

What kind of data rate? How many channels? Can the data be
packetized? or must each reading be read by the application
the instant it arrives?

500 Hz, 3 Channels (8 possible but pushing it with some digital o-scope
timing we have
done…), the data is buffered on the A/D card and then a ‘wad’ is
transfered in a single
interrupt. The data manager app crunches all the data and fills a message
structure
and then passes the ‘crunched wad’ to the storage manager. So, each sample
is NOT
over-headed with all the various latencies.

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ http://www.michscimfd.com
~ mailto:<Lee.R.Copp@MichSciMfd.com>

Mitchell Schoenbrun <maschoen@tsoft.com> wrote in message
news:sou8baij63a163@corp.supernews.com

The I/O manager interface vs Custom interface issue was a red flag the
last time it was brought up, but I’ll venture a reply.

That’s my mind too.

Portability-wise the I/O manager structure is much
more elegant. It will simplify porting your applications
anywhere else if that is an issue. Some would argue the use of a
standardized interface is worth whatever pain it might involve.
I agree in some cases, but not all.

However if you are porting from QNX 4 to Neutrino, a custom message
passing interface will port about as easily, and is easier to
set up.

Unless, and sometimes even if, you are talking about
speeds near the limit of your processor, using
a separate driver process will be the better choice.
If you describe what you are trying to do, this issue
could be addressed more directly.

But, The question IS: how to write a I/O resourse manager in QNX 4.
I’m interested in it too. And now I’m planning to take a QNX training
about it.

There QSSL don’t supply a course “How to write a Driver(resmgr)” in QNX 4,
but in QNX Neutrino. So, I have other question: By the end of course
in QNX Neutrino, can I write a I/O resourse manager in QNX 4 by myself?

If you have any advice, please tell me, Thanks in advance.

-Eric

“Rennie Allen” <rallen@computermotion.com> wrote in message
news:39900EF7.6D6E11CC@computermotion.com

Mario Charest wrote:


Resmgr on nto are darn easy, on QNX4 I find they are not. On NTO I
would go for resmgr, on QNX4 I would probably stick with custom
interface.

Mario, have you looked at the iomanager3 library on quics. It is just
as simple to use as the resmgr lib on NTO.

iomanager3 , hum. I have played with an older template I beleive,
It was far from being as simple as NTO, and far less powerfull IMHO
and it add not doc. Plus there was not book written about it :wink:

Maybe version 3 is better, I’ll have a look if the need comes up thanks.


A prototype will always be built, whether it is shipped, depends on how
much
money is left in the budget.

500 Hz, 3 Channels (8 possible but pushing it with some digital o-scope
timing we have
done…), the data is buffered on the A/D card and then a ‘wad’ is
transfered in a single
interrupt. The data manager app crunches all the data and fills a message
structure
and then passes the ‘crunched wad’ to the storage manager. So, each sample
is NOT

Well even if, you are running on a slow 386, you should not be concerned
with message passing overhead.

\

Mitchell Schoenbrun --------- maschoen@pobox.com

Eric Zhou <2Eric@21cn.com> wrote:

But, The question IS: how to write a I/O resourse manager in QNX 4.
I’m interested in it too. And now I’m planning to take a QNX training
about it.

Well this is not a simple subject. There are numerous issues
to consider, and many details that are poorly or undocumented.
Examples and trial and error are the best ways to learn.

There QSSL don’t supply a course “How to write a Driver(resmgr)” in QNX 4,
but in QNX Neutrino. So, I have other question: By the end of course
in QNX Neutrino, can I write a I/O resourse manager in QNX 4 by myself?

The Neutrino course will probably not help a lot. In Neutrino
a library is supplied with default routines. You only have to
change ones specific to your manager. With QNX 4 you have
to supply a bare minimum, which the examples should get
you through.

If you have any advice, please tell me, Thanks in advance.

Well if you are in a hurry, you’ll do a whole lot less
head scratching if you write your own interface. Typically
you use the first 2 bytes as a short to indicate a command
byte. The data after this may be variable length dependent
on either the command byte, or a length byte. You process
messages in a look like this:


while(1)
{
pid = Receive(0,msg,sizeof(msg));
switch(msg.cmd)
{
case MSG_TYPE_1:

Reply(pid,…);
break;
case MSG_TYPE_2:
.
.
.
}
}
}

Once you have the basic structure, you just fill in
as you go. Of course adding things like interrupts
and timers complicates things a little.


Mitchell Schoenbrun --------- maschoen@pobox.com

“Mario Charest” <mcharest@zinformatic.com> writes:

“Rennie Allen” <> rallen@computermotion.com> > wrote in message
news:> 39900EF7.6D6E11CC@computermotion.com> …
Mario, have you looked at the iomanager3 library on quics. It is just
as simple to use as the resmgr lib on NTO.

I looked for this, but could not find it. Could you please post the
path in /usr/free where this might be hiding?

Thanks,
Andrew


Andrew Thomas, President, Cogent Real-Time Systems Inc.
2430 Meadowpine Boulevard, Suite 105, Mississauga, Ontario, Canada L5N 6S2
Email: andrew@cogent.ca WWW: http://www.cogent.ca

Andrew Thomas wrote:

“Mario Charest” <> mcharest@zinformatic.com> > writes:
“Rennie Allen” <> rallen@computermotion.com> > wrote in message
news:> 39900EF7.6D6E11CC@computermotion.com> …
Mario, have you looked at the iomanager3 library on quics. It is just
as simple to use as the resmgr lib on NTO.

I looked for this, but could not find it. Could you please post the
path in /usr/free where this might be hiding?

It appears they have renamed it to iomanager.tgz. There used to be
iomanager.tgz, iomanager2.tgz and iomanager3.tgz (last year, when I first
happened upon iomanager3). The old iomanager.tgz was a joke; the new one is
very good (it is dated May 26 last year). It lacks only io_select (which I have
added in my internal version here - took about an hour).


A prototype will always be built, whether it is shipped, depends on how much
money is left in the budget.

Andrew Thomas <andrew@cogent.ca> wrote:

“Mario Charest” <> mcharest@zinformatic.com> > writes:
“Rennie Allen” <> rallen@computermotion.com> > wrote in message
news:> 39900EF7.6D6E11CC@computermotion.com> …
Mario, have you looked at the iomanager3 library on quics. It is just
as simple to use as the resmgr lib on NTO.

I looked for this, but could not find it. Could you please post the
path in /usr/free where this might be hiding?

I couldn’t find it anywhere. There was a iomanager.tgz and an
iomanager2.tgz, but I didn’t see a 3rd edition.

I seem to remember them being slightly different, mostly in the
examples. The core of the library was, I seem to remember,
mostly the same.

-David