Future of device drivers and ways to program them?

Discuss all aspects of programming here.

Moderator: The Mod Squad

Future of device drivers and ways to program them?

Postby atang1 » Tue Oct 26, 2004 10:12 am

Universal drivers are coming. It just means modules will be compiled.

But Microsoft has to hire 100 or more hardware and software engineers to use drivers to explore faster data transfer rates? Drivers are embedded software to make devices function. some drivers are stored in flash or eproms. Most drivers are store in drams in the computers.

However, the embedded software can be used in sound chip(audio frequency for analog signals) or DSP(analog and digital signal conversion).

So, the improvement is expected in frequency conversion. Using lower frequency as carrier, then higher frequency pulse width modulation to transfer data faster.

For instance, dialup modems can used the natural frequency capability of the repeaters in POTS(plain old telephone system), which has bandwidth of 150,000 hz. This could improve v0.92 transfer speed three times on bandwidth alone. The peak response compression schema can improve further.

Convergence of technology can often astonish even the most conservative principle engineer. Software programming to change the hardware frequency or modulation can be interesting. But some one has to invest some money to make it come true.
Last edited by atang1 on Wed Nov 10, 2004 4:07 pm, edited 2 times in total.

Postby netaces2k » Tue Nov 09, 2004 2:59 pm

NVidia is currently using their own 'native' unified driver architecture (uda). I see Microsoft doing this, only to be a Joey come lately and be on the 'band wagon'.

A universial driver is possible. And has little to do with the actual speed of the hardware. What they are talking about is the ability of the chipset in the hardware to use compression like the modems do (i.e. MNP-5) to compact the data and send more packets full of data in a shorter time period.

This is nothing new. It's been done for years. And they finally just decided this?... *sighs in disbelief...*

For example the AGP bus is limited to 2.1gbps... The 'supposedly' new bus AGP 3.1 or 4.0 (PCI Express) is nothing more than an AGP 3.0 with MNP-5... The bus rates haven't even yet tapped the 128-bit or 256-bit level of the core chipsets yet. Heck. They aren't even on the 64-bit band wagon yet. Except for the CPU's (AmD Athlon 64)...

Again this is nothing more than a financial ploy to make Dr. Bill 2x richer than he is now, by exploiting the gullibility of the masses.

I'm not impressed at all.

Postby atang1 » Wed Nov 10, 2004 4:21 pm

Thanks for your response.

Universal drivers for devices, first of all, is to improve on the device performance. So, modules have to be written to alter the data transfer modes or rates. Most devices used sound chipset or DSP, analog to digital conversion or digital to analog conversion. So these device can be reprogrammed to work the circuit by embedded functions(firmware change). X2 and Kfles merged into v0.90 modem by firmware change. Anything spill over the firmware can be stored in the dram from the driver.

Then lists of modues and sequences has to be programmed by scripts.

Families of devices can all use the same script except some devices will have more functions, others less functions. This has to be in the PNPOS(4 didit code) data, so that scripts can delete the extra functions in the compiled driver. Hopefully resulting in tighter codes on all drivers.

When PNPOS reads a device code, a driver is compiled from a list of modules(machine language programs), each one only does one function. A script is fetched that fits the device PNP codes then compiles all the modules into a driver.

Thus it is universal driver for any device, but specific when the driver is compiled for a specific device. Many modules can be shared across the cpu functions, the HDD functions, the dram functions, the USB bus hub functions, etc. These mentioned functions are in the kernel. Static or native drivers are not universal.

This concept is not new. But to do it efficiently and prefetch efficiently requires a certain principle or philosophy. Which is how to group the functions to be stored in the dram to be used currently then prefetch others to execute the device later.

More to come later.

Return to Programming

Who is online

Users browsing this forum: No registered users and 1 guest