Eetindia.co.in

Device drivers for nonexistent
Dependencies are an interesting subject. You can be dependent on a variety of chemical sub-stances, some legal and some illegal, but rarely is this type of dependency considered healthy for the dependee. You can also be dependent on people such as a spouse or sibling, which can also be considered unhealthy if taken to an extreme. cies in the schedules for our engi-neering projects. In this situation we are referring to something that must be completed before anoth-er step can be started, meaning that the latter task is completely dependent on the output of the former. This procedure can also be considered unhealthy for a proj-ect, because it prolongs the time it Figure 1.
takes to complete the job, thereby extending the time before it can almost becomes an inescapable thing at one time. be delivered to paying customers. article of faith--a simple conse- In most environments, this for the upper side of the device Extend this time too much, and quence of system development. situation has changed. Engineers driver--the one that interfaces the customers will go pay some- But there are times when it is are becoming more specialised with the application software one else instead. So how can we possible to break addictions, as each subfield becomes more and the operating system. Also, relieve some of the dependencies and this addiction is often one complex. Hardware designs are the increased complexity has regarding our projects? The last of those cases. Let's take a look often being done at the ASIC sometimes made it necessary to time I looked, the Betty Ford cen- at the technical aspects of writing level, and entire system designs move to higher-level languages tre didn't handle an addiction to device drivers and see about find- might be complete and to some such as C, rather than the vener- linear system development. It is up ing ways to write them without extent tested before they ever able, traditional assembly lan-to us to identify areas where work having hardware available. achieve physical incarnation. guage. But opportunity is also An example of this need for Traditional implementation
boarding step, the time penalty of the overal job of writing the technique
for linear development becomes device driver is directly involved ing device drivers. Any system The first step is to examine why even more severe. that requires custom hardware things are the way they are. And the software side of the at least that part of the driver wil probably need software that Writing device drivers after the equation is not getting any sim- is specifical y written to operate hardware is practically done pler either. A device driver used actual hardware. In the fol owing it. It is almost traditional with made a lot of sense when the to consist simply of a couple of sections, I wil discuss some of such projects to put off the job of same engineer was doing both interface functions that were the techniques I have used to do creating that driver code until the jobs. Typically, these engineers cal ed directly from the applica- hardware exists in physical form, were hardware engineers who tion software. This situation has cases go beyond.
which is close to the last step as learned assembly language, but changed with the requirement
far as the hardware engineer is their major job was still more for increased multi-tasking and Stubbing out device
concerned.
associated with a soldering iron other operating system services, interface code
This linear process of system than an editor. Linear develop- forcing the device interfaces to The typical RTOS device driver development is exactly the type ment was a consequence of the adhere to the device driver proto- of unhealthy dependency I am fact that one person couldn't col as dictated by the RTOS. talking about. The dependency concentrate on more than one This increased complexity ring to a physical device at this  | August 1996 | EE Times-India
point, not a file system that needs to be able to maintain a coher-ent structure to the data on the physical device. File systems are usually implemented as a sepa-rate layer that uses the physical device driver, rather than being part of the driver. device driver involves handling the bookkeeping required for the top end of the driver. As I said, this job has gotten more complex over the years as our software environments have grown in capability. The good news is that little of this increased complex-ity is dependent directly on the hardware. At a minimum, this procedure wil represent the work that can always be done without having physical access to the I/O device itself. The entry points and Figure 2.
some discussion of the hardware dependence of each is shown in by a success/failure return. debugging data access conflicts can easily become too dependent Figure 1 and detailed below.
Close is the last of our primarily between the ISR and the non-in- RTOS-centric functions. Shutting terrupt device driver code. With write, we are firmly on easily to another system. tures and communication paths about flushing and deal ocating the system-dependent side with that the driver wil use. There is data paths than about controlling this entry point. Write should be there will probably be several usual y a set of boilerplate code the hardware. In fact, getting back handled much the same way hardware dependencies here, that sets up the interface be- a bad status from a close routine is as the read interface, taking the but don't expect to find all of tween the RTOS and the driver, a fairly unusual situation, so much code as far as is possible before them before the hardware itself at the end of which the device so that it may not even be worth running into the actual hardware. appears. Control is the entry is marked as either successful y testing a failure mode. Timer ticks also work here, acting point you may be using to fix the With read, we are getting to like a clogged output device that problems you find in the actual Create is also where initial the heart of the matter. A read can test the limits of the buffering hardware that were not evident readiness of the hardware itself is function cal usual y has al the in the system. Remember, the in the specification. often tested. It is relatively trivial RTOS overhead taken care of point of debugging is to find the to stub out this code, reporting ahead of time, and it is typical y places where the code doesn't on our device driver, but the either success or failure. Note that about getting data from the de- work, not to show off the places hardware may stil not exist. Is it it is important to implement both vice in as timely a manner as where it does. of these possibilities, because possible. If the driver design is The control interface is the our device driver programmer? either can (and wil ) happen in unbuffered, there is little you can catch-all, usually an ugly re- real hardware at some point. do with this entry point other minder of al the imperfect details little or check out the latest Remember, the goal is to get as than pass along dummy data of working with real hardware. games? This time might have far as possible. Open is another and varied status responses for Control is where you do the been playtime in the past, but not entry point that is often more testing purposes. things that don't fit well with these days. Our demanding proj- Buffered devices provide the logical abstractions of the ect schedules require as much device interface. Open typical y much more opportunity to do other entry points, so there are work as possible to be done as sets up the data structures that a work ahead of time. One of my usually a polyglot of functions early as possible, so we need to particular task or function wil use favourite tricks is to completely that must be performed. Many look at ways to do as much of the to communicate with a physical implement the read function of these functions wil be heav- device or a logical device via the without the corresponding inter- wil probably also be back doors, Cross-development
Again, most of this code can be ing. Once that path is wrung out, I where the application code and The option of cross-develop- written ahead of time. If the device might add code to a system timer the device driver wil be passing ment is always worth exploring. driver is a true one (a network tick interrupt service routine (ISR) information back and forth. Implement this entry point as for isn't available, try to set up per network protocol layer), then in the read buffers. This technique soon as necessary, but use it as a an environment that is as similar the device-dependent portion is takes the programmer a long way last resort as far as the design of as possible to the development probably minimal. Either way, this down the path of debugging your device driver is concerned. environment you need, and de-situation can also be stubbed out the code, even to the point of An application and a device driver velop most of the software there.  | August 1996 | EE Times-India
It often pays to have that system understanding (or lack thereof) " Embedded Systems a necessity for practical y every be as readily available as possible. of that description wil be tested Programming, January 1996, embedded system develop-I have worked on development against the real chip. p. 36) looking at the state of ment, so you would think that by If that period of examination is simulation environments, and this point there would be better undertaken in combination with the fruits of some of the merg- neers, and it seems like useful an unstable hardware platform ers described in that article are There certainly have been seri-work has barely begun before or an unstable programming starting to be available.
In general, this option has hardware and software realms Fortunately, engineers these programmer to get comfortable been getting better over the over the last few years, but those days typical y have a wealth of wil inevitably be longer. If that last few years. Simulated envi- computer power at their disposal. takes place at the end of the proj- ronments exist for most of the maturing in a vertical fashion- ect on the real hardware, then the low-end CPUs and are often con- cal y every engineer can provide a project may well slip its schedule. sidered to be part of the compiler each specific field without inte-mature, accessible development One way around this problem is to development system. Unfortu- platform for many environments, get the programmer a more stable nately, the weakest part of these development toolset. including RTOS device drivers. The key question is whether ment cycle. In my experience, it of specialised I/O devices. the device you are developing is well worth the effort to build a The solution to this is a link frontier in the embedded system for has a close relative available simple platform for initial testing into an executable model of the world. Large EDA companies are on a PC platform. Obviously, the based on a PC or other stable en- chip in question. These models looking to subsume software into best case occurs when exactly the vironment. The cost of this effort exist for standard devices, but the hardware design systems, so same chip is available, but if that can provide effective insurance they are often proprietary and ex- isn't the case, a similar one can against a much more expensive pensive. There has been a move- usual y be found. For example, slip late in the project. ment in the hardware community about how embedded software lately to accumulate a series of development works. Until this for a print server that consisted Device simulation
these models under a public happens, though, it is primarily of a 68000-based single-board But what happens if you can't domain code base, modelled up to the ingenuity of individual computer with a proprietary get a similar enough standard after the GNU software effort, device driver programmers to RTOS. The schedule was ambi- platform? This situation usual y but until this accumulation hap- tious (are there any that aren't happens when you are working pens this option wil be primarily done earlier in the project cycle. these days?), and the hardware at either the high or the low end available to those customers of To accomplish this feat, device was late in coming. The serial of the computing spectrum. EDA companies who are design- and parallel interfaces for the Low-end 8-bit CPUs are turning ing specialised systems and have complete understanding of both 68K were based on standard PC into ASIC libraries these days and relatively deep pockets. interfaces, though, so I developed getting modified or integrated But the advantages of this type available and the capabilities of and debugged the drivers on my with I/O devices to create the of simulation environment are their software tools. PC. The total time it took to bring long-promised 'system on a chip.' undeniable. With them the device them up on the target hardware These systems provide maximum driver programmer has complete that these programmers should was about a day and a half. cost reduction for systems with access to internal states of the be more demanding in al ocat- But specialised hardware can be high volumes, but they can be a device being programmed. This ing resources for new projects. real pain to write software for, due accessibility avoids those frustrat- oped a driver for an ISDN interface to the fact that they won't physi- ing problems where the I/O chip assembly language to C. Get time cal y exist until near the end of the goes off the deep end, providing added to the schedule to build ily, the company had anticipated project. And even then, it is often little or no information about what prototypes dedicated to early ex-the complexity of that effort and impossible to effectively use an caused the situation or what it is perimentation. Device drivers are had built a special daughtercard emulator or logic analyser to de- doing internal y. The combination in many ways the critical founda- for an off-the-shelf VME card. The bug your software. The same can of visibility and early access has tion of embedded systems, so the combination of the VME board hold true on the upper end. If you been enough to keep interest in people responsible for creating and the daughtercard gave me are working with a new CPU, there simulation alive even when the them should not have to make do an environment similar to the an- is usual y a lot of system software current implementations haven't with arbitrarily limited resources. ticipated custom board, al owing to be written. Often, it is desirable lived up to the promise. If the But once you have those resourc-us to uncover some interesting to have this software execute on anticipated combination of fast es, it is up to the programmer to anomalies in the ISDN chipset in a a simulation of the CPU to test it simulation platforms, readily avail- able high-quality simulations, and such as device drivers, that cuts The only real answer in either integration with software-centric across specialties must always these situations is that there will of these cases is a simulated debug environments becomes a be looking for innovative ways usual y be a period of explora- hardware environment similar reality, then simulation may one to solve problems. Don't settle tion for the programmer who is to the one shown in Figure 2. day become the standard way of for doing things the way they've
working with an unfamiliar I/O I have not had good luck with writing system software.
device. If the only information these in the past, but it appears
the programmer has to work with that they might be final y coming Prozac Time
is a paper description, there will of age. I wrote an article recently In some ways, this topic is very
be a period of time where the ("depressing. Device drivers are
 | August 1996 | EE Times-India

Source: http://www.eetindia.co.in/ARTICLES/1996AUG/PDF/EEIOL_1996AUG01_EMS_INTD_TA.pdf?SOURCES=DOWNLOAD