Alexey Filin wrote: > So USB is not a "classic" bus and not universal, it is a network > with non-constant delay. Whatever "classic" bus means.. USB is a packet-based communications bus with well-defined timing characteristics. It is obviously not a local bus, as you know from PC architecture the USB is quite far away from the CPU. The USB spec is pretty clear about the motivation and design goals leading to USB. I for one think that USB is pretty darn good. It is certainly a success in the mass market. Your application is clearly *not* a mass market application. So you need to pay extra close attention to if this technology fits your requirements. > Are there USB controllers with the "synchronous transfers" reported > not on microframe boundary, so we can get response less 125 us? I very much doubt that there is. > Is there any USB2.0 spec extension declaring "synchronous transfers"? No. All USB communication has well-defined timing, and if the definitions can't meet your requirements then you simply have to use another technology, rather than complain about USB and try to bend it to fit your needs. You will probably not be successful, and if you are it will be completely uneconomical. :\ > USB is a good choice for some bus adapters, it is used widely, cheap, > simple. Do you think this may be related to how it was designed? I do. > For 2-byte read/write we could use either two bulk IN/OUT > endpoints (131 * 8kHz ~ 1 MHz) or one control endpoint (table 5-3, 42 > * 8 kHz = 336 kHz). If you can expand further on the details of your application then you will be able to get possibly unparalelled expert technical advice on this mailing list as to the feasibility of designing a solution that uses USB. > Ethernet is overkill for the task even if it could provide 1 us delay. If you require consumer interfaces and you want neither USB nor Ethernet then I guess there is only FireWire left to choose from. > Is it possible for USB Implementers Forum to add extension for > "synchronous transfers" to be handled asynchronously with microframe > boundaries? I think they may simply laugh in your face if you were to suggest it. You have not described your application in high detail, so it is not possible to say with confidence, but so far it seems that USB is just not the right technology for what you want to do. But provide more detail and I think you will also get more detailed replies. //Peter -- 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
