Take a quick look at:
and then at
Notice anything similar? That’s right, there’s almost nothing
chips process signals that have the same specifications, so many of
will be the same, eg. Stop bits, RS/DS, but otherwise they are
Assuming there is no existing driver available for your chip I highly
that you not attempt to write a driver yourself unless one of the
following conditions is true.
- You are a hobbiest with lots of time on your hands and you think it
would be fun to learn how.
- You are a professional programmer who would like to break into the
wonderful world of hardware drivers, and think this would be a good
- Your life depends on accomplishing this.
Otherwise I suggest you seek professional help.
Assuming you meet one of these criteria, here are some basic things
you should know about drivers in general, and QNX specifically.
A driver can logically be divided into to two types of code, that
required to interface to the OS, and that required to talk to the
hardware. In a well written driver, these are separated. I
suspect this is so in the available QNX 8250 source, which means that
you can at the very least learn how to interface to the OS from this
code, and at best you will merely have to drop in some hardware
You might be able to find some hardware code for this chip on-line
such as if there is Linux source available. This sometimes can be
useful, but often not. It is very unlikely you would find source
for the hardware that could just be dropped into the QNX 8250
driver, but in an ideal programming world, this would be possible.
Even if you find good resources at described above, you will have to
become familiar with both of these areas in order to debug your
driver. Interfacing with the QNX OS involves understanding the
structure of a resource manager along with the details of getting
permission to access I/O ports, connecting an Interrupt Service
Routine to an interrupt, querying the PCI configuration information,
along with a general knowledge of how message passing under QNX
works. There are special rules regarding what you can put in an
Familiarity with the Posix thread and process structure may also be
required, especially since your chip supports multiple serial ports.
On the hardware side, you will need to understand the I/O port
assignments of your card, and how they function, or similarly the
memory mapped version. You might also note from the specs above
that since this card has DMA capability, you might need a short
course in what a DMA channel does, and how to program it. And of
course you will need to understand how to turn on interrupts, and how
to service them.
In addition to all of this, I might note that debugging a driver
requires a bit more than a standard program. You will not always be
able to step through instructions. Your driver may occaisionally
crash your system. It is always good if you know how to reproduce
this. If not, the debugging experience will be much more, uh,
exciting. An understanding of what a race condition is, and what
kinds of coding errors cause one can be useful here. Finally, once
you have a driver that is functioning, other issues like efficiency
can sometimes be a problem.
While assembler is rarely needed in a driver anymore, an understanding
of it can be. For example, while you don’t need to code a “rep
inb” instruction, you might need to know what it is, why it
might be important, and what subroutine will provide it for you.
Expect a wide development cycle. Usually the first version of a
driver works in the lab, but when put in the field, unexpected
problems crop up. If you are dealing with hardware from a specific
manufactorer, (unlike an 8250) a good relationship with the techies
at that company can be useful, helpful, and even required. Not all
hardware works as described in its spec sheets all the time. In
rare instances, an oscilliscope can be helpful.
That said, getting a driver working is a very satisfying experience.