C / C++ / MFC

5-Mar-01 0:03

Hi,

anybody here who made experience in driver-development or knows good books, good links about the driver-model ...

Thanks ... Mario ///

----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------

l a u r e n5-Mar-01 2:41

l a u r e n

5-Mar-01 2:41

goto http://www.numega.com/drivercentral/driverstudio.shtml and skwizz thru some of the links there ... they have some samples and stuff ... prolly mostly to advertise their product but it might have other links from it

---
"every year we invent better idiot proof systems and every year they invent better idiots"

MickAB5-Mar-01 3:12

5-Mar-01 3:12

You don't say what windows platform you're developing for....

Just a few questions, then I may be able to help you.

Hardware:
Is it a new piece of hardware?
Off the shelf or in-house

Operating system:
XP/Win2k/NT4 or ME/98/95

Type of driver you are developing:
Kernel mode, user mode or both? (Or 'don't know'.)

If you are developing for NT based OS's, as far as books go, the 'classic' text is "The Windows NT Device Driver Book : A Guide for Programmers" by Art Baker, still relevant for Win2K, but a little dated now. (If you can get a cheap(==free) copy, it's worth having)
He has updated the book for Win2K, it's cunningly titled "The Windows 2000 Device Driver Book : A Guide for Programmers"
I have the first one, haven't got the latest one. The book is still useful, but if your a newbie, get the latest Win2K version.
You could also try "Windows NT Device Driver Development " by Peter Viscarola & W. Anthony Mason, another good book, which I also have. More up to date than the first Art Baker book, but published before Win2K was released.

The (first)Art Baker book is more of a "Device Driver Cookbook" then the Viscerola one.

Plenty of help is available in the DDK, (which is freee to download from MSDN now). But I recommend you get a book too.

Read the book reviews on Amazon.com, all three titles I have mentioned have been reviewed there.

(p.s. I also have another device driver book, but it's at home & I can't remember the title right now). Blush | :O

.::RockNix::.5-Mar-01 4:37

5-Mar-01 4:37

Ok,

I want to write the driver in the first way for win98 and maybe later for 2000. I can`t say anything about the mode you asked for. I have many experience with Win32-API but this driver stuff is totally new to me, so at first I have to learn the basics about the model.

Let me explain what we are trying to do, so maybe you can give some advice where to start.

Actually we are developing a midi-interface ( 19" - outside the pc ) which we want to configure and use via a pc. The configuration and midi-data transmission should go via rs232. So if someone uses a sequencer-soft like Cubase or whatever our external midi-device should have an entry in the output-device list and the app should sent the midi-data through the internal RS232 to our device.

I have heard about a book called PROGRAMMING THE WINDOWS DRIVER MODELL from MS-PRESS. Do you know this book ?

Greatings Mario ///

----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------

MickAB5-Mar-01 5:57

5-Mar-01 5:57

Ahh, much clearer.

First off, to read and write to the serial port under Windows 98 & 2000 is not too difficult, just use the relevant Win32 API calls.

(CreateFile() with the correct parameters to open the device, then take it from there. Plenty of info on sequential and overlapped IO, etc. in the MSDN)

It sounds like you actually want your driver to appear as some kind of generic midi device and internally route midi commands via the serial port? (Or am I barking up the wrong tree?)
I imagine this requires a bit of registry jiggery-pokery to have your app. appear in the driver list. Not sure if this is possible with a pure user-mode driver, I'm not that au-fait with the user-mode part of WDM under Win2k/98 yet.

My development advice is to get the serial port access down pat first, then migrate it to some kind of 'virtual device' driver later (No I *didn't* mean a VxD in case anyone reading this was about to flame me).

As for the different modes (user mode or kernel), the difference is that kernel mode drivers can use privileged processor instructions (IO read and writes for example) and can therefore access hardware directly. User mode drivers need to go via a kernel mode (or other user-mode) driver to access hardware.
There are other differences of course, but you need to read the books I mentioned in the first post for more detail.

The book you mentioned, nope, sorry but I haven't heard of it.

If I'm right about what I *think* your asking about (see comment above, 'barking up the wrong tree' Wink | ;)

) then the books I mentioned are not the ones you want right now. If you need info on serial communications under windows, use the MSDN.
Can't remember if there's anything on the topic in Petzold(not likely) or Richter(maybe).
Richter goes into overlapped and sequential IO and threading issues, but I'm not sure if he specifically looks at the serial port.

Hope this helps Cool | :cool:

.::RockNix::.5-Mar-01 21:29

5-Mar-01 21:29

>It sounds like you actually want your driver to appear as some kind of >generic midi device and internally route midi commands via the serial port? >(Or am I barking up the wrong tree?)

Hi Mick,

you are absolutly right. That`s the way it should go. The serial communication is no problem to me. My test-app I wrote for the hardware uses the serial port to configure and test the hardware and it works well. The point is how to re-route the midi-stream from a midi-application.

