Oh, the hackish method I was thinking was having two endpoints, both being mass storage devices. One of them would disconnect and reconnect each time the filesystem was changed. It would be a very slow interface, though. Also, I believe there are a few cross platform scripting languages that support USB (pyusb is the python/libusb version). You could develop the USB interface to work with python (serial, or a 'raw' usb interface such as bulk, etc), and if you still wanted a WWW experience, tunnel the communications through python (open a local port, and connect the browser to that). Still requires running software on the user's computer, though. Portable python interpretors are available, but I don't know whether libusb/pyusb would work without a native installation. But if you wanted to do it the hard way: Emulate a common, older USB ethernet chip (The Realtek 8150 might have generic drivers included in most OSs, for instance), and drop the TCP/IP stack on top of that along with a simple DHCP server and DNS server. Plug it into an OS, and have the user type, "mylocalneatdevice" into their browser, and they'll be attached to your server running on the chip. It just seems like a lot of work to avoid running custom software on the user's computer, and you are depending on a generic ethernet/usb driver already existing on the OS. But perhaps the benefits to this method outweigh the costs for the particular project you have in mind... -Adam On Mon, Oct 19, 2009 at 9:27 AM, M. Adam Davis wrote: > As David pointed out, once you plug the mass storage device in, the > computer expects the file system to remain static. > > I suspect that implementing a network driver that works across several > operating systems is going to be non-trivial, since the USB network > class is not nearly as well defined as the mass storage class. > > Unfortunately, I don't know of another easy method to make the device > accessable without OS specific drivers, which may be your goal. =A0At > least not another way that isn't terribly hackish. > > However, it's worth trying out, to see how each OS handles a mass > storage interface that changes. =A0Go ahead and make the MSD device, and > have a 'virtual' file on there. =A0The file contents will be derived > from, perhaps, an internal running counter, and will be fed to the > computer whenever it requests that particular block of information. > > See if reloading the file requests the data again. =A0There may also be > some settings in the USB mass storage class that force the computer to > not cache information (useful for security reasons). =A0You may also > have the option of setting up the cache timing - making it so it won't > delay file system writes, for instance. =A0Then you could use javascript > to change files on the device, which would allow a two-way mass file > system interface. (There is a USB wiki that does this - no need for a > server or software to edit files). > > Still, it seems like you'd run into endless issues trying to do this > in a way that would work on several different systems. > > Python and a serial endpoint seem to be a better solution... > > -Adam > > On Fri, Oct 16, 2009 at 10:37 PM, Harold Hallikainen > wrote: >> I'm wondering about combining the USB mass storage class and =A0the HTTP >> server in the Microchip TCP/IP stack. When someone plugs in a host >> computer, the MSD appears on their machine. Click on index.html, and >> you're at the user interface. Or, it could even include an autostart >> file to start the =A0browser. You could, of course, look at files and >> MAYBE even do GET cgi or MAYBE even POST. >> >> Possible? Bad idea? >> >> Thanks! >> >> Harold >> >> >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist