How multiport serial driver really works

Hi All,
I need to develop a multi port serial device driver and its device details are as follows,

Device is based on the 16C554 / 16C654 quad serial port IC.This device contains 4
identical sets of registers, one for each port, and is compatible with the standard PC serial
port. The 16C554 has 16-byte FIFOs for each port and operates up to 115.2kbaud, while the
16C654 has 64-byte FIFOs and operates up to 460.8kbaud.

Please provide the answers to few question.

  1. I want to understand, how exactly multiport really works internally as far as S/W and H/W is concerned. I meant there is exchange of data in read / write operation at multiple ports say 4 ports ( 5,6,7,8) then how data flow and things happening in the serial driver.

You need to look at some hardware specifications for an 8250 and then a 16550 chip. The 16550 is a superset of the 8250 which is compatible. The 16550 adds the FIFO feature.

A complication your 4 port device adds is that it uses just one interrupt, so when the interrupt occurs you need to check each of the four chips to see if it fired. The hardware design makes this easy, you just read one register.

Hardware flow control is setup by configuring the chip to fire interrupts when certain line changes occur. When the interrupt fires you read an interrupt status register to find out that the line change happened and then take appropriate action. Most of this type of handling, including loading and unloading data must occur in the interrupt handler. The existing 8250 driver should illustrate all of this. If you need to modify the current behavior, you will be much better off understanding and then modifying this driver than if you try to write a driver from scratch.

Of course if you are new to QNX, this will be a very challenging project.

Hi maschoen,
I have got one serial driver but i need to test it fully. Can you please provide the scenerios for applications to test the driver.

I would start simple, use an external source and see if you can read incoming data. Then do the reverse. If that all works you might try the obvious variants, two readers or two writers. Finally, make sure it works with two streams going at once. qtalk is a handy utility for this type of testing.

Please have a look on my test scenario.

Case 1 : Application 1 is writing some data( using while(1)) on port dev/ser1 and at same time application 2 is also writing some data (using while(1)) to port dev/ser1. Both applications wrote data on port dev/ser1. 
       
Case 2 : Same as above except application 2 is writing data on different port dev/ser2. 

I wanted to know, how driver manages writing of two applications on same port and different port???

   Please clearify my doubt about driver operation,
 1.  Driver or io-char shall create thread for every ports given during command line option. I meant for every port say dev/ser1 to dev/ser8 , there are 8 threads running to process read / write opertions.
2. What is the significance of waiting read, write and open for TTYDEV structure ????? 

typedef struct ttydev_entry {
iofunc_attr_t attr;
iofunc_mount_t mount;
TTYWAIT *waiting_read;
TTYWAIT *waiting_write;
TTYWAIT *waiting_open;

}

The driver manages writing to the same port and to different ports by the use of internal control blocks. These control blocks have buffers. When two applications write to the same port, the bytes go into the buffer in the order received and therefore are sent in the order received. If a 2nd application writes to a 2nd buffer, the data is kept in a 2nd control block buffer so the data gets to the right serial port. If a port is not sending at the time of the write, the driver will load either one byte or multiple bytes if the device has a FIFO. Thereafter, bytes are loaded from an interrupt handler that is fired when one or more bytes have been sent.

Using the standard resource manager functions, threads are taken from a pool. When more threads are needed they are created dynamically, and when too many are idle, some are automatically destroyed. This is a standard feature available to resource managers. You could write your code differently, creating specific threads for a specific port however you must then provide a way for an application to know which thread to send to. Most resource managers have point of connection. A single thread in receive mode wakes up and handles each message, but not a specific thread. I don’t understand your question 2.

My 2nd doubt is as follows,
TTYEV structure is used as interface between the serial driver (devc-ser8250) and io-char library. In the TTYDEV structure there are fields called waiting_read, waiting_write and waiting_open. In serial driver (devc-ser8250) code, there is no instance of above fields and i am assuming above mentioned fields are used by io-char library to handle multiple application read /write operation. Am i correct on this ???

  One more help needed for slogging. If i use slogf API in driver for logging purpose. My driver is doing something, which cause system to shutdown. How to put logging in driver code. My requirement is know, what functions of devc-ser8250 are called during driver operation.