hi all,
i have to develop a gpio driver .From the qnx documention of writing a driver i came to know that, we have to write a driver as a resource manager.Please clarify my following doubts?
i am using qnx 6.4 and jade processor. Thanking you in advance.
You are not enforced to do so, if you will be running just the one app and exclusivly your app will be run you may be better off just talking directly to your hardware within your app (thread/process). (thats what we do with our selfmanufactured RS232 plugin cards) The big advantage is you won´t have to write an complex RM for handling all kind of IO and can directly control the flow within your app. If the system should not be exclusivly used by your apps, you should consider writing an RM or filter, so developers will talk to the RM instead of the hardware.
We use a proprietary software and we exclusivly use this cards in our system (the card is installed as a module on an proprietary expansion bus to the CPCI System) and therefore we emulate the complete protocol (signal) in our software just having the card and the chip for handling real in and output (FIFO, IO, Powersupply etc.). We do not run RM, but we also have noone other trying to connect to the card than using our software on our sold system ^^.
sorry, no idea.
PS: I think the RM/filter really comes in handy if a lot of different apps/versions/developers try to take usage of your chip/port/card/whatever. If you exclusivly run the Chip/Card… yourself and also just using it in one app, a direct access is at least less complex implementation and has a greater flexibility. Also as maschoen said, the /dev/something will just work within a RM
Hi all,
thanks for alll your replies.But eeven now i am not clear on this.So if we want to write a driver(eg: gpio or led) can we write it as a program that won’t use resource manager? i am confused?
pls help me.
The RM is nothing else than a process handling the communication between apps and hardware.
But it is possible to directly talk to the hardware without a RM.
So, yes, you can write a programm not using a RM but talking to your gpio/led 
hi,
but without using RM can we open the device.In RM we have an option eg: open("/dev/ser", like this… but if we don’t use RM library how can we access the driver from application?
thanks in advance
I will try to answer your question by taking a step back.
In most OS’s a driver consists of two parts, the OS interface code, and the hardware interface code. The hardware interface code is somewhat independent of the OS being used, but the OS interface code is specific to the OS.
In most OS’s a driver must be run as part of the kernel. The OS and processor protection features enforce this. So the only way to access the hardware is with a driver running as part of the kernel, and this is only available from an application by going through the OS interface.
Things are different with QNX. Drivers are not run as part of the kernel, but run as special applications. By special I mean that they must be run as super user and must also first ask the OS for permission to touch the hardware. The standard OS interface is implemented most easily by using the RM library. This interface can also be used for purposes other than a hardware driver for example a printer driver that converts text into PostScript or PCL.
There are other options. At the lowest level, the RM library consists of messages being passed to and from the driver. You can build your own interface using message passing, sending messages to your driver process and having it do the work for you. Again, this process must be run as super user and must ask the OS for permission to touch the hardware. This can be much simpler than the RM interface however there is not much point. The RM library needs a minimum of code to get started and there are examples available.
Another possibility if only one application process will access the hardware is to build the driver code into this application. You can still separate the driver code by isolating it into separate code modules. In this case, your application must run as super user.
There are a few other situations to consider. If you are writing a disk driver, you could implement an RM, but it would need to provide both hardware code as well as implementing a particular disk format. This is very inconvenient. What if you want the drive to have more than one disk format on it, QNX and DOS for example. The RM would have to handle all of this. Instead, QNX provides a special interface for disk drivers so that all you need to write is the disk interface code.
Another issue has to do with hardware that shares a common hardware interface. Examples are PCMCIA, Cardbus, and USB. QNX provides a generic RM for these interfaces, but additional driver code must be used for each different type of device. For this type of code there are special interfaces and a toolkit to support development.
The last example I’ll mention is network drivers. QNX provides a very flexible interface that allows the separate creation of hardware drivers, protocols, and misc. filters. This too requires a special interface and the related toolkit.
take a look at the pci* functions. There are also examples.
In short it will end up in finding your pci-based card on the pci bus, mapping their physical memory into your application memory space and writing there or mapping the io-address and sending there.
The examples in this chapter should give you an idea.
A good starting point is pci_attach_device(), but there are also some examples located here in the forum.