Device driver template?

Have a look at .

I don't think you will find anything like what you seek. The top-side of the driver is dictated by the OS, HAL, etc. What one OS requires may not be at all what is required for another. E.g., some OS's have mechanisms to let you stress the drivers -- how will they behave in a system operating at or beyond capacity. Others might be more brittle.

Programming in the small you probably don't formalize lots of mechanisms (e.g., ioctl) that you would in "fleshier" OS's. Likewise, you might not need/want to design for a very flexible configuration -- you *know* what vdevices will be in your product (usually) so don't have to support probe(), attach(), etc.

Yes. Though it need not be -- if your OS/application don't care then your driver needn't!

Thanks for the link.

Thanks for the insight.

Hi, Peter. I'll add a brief, but hopefully helpful comment about the broader situation. It's conceptual.

You will get references to books and you've made your own above. You will get references to source code, too. But you already mentioned something that needs highlighting a little, as it brings to mind a foundation you may already know but I might as well call out explicitly, anyway.

Device drivers in embedded work are often broken into two parts, separated by a buffer between them. The part that deals with the hardware directly is often called the "low side," probably deals with interrupts in this day and age, and is responsible for either sending or receiving information from a specific bit of hardware. The buffer either acts as a source (playing music in the background, for example) or as a sink (incoming serial data from a host port, for example) for data whose timing is determined in ways _other_ than as is required by the larger application. The part that deals with the larger application is often called the "high side" and similarly accesses the shared buffer, but in this case is "driven by the application needs." The buffer serves as a way to pick up the slack between the application driven needs and the hardware driven needs.

In short, the asynchrony between application and hardware is served well by this split-in-half, buffered model, which has been around since well before I started programming 40 years ago and it will still be when I'm dead and buried.

The low side will be tailored to the hardware in question, of course. That is its job, after all. The high side will be tailored to the application requirements. That's its job. The buffer design just helps in the mediation.

Often, in porting, the high side design remains relatively intact, even though the hardware may change substantially. There is some machinery in the buffering that may require adjustment and, if so, then the high side will see some changes internally -- but not externally in its "contract" with the application. The low side and buffer data design is simply made to work. If the hardware changes a lot, the low side changes a lot. The data design may also require some change. (I usually _start_ by designing that data to fit the requirements, by the way.)

Of course, you may be one of those coding to some highly abstracted, virtualized .NET engine and not directly on embedded hardware and my comments are far less important then.

Jon

Hi Jon, Thank you very much for that comprehensive reply. I shall take it on-board! Cheers Peter