What's a device driver.
-
Ok I googled the basics. Don't worry. But still I'm not getting it. That's the problem. Please see if I'm getting it right. First let me explain a situation without Device Driver: ANY device that wants to be controlled through PC has a firmware written on top of it(On the device side itself). The devices gives us the option to control through PORTS. like serial/USB. We can control these devices by knowing the f/w spec. If we know the firmware spec, we can send direct commands through a port application and communicate with device. For example, I create a RS232 application and ask the printer to do any job I want assuming I know it's firmware spec. Here no drivers are needed. With Driver: When do we need a driver? If we want any application to talk to the device. Right? So we get the firmware spec and implement all I/O in a common driver dll and we keep this port I/O implementation functions into the driver and the OS maps the application calls through this driver right? How does this work? Can I write my own device driver to control the mouse? Can you explain/give link to know the sequence? Please Don't give examples with driver frameworks. I want to know the underlying basics. Thanks in advance.
---------------------------- 286? WOWW!:-O
-
Ok I googled the basics. Don't worry. But still I'm not getting it. That's the problem. Please see if I'm getting it right. First let me explain a situation without Device Driver: ANY device that wants to be controlled through PC has a firmware written on top of it(On the device side itself). The devices gives us the option to control through PORTS. like serial/USB. We can control these devices by knowing the f/w spec. If we know the firmware spec, we can send direct commands through a port application and communicate with device. For example, I create a RS232 application and ask the printer to do any job I want assuming I know it's firmware spec. Here no drivers are needed. With Driver: When do we need a driver? If we want any application to talk to the device. Right? So we get the firmware spec and implement all I/O in a common driver dll and we keep this port I/O implementation functions into the driver and the OS maps the application calls through this driver right? How does this work? Can I write my own device driver to control the mouse? Can you explain/give link to know the sequence? Please Don't give examples with driver frameworks. I want to know the underlying basics. Thanks in advance.
---------------------------- 286? WOWW!:-O
without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports), and you implement all the peripheral-specific stuff yourself inside your app. That may solve the problem for one app using a (simple) peripheral one at a time. with a driver you can use peripherals that could be shared (e.g. your LAN) and where incoming data gets to the interested party, you can apply protocols that need to be implemented only once (e.g. TCP/IP), and you can easily isolate your apps' problems from the drivers' problems. Would you like to have each and every app on your system to fiddle with the sectors of your disk? :)
Luc Pattyn
:badger: :jig: :badger:
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
:jig: :badger: :jig:
-
without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports), and you implement all the peripheral-specific stuff yourself inside your app. That may solve the problem for one app using a (simple) peripheral one at a time. with a driver you can use peripherals that could be shared (e.g. your LAN) and where incoming data gets to the interested party, you can apply protocols that need to be implemented only once (e.g. TCP/IP), and you can easily isolate your apps' problems from the drivers' problems. Would you like to have each and every app on your system to fiddle with the sectors of your disk? :)
Luc Pattyn
:badger: :jig: :badger:
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
:jig: :badger: :jig:
Thanks for your reply.
Luc Pattyn wrote:
without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports),
So if we write to a port using CreateFile, will that be using Serial-Driver? The serial driver gets loaded when you connect some device in the port or it's running always? Also, does all hardware have the firmware on top for driver communication? Can any device without f/w be controlled by drivers alone? Let me get little more simpler. Assume I have motor running in a device. Now I need to write a driver that handles the RMP of it. I want to read/ control the RPM.. What are the sequence required? Lot more to ask actually. I will ask.
---------------------------- 286? WOWW!:-O
-
Thanks for your reply.
Luc Pattyn wrote:
without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports),
So if we write to a port using CreateFile, will that be using Serial-Driver? The serial driver gets loaded when you connect some device in the port or it's running always? Also, does all hardware have the firmware on top for driver communication? Can any device without f/w be controlled by drivers alone? Let me get little more simpler. Assume I have motor running in a device. Now I need to write a driver that handles the RMP of it. I want to read/ control the RPM.. What are the sequence required? Lot more to ask actually. I will ask.
---------------------------- 286? WOWW!:-O
_8086 wrote:
So if we write to a port using CreateFile, will that be using Serial-Driver?
yes. a serial driver, there could be more than one e.g. one for the standard serial ports based on 16550 device, one for a specific USB-to-serial cable, etc. And there could even be more than one stacked on top of each other. if by "device without firmware" you mean a dumb peripheral needing all its control from PC, that could be a bad idea; there was a time floppy drives had no intelligence, and interrupted the CPU for every byte transferred, that is once every 6 microseconds. You may remember Win98 with floppy activity didn't do anything else while a transfer was going on. IMO peripherals need sufficient intelligence so they can left alone for 1 millisecond or more; so don't consider a PC driving a stepper motor; use a microcontroller for that. Last advice: read some books and some articles on the subject. :)
Luc Pattyn
:badger: :jig: :badger:
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
:jig: :badger: :jig:
-
Ok I googled the basics. Don't worry. But still I'm not getting it. That's the problem. Please see if I'm getting it right. First let me explain a situation without Device Driver: ANY device that wants to be controlled through PC has a firmware written on top of it(On the device side itself). The devices gives us the option to control through PORTS. like serial/USB. We can control these devices by knowing the f/w spec. If we know the firmware spec, we can send direct commands through a port application and communicate with device. For example, I create a RS232 application and ask the printer to do any job I want assuming I know it's firmware spec. Here no drivers are needed. With Driver: When do we need a driver? If we want any application to talk to the device. Right? So we get the firmware spec and implement all I/O in a common driver dll and we keep this port I/O implementation functions into the driver and the OS maps the application calls through this driver right? How does this work? Can I write my own device driver to control the mouse? Can you explain/give link to know the sequence? Please Don't give examples with driver frameworks. I want to know the underlying basics. Thanks in advance.
---------------------------- 286? WOWW!:-O
Often, in general, when people talk about a "device driver", that's low-level code that writes and read directly with the hardware. It uses absolute addresses. In general, user code can't write/read absolute hardware locations. You would need a drive if you have custom hardware in your PC. That means if you make a PCI card with custom hardware, then a device driver needs to be written so that application-level programs can have access to the hardware. Think of it as a "delegate". :) The above is the "simple answer". :) But, wait, there's more! :) For something that goes on the USB or network, that gets more involved. There are many software/firmware/hardware levels in a Network/USB/Firewire transaction. So, we can quickly get into "terminology hell/confusion" when we start talking about "drivers". :sigh: I can argue what goes where in an application that uses TCP/IP over Ethernet. I can argue what goes where and why from the upper most GUI layer way down in the the core switching hub software. That's because of what I did in grad school and spent many many years in Networking. But, with USB/Firewire, the distinction between hardware/firmware/software is always changing. Yes, it is similar in the Networking world. But, for me, words like "Brouter" (bridge/router) don't scare me, since I was designing Brouters in the 90's. However, USB and Firewire are both very complicated! They are just as complicated as the TCP/IP flow. Maybe even more so since USB/Firewire now support so many different modes and hubs. My point is that writing a "driver" for a new custom USB device is not the same as writing a driver for a new video card. Yes, they are both called "drivers". But, the "driver" that is written for a new USB device will be calling a lower level driver that talks directly to the USB chip/hardware. I hope that last sentence makes sense. Again, it's due to the different layers involved in a Network transaction. It may help to think of them as a "Layer 3 driver", "Layer 4 driver", etc. So, a "driver" for a new USB device can easily be written in C# without the need to know any hardware details. Or, by knowing only a few higher level hardware details/limitations - like how fast the new device can take/send data if you don't want to overrun a buffer. Since I do embedded CPUs and FPGAs, I often write low level drivers that directly control the hardware. It often takes a very good unders
-
without a specific driver your app might be able to interact with a peripheral, provided the peripheral uses a hardware interface that is supported by some general-purpose driver (e.g. for serial ports), and you implement all the peripheral-specific stuff yourself inside your app. That may solve the problem for one app using a (simple) peripheral one at a time. with a driver you can use peripherals that could be shared (e.g. your LAN) and where incoming data gets to the interested party, you can apply protocols that need to be implemented only once (e.g. TCP/IP), and you can easily isolate your apps' problems from the drivers' problems. Would you like to have each and every app on your system to fiddle with the sectors of your disk? :)
Luc Pattyn
:badger: :jig: :badger:
Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.
:jig: :badger: :jig:
thanks so much for this information. things are more clear to me now.
-
Ok I googled the basics. Don't worry. But still I'm not getting it. That's the problem. Please see if I'm getting it right. First let me explain a situation without Device Driver: ANY device that wants to be controlled through PC has a firmware written on top of it(On the device side itself). The devices gives us the option to control through PORTS. like serial/USB. We can control these devices by knowing the f/w spec. If we know the firmware spec, we can send direct commands through a port application and communicate with device. For example, I create a RS232 application and ask the printer to do any job I want assuming I know it's firmware spec. Here no drivers are needed. With Driver: When do we need a driver? If we want any application to talk to the device. Right? So we get the firmware spec and implement all I/O in a common driver dll and we keep this port I/O implementation functions into the driver and the OS maps the application calls through this driver right? How does this work? Can I write my own device driver to control the mouse? Can you explain/give link to know the sequence? Please Don't give examples with driver frameworks. I want to know the underlying basics. Thanks in advance.
---------------------------- 286? WOWW!:-O
You've got some excellent answers here already, but let me add another that might help a bit. Back in the good old days when we didn't have to deal with Windows I did a lot of programming devices; specifically, measuring devices to test military hardware. There were no standards then, not as we know them today. The operating system was customized for every machine model, and already "knew" how to send bits over a serial link or HPIB bus. But the languages used had constructs like READ_VOLTS(DC, 100, AVG, 10) to return the measured DC volts on a line, up to 100 Vdc, averaged over a period of 10 milliseconds. But every oscilloscope, DMM, millivoltmeter, etc, recognized a different set of commands, unique to each manufacturer, and often each model. Usually these were in the form of text strings, and often the device listened for commands on a different physical address than the one used for data. For each device, we had to write a subprogram to translate what the operating system sent into a form the device could recognize. Today we'd call that subprogram a driver, and its job remains the same in the modern world. If you were to design a new programmable device, a toaster perhaps, it would have built in commands that Windows knows nothing about. You might have a syntax containing something like: ATDDSSSSHHMM# where AT = Attention (new command setting follows) DD = Darkness (1 - FF) SSSS = Active slots (0001 - 1111) HHMM = Start time (HH, hours; MM, minutes) # = execute command Your Toaster application program - the software your user runs to make toast - might output a command like: Toast (Medium, 2, 5:30AM) You would need to provide a driver to convert Medium to 80, 2 to 0011, and 5:30AM to 0530, then string them together into a command the toaster recognizes: AT8000110530#. On installation, your driver would register with Windows the addresses it listens to, and you would provide the port to which the physical toaster is connected. The driver would then ask Windows to send the commmand string it constructs using the assigned port when your program requests toast. Ideally, your driver would also notify Windows when the toast is done, so that the OS can tell your application program the status of the job. In the Windows world, devices are not physical things, but software entities called drivers. The driver software does the actual manipulation of real objects, which adds layers of confusion for users trying to play with Device Manager. :-D Writing drivers is a difficult job,