Device drivers, depending on the particular device, design requirements, and kernel, executive, or operating system (O/S), consist of a combination of one or more of the following:
Regardless of the requirements of the O/S being used (or even if no O/S is used), the device driver will need one or more of the above to be written for it, and while all of the above may require some O/S specific code, generally, only the first three are O/S specific, the rest of these items in most cases can be implemented using POSIX and ANSI standard library functions included with most C or C++ compilers (these being the best languages currently available for writing device drivers) as well as a few compiler options which are included with all commercial C/C++ compilers available today. This does not mean that it will not be necessary to use O/S specific code in the remaining items, only that if and when it is required, it will usually be minimal. What this means is that when done correctly, most of the software required for writing a device driver of any complexity, is independent of the O/S being used. Since some systems provide little or no O/S support, it is sometimes necessary to repartition the above items differently, but even in these cases, the functional code should generally remain the same, just used in a different manner. Probably the most common example of this would be writing for, or porting a driver to a system without any O/S support. In this type of case it is usually necessary to move some or all of the real-time code into interrupt routines - usually the device interrupt code, though often system timer routines are useful for handling some of this type of processing as well. When the driver is properly partitioned, it is simply a matter of where the calls to the driver code are placed in a given O/S environment, requiring little or no modification to the design or implementation of the driver software itself.
While the first three items listed above can be mildly complex for some O/S environments, the implementation is generally fairly straight forward and relatively simple to code and debug. The real challenge in writing device drivers are the remaining items. These generally require a good understanding of electronic hardware design and trouble shooting, as well as the design and implementation of operating systems. These items also require far greater skill to debug, since this type of code almost invariably requires multiple threads of execution which can collide in subtle ways that are difficult to capture and debug. In addition, for a new device, it is not only the new software for the driver that is being debugged, but the hardware as well, since this is often the first time that hardware design and/or manufacturing problems will show up. Even for older, "debugged" hardware, a new driver will often find previously undiagnosed problems due to even minor differences in driver behavior. Because of these issues to name a just a few, it is important that the driver developer be proficient in debugging hardware, and have knowledge which includes:
and their software knowledge should include a good understanding of:
In an ideal world, you should of course use an device driver developer with experience developing drivers for the desired O/S environment that you are interested in, but if you can't find such a person, it should be fairly clear from the above information, that you are much better off going with an experienced device driver developer for other O/S environments, than you would be going with someone experienced with the O/S but with no driver development experience. This is because driver development requires a fair amount of specialized knowledge and skills, and the majority of the driver development work is not O/S specific.
DeaTech Research Inc. can provide you with all of the knowledge and experience listed above, and has developed drivers in the past for the following environments:
Return to our Software Home Page
Solar powered hosting (from our cob office building) provided by: DeaTech Research Inc. using Debian Linux based servers. We highly recommend, use, and provide support services for Debian Linux.
If you should have any problems with this page or website, please send email describing the problem(s) to: firstname.lastname@example.org
Last Modified: April 12, 2007
If you wish to be permanently blocked from ever being able to send email to this domain, send your SPAM messages to: email@example.com