Skip navigation.
Home
The QNX Community Portal

View topic - devc-ser8250 modification

devc-ser8250 modification

Read-only archive of qnx.ddk (Writing device drivers for scanners, video card, optical mouse, etc) at inn.qnx.com

devc-ser8250 modification

Postby bfaber » Fri Feb 01, 2008 9:09 pm

Hello

We have just purchased a pc104+ board based off the XR17D158 Chipset. It is a quad serial uart chip. I am trying to get this to run with QNX and am not sure how to go about this. I have read a few threads about changing the mmap_device_io call to mmap_device_memory() call. I have never done any driver programming so if anyone could/would give me any insight on the code modification it would take to the devc-ser8250 ddk (init.c) code , I'd appreciate it.

Here is my PCI Info
Class = Communication (Serial Controller)
Vendor ID = 13a8h, Exar Corp.
Device ID = 158h, XR17C158 Octal UART
PCI index = 0h
Class Codes = 070002h
Revision ID = 9h
Bus number = 1
Device number = 2
Function num = 0
Status Reg = 80h
Command Reg = 102h
I/O space access disabled
Memory space access enabled
Bus Master disabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Error Response disabled
Data/Address stepping disabled
SERR# driver enabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = ff7ff000h 32bit length 4096 enabled
Subsystem Vendor ID = 1435h
Subsystem ID = 7320h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 6
CPU Interrupt = 6h
Device Dependent Registers:
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Thanks,

Ben
bfaber
New Member
 
Posts: 1
Joined: Fri Feb 01, 2008 8:56 pm

RE: devc-ser8250 modification

Postby maschoen » Sat Feb 02, 2008 5:30 pm

Ben,

Take a quick look at:
http://www.ortodoxism.ro/datasheets/exa ... 58v110.pdf

and then at

http://www.ortodoxism.ro/datasheets/nat ... 008652.PDF

Notice anything similar? That's right, there's almost nothing similar. These
chips process signals that have the same specifications, so many of the concepts
will be the same, eg. Stop bits, RS/DS, but otherwise they are completely different
hardware.

Assuming there is no existing driver available for your chip I highly recommend
that you not attempt to write a driver yourself unless one of the following conditions is true.

1) You are a hobbiest with lots of time on your hands and you think it would be fun to learn how.
2) You are a professional programmer who would like to break into the wonderful world of hardware drivers, and think this would be a good starter project.
3) 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 code.

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 ISR.
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.
maschoen
QNX Master
 
Posts: 2640
Joined: Wed Jun 25, 2003 5:18 pm

Re: devc-ser8250 modification

Postby jacus » Mon Feb 04, 2008 10:03 am

Hello,

We have written driver for the XR17D158 chipset.
For more details about availability etc. please contact with us.

Regards,
Jacek



Uzytkownik "bfaber" <ben.faber@lmco-dot-com.no-spam.invalid> napisal w
wiadomosci news:fo04hc$a78$1@inn.qnx.com...
Hello

We have just purchased a pc104+ board based off the XR17D158 Chipset.
It is a quad serial uart chip. I am trying to get this to run with
QNX and am not sure how to go about this. I have read a few
threads about changing the mmap_device_io call to
mmap_device_memory() call. I have never done any driver programming
so if anyone could/would give me any insight on the code modification
it would take to the devc-ser8250 ddk (init.c) code , I'd appreciate
it.

Here is my PCI Info
Class = Communication (Serial Controller)
Vendor ID = 13a8h, Exar Corp.
Device ID = 158h, XR17C158 Octal UART
PCI index = 0h
Class Codes = 070002h
Revision ID = 9h
Bus number = 1
Device number = 2
Function num = 0
Status Reg = 80h
Command Reg = 102h
I/O space access disabled
Memory space access enabled
Bus Master disabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Error Response disabled
Data/Address stepping disabled
SERR# driver enabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = ff7ff000h 32bit length 4096 enabled
Subsystem Vendor ID = 1435h
Subsystem ID = 7320h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 6
CPU Interrupt = 6h
Device Dependent Registers:
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Thanks,

Ben
jacus
Senior Member
 
Posts: 239
Joined: Tue Apr 22, 2003 8:36 am


Return to qnx.ddk

Who is online

Users browsing this forum: No registered users and 1 guest

cron