h a l f b a k e r yYeah, I wish it made more sense too.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
USB devices often need drivers from a separate driver disk. Too often the disk is misplaced, and when you need to plug the device into another PC, you haven't got drivers for it.
This is the solution: every device should have built into it a Flash or ROM chip with the drivers on it. Then, when you
plug it in, it's automatically configured.
This would require very minor modification to the USB software in the operating system (make sure it knows how and where to look for drivers), would be quite cheap (how expensive are tiny flash chips?), and would make "plug-and-play" a much more realistic term.
Two more great features: drivers for multiple operating systems can be included on one chip (including Linux and Mac); and, if it's a Flash (rewritable) chip, you can update the drivers as needed, and the updates will be applied to *any* computer you plug the device into, not just the one you installed the update in (since the updated drivers were written into the chip).
automatic driver download
http://www.halfbake...20driver_20download
More elegant solution to this problem by [egnor], requires little or no storage on the device itself. [krelnik, Oct 04 2004, last modified Oct 05 2004]
Jungo Ltd
http://www.jungo.com
Jungo develops a premier hardware access product line, featuring WinDriver - a software development toolkit that enables developers to quickly create custom device drivers that can run on a multitude of operating systems without modification. [jungo, Oct 04 2004, last modified Oct 05 2004]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
Indeed. The embedded driver that works today probably won't work tomorrow. And who needs another vector for virii? |
|
| |
Actually, this would be merged into the USB protocol. The protocol is software rather than hardware, so that's not hard, and ROM chips (for those that don't want another virus avenue) are VERY cheap. |
|
| |
The obsolete driver can easily be updated. That's why you might want Flash chips. |
|
| |
How about storing only a web link to the right driver on the device. That way, you can automically get the latest version, and the memory requirements are minimal. |
|
| |
...unless the website changes, or the company goes out of business (unlikely but possible), or you're not connected to the Internet (also unlikely, but also possible). |
|
| |
Modification: the mfr could publish a hash (md5sum) of the contents of the chip, and you could have a utility to check your device against it (to verify that nothing has been changed). As updates are released, updated checksums would be too. |
|
| |
I'm more in favour of the USB device supporting open standards, and developing those standards to support new devices. Sure something new and revolutionary will need a specific driver, but only temporarily. When its features become mainstream, they will get absorbed into generic USB support. Surely this is the point of USB. |
|
| |
"Actually, this would be merged into the USB protocol."
Which means what? If the device driver is embedded in ROM, it can't be updated and will fall out of date.
If the device driver is embedded in RAM/EEPROM the driver is subject to being overwritten with whatever code someone wants to put there. That scanner you bought at the hardware swap meet might bring your system to its knees.
You should include some virus protection or a way to flush the RAM/EEPROM in your idea. |
|
| |
Done. There's an md5sum (checksum) in an earlier comment of mine. Please read it and see if that would do it. |
|
| |
and what format would these drivers be in? and besides, a much better solution is the driverless approach. |
|
| |
we need more platform-independant protocols for how the user can interface with the device before something like this is ready for any real use. |
|
| |
I want it, or something that accomplishes the same task. Why do we still have to play with *@#! drivers at all? They are the bane of my existence. EE's / CO's, you have your marching orders. |
|
| |
Heh. So teaching grandma to check a hash of the contents of a chip and verify said hash against a published reference provided by the manufacturer is somehow easier than teaching her to install a driver from CD? |
|
| |
Nobody says Grandma has to know how to do it. The OS just says "Lemme check what you just plugged in to make sure it won't fry yer computer." It then checks the checksum for her, and tells her everything is fine (unless it's not). Nana only has to click OK 2 times. Simple, no? |
|
| |
Oh yeah, I do agree that driverless would be good. But until things get that way, let's make the most (easiest) of existing drivers. |
|
| |
// I don’t see any reason working against making device drivers work bidirectionally and being O/S independent. // |
|
| |
Don't worry, Microsoft will find a way ..... |
|
| |
Yeah, they would. I'm not hoping they get any kind of control over it. |
|
| |
I think this could be baked with at least one existing operating system (Windows XP). I’m not familiar enough with other OSs to know how well this solution would work for them. |
|
| |
Build the device to appear as a USB hub with a storage device and the real device attached. |
|
| |
When the device is first plugged in, the real device is hidden so only the storage device appears. The storage class is well defined, so the OS installs and configures it without needing any drivers and appears as a new disk on the system. Once the storage device is installed, the simulated hub simulates the insertion of the new device. When the OS goes looking for drivers it can find them on the new disk. |
|
| |
I’m not sure off the top of my head how the OS decides which drives to search for drivers. My guess is that there would be some flags that could be set on the storage device to make this happen (for example if it pretended that it was a CD drive or a floppy drive). That still might not make it completely automatic. Or maybe it could pretend to be a CD drive, and then simulate the insertion of a new disk, causing autorun to kick off the installation process. |
|
| |
Virus protection for drivers is basically implemented for Windows XP in the form of driver signing. Attempting to install an unsigned driver will pop up a warning message, though that message does not specifically mention viruses, just that the driver has not been verified to work with Windows XP. |
|
| |
Automatically updating the driver could be done with Windows Update. Of course to use driver signing and Windows update, the device must be certified by Windows Hardware Quality Labs. That wouldn’t be a problem for some companies that already do that, but there are plenty of other device makers who don’t want to jump through all of their hoops. |
|
| |
The driver update could include a coinstaller that would write the updated driver to the storage device if it had flash memory. Of course then the driver itself could actually viral. Update one device. Plug into a different machine. It updates the drivers on that machine. Plug a new device into that machine, and its drivers get updated, etc… Updating the driver on the device could also be bad because it is unfortunately not that uncommon for a company to release an updated driver that causes more bugs than it fixes. It might be better to always just have the original version of the driver on the device, which may not be quite as good as the latest, but should at least mostly work. |
|
| |
To support other OSs the storage device could have as many different versions of the driver as necessary. Even if the auto updating etc wasn’t baked for some OSs, as long as they support the standard storage class devices, this would fix the problem of loosing the installation disk. |
|
| |
Of course storing these drivers take a bit of space, leading to a rather expensive ROM/flash ROM. The chip to simulate the hub and storage device would probably be doable, but would take a bit of development. That makes this expensive unless it becomes very common, but it won’t be very common since it isn’t cheap. |
|
| |
Wow, sorry about the long annotation. Is this type of annotation appreciated or not? |
|
| |
I appreciate your thoughts, although I don't agree with all of them. As for expense, 1 megabyte (which would hold quite a bit in the way of drivers) is quite cheap. I can get 256 MB of CompactFlash for US$80. |
|
| |
To show how much I appreciate well intentioned and informative anno's such as scad mientist's - I'm awarding a croissant. |
|
| |
This is a good idea, but needs to be simplified a little. |
|
| |
Firstoff, I remeber when I started hearing about PNP, I acctually thought that it worked like this.. It's still a good idea. |
|
| |
To simplify; you could embed a generic driver. One that supports all basic functionality of the device, but with no chance of compatability issues (And in that case, it could be written semi cross-platform; eg working with all versions of windows and a seperate for all versions of linux, etc) |
|
| |
[JackandJohn], I wish everything worked with all versions of an OS. It doesn't, but I hope it will. |
|
| |
[RodsTiger], being a Linux user, I'm all for open-source software. Firmware is no exception. |
|
| |
[Rods] - "murder" of links? Ha! <sudden suspicious frown>Is that proprietary?</ssf> |
|
| |
More like an exulatation of links. |
|
| |
I believe a group of crows is called a murder. |
|
| |
//Where'd [Shz]'s anno go?// |
|
| |
I deleted it. It included something I thought potentially offensive to others. My deleted anno supported the idea of bi-directional O/S independent device driver loading, and this idea. Croissant remains affixed, as it has been. |
|
| |
[ galukalock ]; it would be possible if we could all agree on some legacy support in perpetuity.. (For example, you can use an AT-compatable non-winmodem driver from win3.11 in winxp if you get it past the logo verification)
This support would be much like XML is for data transfer; a set of rules independent of software or hardware. |
|
| |
[ misc ] A murder of crows, yes.. and I think a "Tangle" of links is more apt ;) |
|
| |
I've been trying to think of what to say to that. XML could be a good choice in itself; I'm not an expert on the USB protocol. |
|
| |
Since USB is here to stay for a while, yes, some legacy support will need to be built into the standard. Whatever the case, it'll need to be agreed on, all right. |
|
| |
The nice thing is that, as far as I can tell (and you seem to agree), it won't need for any new *hardware* to be installed on computers, but can be done with mere software configuration. |
|
| |
Wow. Are you sure that wasn't from a brochure? 'Cause it sold me. |
|
| |
This idea seems to be mutating (no bad thing). It seems to be moving from the idea of storing OS speific drivers to developing a cross-platform protocol that a USB device can use to inform its host of its capabilities. The first idea I dislike, whereas I'm in favour of the second. |
|
| |
Agreed, driver-less devices (or devices that only use the drivers everybody has) are much more acceptable than ones that ship with their own copies of proprietary drivers. This is pretty much what USB is for, anyway. Plug any USB mouse into any USB computer, and it will generally work, no drivers involved. |
|
| |
Of course, i still wish that PCs had the equivalent of USB Overdrive. |
|
| |
Have you heard of USB 2.0? Theoretical maximum transfer rate of 480 mbps. It's been out for close to a year. |
|
| |
[galukalock] //Have you heard of USB 2.0? Theoretical maximum transfer rate of 480 mbps.// |
|
| |
Ever heard of Firewire 800? |
|
| |
Ever hear of Gigabit Ethernet? |
|
| |
Nice Idea. Definately representative of the angst involved in dealing with inferior technological solutions. I know it's not realistic, and I know I'm going to get hammered but ... GET A MAC !!!.... |
|
| |
We are considering a Mac for a future computer. But even Macs sometimes (though I'm sure it's much rarer than with PC's) need a driver disk. This would quite nearly eliminate the driver disk problem. |
|
| |
Open Firmware may indeed prove to be the medium of choice for this. |
|
| |
[galukalock]"Yup. Ever hear of Gigabit Ethernet?" |
|
| |
Yup. Hasn't really taken off. |
|
| |
Ever hear of...this isn't going anywhere. |
|
| |
They're most of the way home by now. |
|
| |
Driver free PnP works with Windows 2000 and above.
Don't even think about ME! (It's an Inoperating System!) |
|
| |
I think the best way to promote this kind of system, is a 'passthough flash chip drive' |
|
| |
Just have 6 pins! 2 for datelines from pc, and 2 data lines towards the driver less chip. (the last 2 is for power) |
|
| |
What it does, is act as a normal pass though, but if the pins towards the driver is 'shorted' (e.g. button is pressed) for more than 1 sec, then it will mount its internal flashdrive ( 128meg, 256meg, 512 meg, and 1gig). |
|
| |
This will allow it to be hidden in all sorts of places, e.g. within the usb cable itself. |
|
| |
My Sony Ericsson X10 Mini already does this. When
you first plug it in it asks if you want to install driver
and apps. |
|
| |
Yup, I have a printer, 2 external HDDs, a camera and a 3G modem that all have software and drivers built in. They also go right ahead and look for updates via the interweb. |
|
| |
Though perhaps in 2003 this wasn't the case so [+] |
|
| |