After a couple of years I was given a team, and led a half-dozen software development engineers in the System Software department on new BusinessMate and PowerMate product development initiatives. One of these projects involved a just-released version of the Intel 80486 microprocessor and NEC's customized flavor of SCO Unix. I helped some of my staff on writing device drivers for an OEM'd video display tube to replace the standard CRT, which used the serial port as /dev/tty01 instead of the video console port. Others I helped in the intricacies of the network drivers for TCP/IP and NFS and making sure the networking subsystem worked well on the new hardware platform. And one poor soul on my staff got the dubious distinction of figuring out why the system always crashed if loaded with more that 16MB of RAM - something to do with the memory software subsystem and a particular semiconductor chip we were using.....
But alas and alack, there are never enough software developers to go around when you need them, so I took on one task myself which caused more than a few all-nighters and many late evenings of diet cola and munchies from the vending machine. On this hardware platform that was still under development, the super i/o chip was integrated on the motherboard with some other glue logic, and for some unfathomable reason the damn thing would just freeze up and die everytime someone tried to send something out to the printer port. Normally in a PC the parallel port used for printing didn't cause much of a problem, but now it seemed on this particular puppy it was going to cause much wringing of hands and gnashing of teeth....
Slowly but surely, all the other product development issues were being finalized and achieving closure. The new OEM'd display, which the marketing folks called "The NEC Multiterm" (kinda catchy, eh? Not.) was ready for release, the BusinessMate 486/33E was ready to be launched, and one by one the technical software issues were being resolved. Except for the damn panic traps on the parallel port. I dived into the kernel to look for where the problems might lie. I checked the order in which all the system's different device drivers were booting up in the /etc/rc directory. I looked at the installation scripts for the some add-on desktop publishing packages. I tested the port using DOS and Windows commands, and I still couldn't find anything wrong. It was only under our flavor of SCO Unix that it didn't work..... None of my debugging and troubleshooting techniques seemed to be yielding any positive results.
The symptom was simple enough, easy to see. If you tried to print something, the system just shit the bed (that's a technical term, of course). It didn't matter what kind of printer was attached to the parallel port, there was an error message that spewed to /dev/console and the system froze up, accepting no further input, and had to be re-booted. So I started looking at the specific IRQ (I think it was number 9, but its too long ago to be sure) and how it was handled by the operating system's interrupt handler routine. The device driver written for IRQ9 was interrupt driven, and I noticed the state machine was fine up until it actually started receiving data. So I thought to myself, what if I changed the paradigm, mixed it up a bit, and caused the device driver to be polling rather than interrupt driven. There were some command line over-ride switches that could be thrown in the printer's application layer that called the device driver that could force it into a polling mode, so that it was waiting and expecting to receive data rather than sitting there doing something and getting interrupted. If I could make sure this would happen everytime someone tried to print something, then maybe I could get the system to stay up long enough to print a document.....
Sure enough, several code modifications and some brief validation cycles later, the problem was resolved. By changing the SCO Unix parallel port printer driver from interrupt driven mode to polling mode, the system no longer crashed when someone printed a document, and all was right with the world..... Who knew? Who would have thought that it would make a difference? Polling or interrupt driven? But it did. Device drivers. So compact, yet so complex. Go figure....
Beginning in June 2004 with TransformTec, Inc. (my product development and technology broker company) , I now bring together technical teams and acquiring companies to monetize intellectual property. I have a passion for engineering new products and creating new markets, turning ideas into reality, and transforming technology concepts into products. No time like the present - if you have a product idea and need help with engineering design, development, and/or product launch, contact TranformTec, Inc. for a free preliminary consultation.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment