Device Drivers

Where can i find a web site who explain how to write device drivers in
QNX and with source code who explain how to do that ?

And the other question would be what OS :wink:

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

A good starting question would be, what kind of device
driver do you want to write.

A disk/block I/O driver?
A charactor I/O driver?
Something more exotic?


Yuhong Ren <> engp9802@nus.edu.sg> > wrote:
Where can i find a web site who explain how to write device drivers in
QNX and with source code who explain how to do that ?


\

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

A good starting question would be, what kind of device
driver do you want to write.

A disk/block I/O driver?
A charactor I/O driver?
Something more exotic?


Yuhong Ren <engp9802@nus.edu.sg> wrote:

Where can i find a web site who explain how to write device drivers in
QNX and with source code who explain how to do that ?


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

Hi, Mitchell,

I want to write drivers for DAQ card, and some multi-function I/O controller
cards. They are not very difficult in windoz, but for QNX, I could not find
any sample code. Thank you for your any suggestion.



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

A good starting question would be, what kind of device
driver do you want to write.

A disk/block I/O driver?
A charactor I/O driver?
Something more exotic?


Yuhong Ren <> engp9802@nus.edu.sg> > wrote:
Where can i find a web site who explain how to write device drivers in
QNX and with source code who explain how to do that ?


\

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

Yuhong Ren <engp9802@nus.edu.sg> wrote:

Hi, Mitchell,

I want to write drivers for DAQ card, and some multi-function I/O controller
cards. They are not very difficult in windoz, but for QNX, I could not find
any sample code. Thank you for your any suggestion.

Did you want to write a driver for QNX4 for Neutrino? They are somewhat
different.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Yuhong Ren <engp9802@nus.edu.sg> wrote:

Hi, Mitchell,

I want to write drivers for DAQ card, and some multi-function I/O controller
cards. They are not very difficult in windoz, but for QNX, I could not find
any sample code. Thank you for your any suggestion.

I’m assuming that you are talking about QNX 4, not Neutrino.

You have two major, and one minor choice.
The major choice is whether to treat the
device as a char I/O device. This makes
most sense when you want Dev to provide
the Posix terminal features. If not,
you are in the realm of a general
interface driver.

If this is the case, then you could either
write the driver as an I/O manager. This
give your device /dev/xxxx access using
the standard open/close/read/write/ioctl
routines. You may also be able to use
standard utilities with this type of driver.
The downside is that there is more to learn.

The other option, which is easier, especially
the first time around, is to create a simple
process that receives messages in a format
of your own choosing, and responds to them.
This process does all your hardware I/O.
The structure is very simple, and there are
plenty of examples around.

If you’ll fill in some blanks, we can fill
in some more details.

Does your hardware use DMA, shared memory,
interrupts, or just I/O port access?

\

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

Hi, Chris,

For QNX4, not for Neutrino. Thank you for your any kind suggestion.


Chris McKillop <cdm@qnx.com> wrote in message
news:8oe5nl$q2v$2@nntp.qnx.com

Yuhong Ren <> engp9802@nus.edu.sg> > wrote:
Hi, Mitchell,

I want to write drivers for DAQ card, and some multi-function I/O
controller
cards. They are not very difficult in windoz, but for QNX, I could not
find
any sample code. Thank you for your any suggestion.


Did you want to write a driver for QNX4 for Neutrino? They are somewhat
different.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

Hi, Mitchell,

Thanks so much for your assistance.

You have two major, and one minor choice.
The major choice is whether to treat the
device as a char I/O device. This makes
most sense when you want Dev to provide
the Posix terminal features. If not,
you are in the realm of a general
interface driver.

If this is the case, then you could either
write the driver as an I/O manager. This
give your device /dev/xxxx access using
the standard open/close/read/write/ioctl
routines. You may also be able to use
standard utilities with this type of driver.
The downside is that there is more to learn.

The other option, which is easier, especially
the first time around, is to create a simple
process that receives messages in a format
of your own choosing, and responds to them.
This process does all your hardware I/O.
The structure is very simple, and there are
plenty of examples around.
I’d like to choose this option. Could you please inform me where I could

find these examples?


If you’ll fill in some blanks, we can fill
in some more details.

Does your hardware use DMA, shared memory,
interrupts, or just I/O port access?
Yes, the hardware will use DMA, shared memory, and interrupts. And it is

