1. The serial port ttySx (x=0,1,2, etc.) is major number 4. You can see this (and the minor numbers too) by typing: 'ls -l ttyS.' in the /dev directory. To find the device names for various devices, see the 'devices' file in the kernel documentation. There formerly was a 'cua' name for each serial port and it behaved just a little differently.
2. In order to use a device on the Novus network, such as a router, desktop or laptop, you will need to register it onto the Novus network. Connect your device to the Novus network using an ethernet cable. Open a web browser. You should be redirected to the online registration page.

-->

A minidriver or a miniport driver acts as half of a driver pair. Driver pairs like (miniport, port) can make driver development easier. In a driver pair, one driver handles general tasks that are common to a whole collection of devices, while the other driver handles tasks that are specific to an individual device. The drivers that handle device-specific tasks go by a variety of names, including miniport driver, miniclass driver, and minidriver.

To verify that your driver is working, you should see a difference in the following pictures after plugging the CH340 to a USB port. To check that the CH340 enumerates to a COM port, you can open the device manager. You can click the Start or ⊞ (Windows) button and type 'device manager to quickly search for the application.

Microsoft provides the general driver, and typically an independent hardware vendor provides the specific driver. Before you read this topic, you should understand the ideas presented in Device nodes and device stacks and I/O request packets.

Every kernel-mode driver must implement a function named DriverEntry, which gets called shortly after the driver is loaded. The DriverEntry function fills in certain members of a DRIVER_OBJECT structure with pointers to several other functions that the driver implements. For example, the DriverEntry function fills in the Unload member of the DRIVER_OBJECT structure with a pointer to the driver's Unload function, as shown in the following diagram.

The MajorFunction member of the DRIVER_OBJECT structure is an array of pointers to functions that handle I/O request packets (IRPs), as shown in the following diagram. Typically the driver fills in several members of the MajorFunction array with pointers to functions (implemented by the driver) that handle various kinds of IRPs.

An IRP can be categorized according to its major function code, which is identified by a constant, such as IRP_MJ_READ, IRP_MJ_WRITE, or IRP_MJ_PNP. The constants that identify major function code serve as indices in the MajorFunction array. For example, suppose the driver implements a dispatch function to handle IRPs that have the major function code IRP_MJ_WRITE. In this case, the driver must fill in the MajorFunction[IRP_MJ_WRITE] element of the array with a pointer to the dispatch function.

Typically the driver fills in some of the elements of the MajorFunction array and leaves the remaining elements set to default values provided by the I/O manager. The following example shows how to use the !drvobj debugger extension to inspect the function pointers for the parport driver.

In the debugger output, you can see that parport.sys implements GsDriverEntry, the entry point for the driver. GsDriverEntry, which was generated automatically when the driver was built, performs some initialization and then calls DriverEntry, which was implemented by the driver developer.

You can also see that the parport driver (in its DriverEntry function) provides pointers to dispatch functions for these major function codes:

• IRP_MJ_CREATE
• IRP_MJ_CLOSE
• IRP_MJ_READ
• IRP_MJ_WRITE
• IRP_MJ_QUERY_INFORMATION
• IRP_MJ_SET_INFORMATION
• IRP_MJ_DEVICE_CONTROL
• IRP_MJ_INTERNAL_DEVICE_CONTROL
• IRP_MJ_CLEANUP
• IRP_MJ_POWER
• IRP_MJ_SYSTEM_CONTROL
• IRP_MJ_PNP

The remaining elements of the MajorFunction array hold pointers to the default dispatch function nt!IopInvalidDeviceRequest.

In the debugger output, you can see that the parport driver provided function pointers for Unload and AddDevice, but did not provide a function pointer for StartIo. The AddDevice function is unusual because its function pointer is not stored in the DRIVER_OBJECT structure. Instead, it is stored in the AddDevice member of an extension to the DRIVER_OBJECT structure. The following diagram illustrates the function pointers that the parport driver provided in its DriverEntry function. The function pointers provided by parport are shaded.

Making it easier by using driver pairs

Over a period of time, as driver developers inside and outside of Microsoft gained experience with the Windows Driver Model (WDM), they realized a couple of things about dispatch functions:

• Dispatch functions are largely boilerplate. For example, much of the code in the dispatch function for IRP_MJ_PNP is the same for all drivers. It is only a small portion of the Plug and Play (PnP) code that is specific to an individual driver that controls an individual piece of hardware.
• Dispatch functions are complicated and difficult to get right. Implementing features like thread synchronization, IRP queuing, and IRP cancellation is challenging and requires a deep understanding of how the operating system works.

