Writing Real-Time Device Drivers for Telecom Switches, Part 2 of 2

Instead of jumping into the organization of files or programming techniques when programming for real time, first evaluate background information. Ask questions about time constraints, message frequencies, buffer sizes and data path dependencies. Also, ask if there is any intelligence built into registers. You will find this information useful when you are in the debugging and implementation stages. The safest way to learn how to write software drivers is to modify an existing driver. Writing one from scratch might be a little hard for a novice writer.

Here are the basic steps for writing a software driver:

There are several ways to structure the hardware access in your HAL layer. You could have functions like _APS_WriteMBRtable() and _APS_ReadCellCounter(), and they will simply talk to the hardware directly via RW_ReadLongWord().

There are also some drivers that define a struct and take a pointer to it and point it at the base address of the device. They simply can dereference the struct pointer as

_APS_Memory->contextTable.entry[12].esot = 1;

Or you could pass all hardware access through a small number of specialized access routines. If these are inlined, there is no performance hit:

_APS_WriteMem()
_APS_ReadMem()
_APS_WriteReg()
_APS_ReadReg()

Think of the time it takes to do this:

address = _APS_Base + _APS_tStats;
RW_WriteMem(address, value[1]);
RW_WriteMem(address+4, value[2]);
RW_WriteMem(address+8, value[3]);

vs. the amount of time to do this:

_APS_WriteMem(_APS_tStats, value[1]);
_APS_WriteMem(_APS_tStats+4, value[2]);
_APS_WriteMem(_APS_tStats+8, value[3]);
_APS_WriteMem(longword address, longword value)
{
  RW_WriteMem(_APS_Base + address, value);
}

You may have a device that uses mailbox access rather than a memory-mapped structure. Often such mailbox accesses allow you to write multiple values at once. Obviously, it would be inefficient to have a _APS_WriteMem() that accesses the mailbox but only writes one word at a time. But you could have a _APS_WriteEntries(longword data[], longword startAddr, int numEntries) routine that still would be your one point of access as described above. Sometimes your device may allow mailbox access in various sizes (e.g., bytes, words, longwords). You should provide this flexibility.

There are several parts to driver initialization:

These should be kept as separate functions so each can be called at the appropriate place during startup. Also, as much as possible, keep initializations free from dependencies on other modules. People are always moving different initializations before and after others, making interdependence a real problem.

When accessing a device that has more than one data path, i.e., four streams of data flowing into it (0-3), you should take extra care in finding out which channels need to be accessed. Let's say we have two slots labeled (0-1), and we have eight ports per slot (0-7). By design we have the following: ports 0-3 on slot ID 0 belong to data path 0, ports 4-7 on slot ID 0 are attached to data path 1, ports 0-3 on slot ID 1 are associated with data path 2 and ports 4-7 on slot ID 1 are connected to data path 3. Notice the importance here of knowing if the numbers are 0- or 1-based. Such a complication in the hardware can lure us to write several conditional if/then/else statements. We can avoid that by plotting a binary table of the required results. Then we can figure out the bit shifting that will help us.

The following piece of code simplifies the table into a couple of register shifts. I am sure that bit shifting can be your friend in many cases, but you have to be careful:

DataPathSelected = (ioSlot<<1) + (PortNumber>>2)

If you plot the table for values of ioSlot ranging from 0-1 and PortNumber 0-7 per I/O card, DataPath will follow Table 1. This will actually give you a map and will always result in a 0 or a 1 indicating the data path required (see Listing 1).

Table 1. Binary Table of Required Results