planned that the hardware management will be done within a Photon
application, we are supposed to design a software package running in Photon.
Thanks again for your time.

Regards,

Yuhong

look at ftp://ftp.qnx.com/usr/free/qnx4/os/samples/Dev_drivers there are
very good examples how to write Dev drivers with full source code

Ian M. Zagorskih
Software Developer
Novosoft CyBearNet Department
Custom software development and web design since 1992

Phone: +7 (3832) 33-36-49(*225)
Fax: +7 (3832) 39-63-58
E-mail: ianzag@novosoft.ru
For more visit http://www.novosoft.ru/

“Yuhong Ren” <engp9802@nus.edu.sg> wrote in message
news:22E71DAEC504D111B78100805FFE9DC73E687A0D@pfs21.ex.nus.edu.sg

Where can i find a web site who explain how to write device drivers in
QNX and with source code who explain how to do that ?

Yuhong Ren <engp9802@nus.edu.sg> wrote:

I’d like to choose this option. Could you please inform me where I could
find these examples?

On QUICS take a look in /usr/free/qnx4/os/samples/miscs at
chat.tgz. This only shows the message passing part.

Does your hardware use DMA, shared memory,
interrupts, or just I/O port access?
Yes, the hardware will use DMA, shared memory, and interrupts.

For shared memory, take a look at documenation for shm_open() and
mmap() routines. For interrupts, look at the qnx_hint_attach()
routine. DMA is usually controlled via I/O ports. To create
some memory that you can DMA from, you may need to use
the qnx_segment_alloc_flags() routine with the _PMF_DMA_SAFE
and _PMF_DMA_HIGH bits set. the create selector can by
used with far pointers, or you can map this memory into
your own DS using the qnx_segment_info() routine to find
the real address, and then use shm_open() on the “Physical”
memory object, along with mmap().

And it is
planned that the hardware management will be done within a Photon
application,

While there might be good reasons, I would generally recommend
against this approach.

we are supposed to design a software package running in Photon.

That doesn’t prevent you from having a separate UI Photon process
that communicates via message passing with a non-Photon driver
process.


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

Mitchell Schoenbrun <maschoen@tsoft.com> wrote:

The other option, which is easier, especially
the first time around, is to create a simple
process that receives messages in a format
of your own choosing, and responds to them.
This process does all your hardware I/O.
The structure is very simple, and there are
plenty of examples around.

For a good example driver of this type, I wrote a
_CA_PCI replacement library that uses a set of library
replacements that build a message and pass it to the
server that makes the calls. The server is compiled
to be able to make the _CA_PCI calls (-T1, root, stack
less than 64k, no shared libraries), allowing the client
or clients to not be so restricted. The archive includes
the headers for defining the message interface, the library
that builds messages, and the server.

ftp.qnx.com:/usr/free/qnx4/os/samples/misc/ca_pci_msg.tgz

-David

Mitchell Schoenbrun <maschoen@tsoft.com> wrote:

Yuhong Ren <> engp9802@nus.edu.sg> > wrote:
I’d like to choose this option. Could you please inform me where I could
find these examples?

Does your hardware use DMA, shared memory,
interrupts, or just I/O port access?
Yes, the hardware will use DMA, shared memory, and interrupts.

For shared memory, take a look at documenation for shm_open() and
mmap() routines. For interrupts, look at the qnx_hint_attach()
routine. DMA is usually controlled via I/O ports. To create
some memory that you can DMA from, you may need to use
the qnx_segment_alloc_flags() routine with the _PMF_DMA_SAFE
and _PMF_DMA_HIGH bits set. the create selector can by
used with far pointers, or you can map this memory into
your own DS using the qnx_segment_info() routine to find
the real address, and then use shm_open() on the “Physical”
memory object, along with mmap().

And /etc/readme/technotes/shmem.txt (shipped with your development
system) contains sample code for allocating DMA safe memory.

And it is
planned that the hardware management will be done within a Photon
application,

While there might be good reasons, I would generally recommend
against this approach.

we are supposed to design a software package running in Photon.

That doesn’t prevent you from having a separate UI Photon process
that communicates via message passing with a non-Photon driver
process.

I strongly suggest that the UI and the driver be seperate processes
that communicate with a message passing interface. You do not want
a GUI process also trying to handle hardware directly – the two
operations require very different code paths and decisions.
(In fact, you may want to have several cooperating processes.)

-David