To make things easier for driver developers, Microsoft created several technology-specific driver models. At first glance, the technology-specific models seem quite different from each other, but a closer look reveals that many of them are based on this paradigm:

• The driver is split into two pieces: one that handles the general processing and one that handles processing specific to a particular device.
• The general piece is written by Microsoft.
• The specific piece may be written by Microsoft or an independent hardware vendor.

Suppose that the Proseware and Contoso companies both make a toy robot that requires a WDM driver. Also suppose that Microsoft provides a General Robot Driver called GeneralRobot.sys. Proseware and Contoso can each write small drivers that handle the requirements of their specific robots. For example, Proseware could write ProsewareRobot.sys, and the pair of drivers (ProsewareRobot.sys, GeneralRobot.sys) could be combined to form a single WDM driver. Likewise, the pair of drivers (ContosoRobot.sys, GeneralRobot.sys) could combine to form a single WDM driver. In its most general form, the idea is that you can create drivers by using (specific.sys, general.sys) pairs.

Function pointers in driver pairs

In a (specific.sys, general.sys) pair, Windows loads specific.sys and calls its DriverEntry function. The DriverEntry function of specific.sys receives a pointer to a DRIVER_OBJECT structure. Normally you would expect DriverEntry to fill in several elements of the MajorFunction array with pointers to dispatch functions. Also you would expect DriverEntry to fill in the Unload member (and possibly the StartIo member) of the DRIVER_OBJECT structure and the AddDevice member of the driver object extension. However, in a driver pair model, DriverEntry does not necessarily do this. Instead the DriverEntry function of specific.sys passes the DRIVER_OBJECT structure along to an initialization function implemented by general.sys. The following code example shows how the initialization function might be called in the (ProsewareRobot.sys, GeneralRobot.sys) pair.

The initialization function in GeneralRobot.sys writes function pointers to the appropriate members of the DRIVER_OBJECT structure (and its extension) and the appropriate elements of the MajorFunction array. The idea is that when the I/O manager sends an IRP to the driver pair, the IRP goes first to a dispatch function implemented by GeneralRobot.sys. If GeneralRobot.sys can handle the IRP on its own, then the specific driver, ProsewareRobot.sys, does not have to be involved. If GeneralRobot.sys can handle some, but not all, of the IRP processing, it gets help from one of the callback functions implemented by ProsewareRobot.sys. GeneralRobot.sys receives pointers to the ProsewareRobot callbacks in the GeneralRobotInit call.

At some point after DriverEntry returns, a device stack gets constructed for the Proseware Robot device node. The device stack might look like this.

As shown in the preceding diagram, the device stack for Proseware Robot has three device objects. The top device object is a filter device object (Filter DO) associated with the filter driver AfterThought.sys. The middle device object is a functional device object (FDO) associated with the driver pair (ProsewareRobot.sys, GeneralRobot.sys). The driver pair serves as the function driver for the device stack. The bottom device object is a physical device object (PDO) associated with Pci.sys.

Notice that the driver pair occupies only one level in the device stack and is associated with only one device object: the FDO. When GeneralRobot.sys processes an IRP, it might call ProsewareRobot.sys for assistance, but that is not the same as passing the request down the device stack. The driver pair forms a single WDM driver that is at one level in the device stack. The driver pair either completes the IRP or passes it down the device stack to the PDO, which is associated with Pci.sys.

Example of a driver pair

Suppose you have a wireless network card in your laptop computer, and by looking in Device Manager, you determine that netwlv64.sys is the driver for the network card. You can use the !drvobj debugger extension to inspect the function pointers for netwlv64.sys.

In the debugger output, you can see that netwlv64.sys implements GsDriverEntry, the entry point for the driver. GsDriverEntry, which was automatically generated when the driver was built, performs some initialization and then calls DriverEntry, which was written by the driver developer.

In this example, netwlv64.sys implements DriverEntry, but ndis.sys implements AddDevice, Unload, and several dispatch functions. Netwlv64.sys is called an NDIS miniport driver, and ndis.sys is called the NDIS Library. Together, the two modules form an (NDIS miniport, NDIS Library) pair.

This diagram shows the device stack for the wireless network card. Notice that the driver pair (netwlv64.sys, ndis.sys) occupies only one level in the device stack and is associated with only one device object: the FDO.

Available driver pairs

