> > Correct, but unfortunately, the parallel port is a dying species. Just > > out of curiosity: would such semi-accurate timing be at all possible > > with USB, or is that already excluded by the spec itself? > How accurate do you mean? It depends on what signals you want to > regulate. What this guy basically did was to generate an SPI signal out of USB reset pulses. For the clock line, a single port is sufficient; for the data line, he used a flipflop and two ports. To get rid of even that single flipflop, it would be necessary to generate reset pulses on two ports so that the (rising or falling) edge of one pulse reliably overlaps the 0 state of the pulse on the second port. > It is not safe to reset multiple devices on the same bus at the same > time. The Linux hub driver won't allow you to reset multiple devices > at the same time even if they aren't on the same bus, although that > could be changed. > Therefore to do this at all, you would have to unbind your hub(s) from > the hub driver and send commands to them via usbfs or libusb. The > timing could be regulated to a precision of about a millisecond. I think that's more or less what he already did. So a hub should properly handle two reset commands sent in direct succession? Florian PS. Disclaimer: I know this is really getting a bit off-topic, but I think it would really be pretty neat to be able to bootstrap a microcontroller with nothing but three USB cables and some resistors. -- 0666 - Filemode of the Beast -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