I know that must be possible. There is a tool out called TotalRecorder. This tool does the same I want but with audio-streams. It receives a wave-stream from another app, can write it to a file and send it THROUGH to the wave-device and it also appears as a kind of device-driver in the list.

But I see I have to read and learn a lot again before starting.

Ok, once again back to the books - Do I need different books for 98 and 2K to learn the basics or are there only special things that are different so I can use one book to learn the basics of the driver models of both OS ?

Thanks Mario ///

----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------

MickAB6-Mar-01 1:17

6-Mar-01 1:17

Hi Mario, glad you found my comments useful, let's see if I can be of any more help.

Now you've established that driving the hardware via the serial port using the API calls is ok, let's look at the next problem. So I need to ask some more questions.

First off, MIDI is not my forte, and I've never played around with any midi devices or applications, so bear with me.

The problem is you have a piece of hardware which hangs off of the serial port.
Q> Do you want to detect when the device is plugged in or removed?
(This implies some way of enabling Plug-and-Play for the serial port).
I think this would be nice to have, but not necessary to get the driver working.

Q> Do you need a MIDI application to 'see' the hardware on the serial port as a MIDI device?
(If yes, then it sounds like you want to write a 'layered' driver which sits between the MIDI device drivers and the serial port, rerouting MIDI commands to the serial port)

To answer your other question, for Win2K and 98/ME (and I assume XP), the most 'compatible' drivers are WDM drivers. (By compatible, I mean write-once, run on any WDM platform... in theory).