The different technology-specific driver models use a variety of names for the specific and general pieces of a driver pair. In many cases, the specific portion of the pair has the prefix 'mini.' Here are some of (specific, general) pairs that are available:

• (display miniport driver, display port driver)
• (audio miniport driver, audio port driver)
• (storage miniport driver, storage port driver)
• (battery miniclass driver, battery class driver)
• (HID minidriver, HID class driver)
• (changer miniclass driver, changer port driver)
• (NDIS miniport driver, NDIS library)

Note As you can see in the list, several of the models use the term class driver for the general portion of a driver pair. This kind of class driver is different from a standalone class driver and different from a class filter driver.

Related topics

NextPreviousContents

Common serial port names are /dev/ttyS0, /dev/ttyS1, etc. Thenaround the year 2000 came the USB bus with names like /dev/ttyUSB0 and/dev/ttyACM1 (for the ACM modem on the USB bus). Multiport serialcard used somewhat differnt names (depending on the brand) such as/dev/ttyE5.

Since DOS provided for 4 serial ports on the old ISA bus:COM1-COM4, or ttyS0-ttyS3 in Linux, most serial ports on the newer PCIbus used higher numbers such as ttyS4 or ttyS14 (prior to kernel2.6.13). But since most PCs only came with one or two serial ports,ttyS0 and possibly ttyS1 (for the second port) the PCI bus can now usettyS2 (kernel 2.6.15 on). All this permits one to have both ISAserial ports and PCI serial ports on the same PC with no nameconflicts. 0-1 (or 0-3) are reserved for the old ISA bus (or thenewer LPC bus) and 2-upward (or 4-upward or 14-upward) are used forPCI, where older schemes are shown in parentheses . It's not requiredto be this way but it often is.

If you're using udev (which puts only the device you have on yourcomputer into the /dev directory at boottime) then there's an easy wayto change the device names by editing files in /etc/udev/. Forexample, to change the name of what the kernel detects as ttyS3 towhat you want to name it: ttyS14, add a line similar to this to/etc/udev/udev.rules
BUS'pci' KERNEL'ttyS3',NAME='ttyS14'

On-board serial ports on motherboards which have both PCI and ISAslots are likely to still be ISA ports. Even for all-PCI-slotmotherboards, the serial ports are often not PCI. Instead, they areeither ISA, on an internal ISA bus or on a LPC bus which is intendedfor slow legacy I/O devices: serial/parallel ports and floppy drives.

Devices in Linux have major and minor numbers. The serial portttySx (x=0,1,2, etc.) is major number 4. You can see this (and theminor numbers too) by typing: 'ls -l ttyS*' in the /dev directory. Tofind the device names for various devices, see the 'devices' file inthe kernel documentation.

There formerly was a 'cua' name for each serial port and it behavedjust a little differently. For example, ttyS2 would correspond tocua2. It was mainly used for modems. The cua major number was 5 andminor numbers started at 64. You may still have the cua devices inyour /dev directory but they are now deprecated. For details seeModem-HOWTO, section: cua Device Obsolete.

For creating the old devices in the device directory see:

Dos/Windows use the COM name while the messages from the serial driveruse ttyS00, ttyS01, etc. Older serial drivers (2001 ?) used justtty00, tty01, etc.

The tables below shows some examples of serial device names. TheIO addresses are the default addresses for the old ISA bus (not forthe newer PCI and USB buses).

For more info see the usb subdirectory in the kernel documentationdirectory for files: usb-serial, acm, etc.

Drivers Novus Port Devices Lucie

On some installations, two extra devices will be created,/dev/modem for your modem and /dev/mouse for amouse. Both of these are symbolic links to the appropriatedevice in /dev.

Historical note: Formerly (in the 1990s) the use of/dev/modem (as a link to the modem's serial port) wasdiscouraged since lock files might not realize that it was really say/dev/ttyS2. The newer lock file system doesn't fall intothis trap so it's now OK to use such links.

Drivers Novus Port Devices Gigabit

Inspect the connectors

Inspecting the connectors may give some clues but is often notdefinitive. The serial connectors on the back side of a PC areusually DB connectors with male pins. 9-pin is the most common butsome are 25-pin (especially older PCs like 486s). There may be one9-pin (perhaps ttyS0 ??) and one 25-pin (perhaps ttyS1 ??). For two9-pin ones the top one might be ttyS0.

If you only have one serial port connector on the back of your PC,this may be easy. If you also have an internal modem, a program likewvdial may be able to tell you what port it's on (unless it's a PnPthat hasn't been enabled yet). A report from setserial (atboot-time or run by you from the command line) should help youidentify the non-modem ports.

If you have two serial ports it may be more difficult. You could haveonly one serial connector but actually have 2 ports, one of whichisn't used (but it's still there electronically). First check manuals(if any) for your computer. Look at the connectors for meaningfullabels. You might even want to take off the PC's cover and see ifthere are any meaningful labels on the card where the internal ribbonserial cables plug in. Labels (if any) are likely to say something like'serial 1', 'serial 2' or A, B. Which com port it actually is willdepend on jumper or PnP settings (sometimes shown in a BIOS setupmenu). But 1 or A are more likely to be ttyS0 with 2 or B ttyS1.

