Talking to hardware under QNX Neutrino
If you've ever tried to develop a device driver under a traditional Unix operating system, you're sure to feel spoiled when developing hardware-level code for QNX Neutrino.
Thanks to Neutrino's microkernel architecture, writing device drivers is like writing any other program. Only core OS services reside in "kernel" address space -- everything else, including device drivers, reside in "process" or "user" address space. The impact of this is that a device driver has all the services that are available to "regular" applications.
Many models are available to driver developers under Neutrino. Generally, the type of driver you're writing will determine the driver model you'll follow. For example, graphics drivers follow one particular model, which allows them to plug into the Photon graphics subsystem, whereas network drivers follow a different model, and so on.
On the other hand, depending on the type of device you're targeting, it may not make sense to follow any existing driver model at all.
In this article, we'll focus on the low-level details of accessing and controlling device-level hardware, which are common to all types of device drivers.
View Entire Paper | Previous Page | White Papers Search
If you found this page useful, bookmark and share it on:
If you are familiar with RSS feeds, you can also sign up for our free blog feed. Our RSS feed is updated in real-time while our newsletter is updated daily.