The book I mentioned yesterday (which I couldn't remember the title of) is "Writing Windows WDM Device Drivers" by Chris Cant. It's pitched at an accessible level, and contains some good information. It also explains some of the differences and similarities between 'classic' NT style drivers, Windows 95 style VxD drivers, and the new WDM stuff. It's also much more readable than any other device driver books I've read.

Whether it's 100% relevant to your current problem I can't say, (I only have three device driver books, which is not a large enough sample to give a good recommendation). But IMHO it's a good place to get the basics of the differences between the various driver types you can have on Windows platforms.

l8r

"The project spec. said 'customer *needs* to go to the top of the mountain'....nobody stopped to ask him why"

.::RockNix::.6-Mar-01 4:31

6-Mar-01 4:31

Hi Mick,

let me try to answer the questions clearly:

Q>> Do you want to detect when the device is plugged in or removed?
>>(This implies some way of enabling Plug-and-Play for the serial port).
>>I think this would be nice to have, but not necessary to get the driver >>working.

This is not necessary. I don`t see any advantage at the moment if we do so. But wait ... what about possible handshaking between hardware and ser-port. Could this cause a deadlock ? Maybe an app is sending midi-msg through the ser-device and the device waits for a handshake ? I`m not sure ...

Yes, I think we should keep the idea. We have several CPU`s in our hardware and it would not be to difficult to make them send an id-string back to the driver on request

>>Q> Do you need a MIDI application to 'see' the hardware on the serial port >>as a MIDI device?

Let me say some words about Cubase ( midi-sequencer-app ). Here you have for example 16 seperate tracks for midi-commands. For every track you can choose a different midi-out device if you have more than 1 device installed. So finally our driver should appear in this list, get the midi-commands from the track and send it via RS232.

>>(If yes, then it sounds like you want to write a 'layered' driver which >>sits between the MIDI device drivers and the serial port, rerouting MIDI >>commands to the serial port)

That`s it !

Thanks a lot ... Mario ///

P.S.: A LITTLE ENGLISH LESSON: I often read the "IMHO" - What does this mean ?

----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------

MickAB6-Mar-01 5:50

6-Mar-01 5:50

OK, back again. A word of warning, I'm giving these answers on-the-fly, some info might not be 100% correct.

>But wait ... what about possible handshaking between hardware and ser-port. Could this cause a deadlock ? >Maybe an app is sending midi-msg through the ser-device and the device waits for a handshake.

The handshaking is set up by configuring the serial port (either via the serial port property pages or programmatically).
You should 'capture' the serial port when your driver inserts itself. This won't necessarily deadlock the machine if your driver blows it's stack or something, but may require a reboot to release and reset the serial port.

As far as the MIDI stuff goes, what you actually are writing is a *MIDI driver*, which uses the serial port. So your drivers should be enumerated by the system as a MIDI device, and query your hardware to enumerate all the midi devices on the serial port. The actual serial port access is the *easy* part.
You should be able to drive the serial hardware from user mode, but test performance first. Besides which, if you write it correctly, you can develop the driver fully in user-mode, then try a kernel-mode implementation only if you can't get the best performance.
Another point to note is that the device driver may integrate better with windows not as a pure MIDI device, but as some type of DirectMedia driver.

OK, that's as much useful advice as I can give....

Abbreviations
IMHO In My Humble Opinion
IMO In My Opinion
AFAIK As Far As I Know

RTFM Read The F*****g Manual (Note, this is *not* necessarily insulting)
ROFL Rolls On Floor Laughing (Also ROFLMAO, MAO - My A** Off)
WTF What The F***

Look for 'MIDI' & 'serial' in the MSDN & DDK. (That's a 'RTFM' (!))

Are you in Germany? Italiano or Deutsche? (I'm in Munich);)

.::RockNix::.6-Mar-01 21:35

6-Mar-01 21:35

Hi Mick,

thank you very much for giving advice.

I think now I know how to start-up dealing with driver-development and learning the basics.

Mario ///

P.S.: In fact - I`m from Germany and now I also know how to decode the english abbreviations Smile | :)

Greatings Mario ///

----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------

MickAB6-Mar-01 23:42

6-Mar-01 23:42

Thanks for the thanks Blush | :O

Let me know how the project turns out. Big Grin | :-D

There are three types of people in this world, those who can do arithmetic and those who can't.

Joe Moldovan5-Mar-01 7:10

Joe Moldovan

5-Mar-01 7:10

I am certainly no expert having written only two simple parallel port drivers for 98 and NT but maybe I can give you a bit of advice.

1. Believe it or not, a Win98 driver is much harder to write than an NT (and I suppose 2000) driver. If 98 is not essential I wouldn't bother. In any case I would write for 2000 first and get the feel for how the driver works. Porting to 98 is easier after that.

2. Write a kernel mode driver. Although it's harder to write I think you will find that it gives you much better control and response. The fact that you are going to drive sound hardware almost mandates this.

3. You must understand re-entrant programming and especially clean and "dirty" (shared) data before you begin. The driver is written more or less as a set of parallel routines which are synchronised both by the kernel and by you. If you can write re-entrant code you are half way there.

4. Use a skeleton driver provided by the DDK or from the net. If you try to write it from scratch you will be releasing it for Windows 2010. The skeleton I used was very good and I didn't have to do very much to adapt it. I think you will find the same for the serial port.

5. You must develop using TWO PCs. Don't try to debug on a single machine. It's instant death and only an idiot (eg. myself) would try it. The DDK has tools for remote debugging and you should use these. Also, make sure that your target machine has absolutely nothing running on it. Clean all startup processes out even if you have to modify the registry. The less that's running the better you can debug the driver.

6. Do incremental development. Change one thing at a time. Remember that this is not a sequential process and lots of things are happening at the same time. Also remember that you are in kernel mode. You can kill the machine with a single keystroke.

7. Be extremely careful about memory allocation and deallocation for buffers and things. This is where you can get into real trouble. There are things which you can and cannot do in different parts of the driver.

8. Get two or three different books with lots of examples. I did this project a couple of years ago so the books I had are not relevant to you (and I had to leave them with my client) but I'm sure there is lots out there. Try to get one which uses a serial port driver as an example.

Although developing a driver is complicated it isn't as bad as it looks and it is fun when you get it to work. I hope this helps.

MickAB5-Mar-01 3:12