Send bytes to the port

Labels are not apt to be definitive so here's another method. Ifthe serial ports have been configured correctly per setserial, thenyou may send some bytes out a port and try to detect which connector(if any) they are coming out of. One way to send such a signal is tocopy a long text file to the port using a command like: cpmy_file_name /dev/ttyS1. A voltmeter connected to the DTR pin (seeSerial-HOWTO for Pinout) will display a positive voltage as soon asyou give the copy command.

The transmit pin should go from several volts negative to a voltagefluctuating around zero after you start sending the bytes. If it doesn't(but the DTR went positive) then you've got the right port but it'sblocked from sending. This may be due to a wrong IRQ, -clocal beingset, etc. The command 'stty -F /dev/ttyS1 -a' should showclocal (and not -clocal). If not, change it to clocal.

Another test is to jumper the transmit and receive pins (pins 2 and 3of either the 25-pin or 9-pin connector) of a test serial port. Thensend something to each port (from the PCs keyboard) and see if it getssent back. If it does it's likely the port with the jumper on it.Then remove the jumper and verify that nothing gets sent back. Notethat if 'echo' is set (per stty) then a jumper creates an infiniteloop. Bytes that pass thru the jumper go into the port and come rightback out of the other pin back to the jumper. Then they go back inand out again and again. Whatever you send to the port repeats itselfforever (until you interrupt it by removing the jumper, etc.). Thismay be a good way to test it as the repeating test messages halt whenthe jumper is removed.

As a jumper you could use a mini (or micro) jumper cable (sold in someelectronic parts stores) with mini alligator clips. A small scrap ofpaper may be used to prevent the mini clips from making electricalcontact where it shouldn't. Metal paper clips can sometimes be bentto use as jumpers. Whatever you use as a jumper take care not to bendor excessively scratch the pins. To receive something from a port,you can go to a virtual terminal (for example Alt-F2 and login) andtype something like 'cp /dev/ttyS2 /dev/tty'. Then at another virtualterminal you may send something to ttyS2 (or whatever) by 'echotest_message > /dev/ttyS2'. Then go back to the receive virtualterminal and look for the test_message. See Serial Electrical Test Equipment for more info.

Connect a device to the connector

Another way to try to identify a serial port is to connect somephysical serial device to it and see if it works. But a problem hereis that it might not work because it's not configured right. A serialmouse might get detected at boot-time if connected.

You may put a device, such as a serial mouse (use 1200 baud), on a portand then use minicom or picocom to communicate with that port. Thenby clicking on the mouse, or otherwise sending characters with thedevice, see if they get displayed. It not you may have told picocomthe wrong port (such as ttyS0 instead of ttyS1) so try again.

Missing connectors

If the software shows that you have more serial ports than youhave connectors for (including an internal modem which counts as aserial port) then you may have a serial port that has no connector.Some motherboards come with a serial port with no cable or externalserial DB connector. Someone may build a PC from this and decide notto use this serial port. There may be a 'serial' connector and labelon the motherboard but no ribbon cable connects to its pins. To usethis port you must get a ribbon cable and connector. I've seendifferent wiring arrangements for such ribbon cables so beware.

If you don't use devfs (which automatically creates such devices) anddon't have a device 'file' that you need, you will have to create it.Use the mknod command or with the MAKEDEV shell script.Example, suppose you needed to create ttyS0:

Drivers Novus Port Devices Inc

The MAKEDEV script is easier to use.See the man page for it. For example, if you needed to make thedevice for ttyS0 you would just type:

If the above command doesn't work (and you are the root user), lookfor the MAKEDEV script in the /dev directory and run it.

This handles the devices creation and should set the correct permissions.For making multiport devices see Making multiport devices in the /dev directory.

Drivers Novus Port Devices Bluetooth

NextPreviousContents