On Fri, Jul 27, 2012 at 5:04 PM, Peter Stuge <peter@xxxxxxxx> wrote: > 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. Me too. USB price / performance is very good for consumer market and that doesn't mean it is a good solution for all use cases as one can think about "universal bus". Rather "for all gadgets", not "for all use cases". > > Your application is clearly *not* a mass market application. So you > need to pay extra close attention to if this technology fits your > requirements. Sure. Completion reports by microframe boundaries is a non-obvious and not highlighted detail most important for my use case. > > >> 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. USB user can't know all implementation details not specified in spec. I ask experts here about the details. > > >> 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. 1. To transfer data from big buffer to pc. USB controller/Linux subsystem resolved the problem very good. [storm of applause] After a lot of problems with PCI7200 (digital IO card) I am happy, really. 2. To provide link to external bus adapter with 1 us delay and use the same USB link from first use case. Not possible with 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. "The FireWire host interface supports DMA and memory-mapped devices" very good > > >> 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. use cases rule over the world, not experts. > > > 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. Thanks, I got answer, 1 us delay is impossible with USB. > > > //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 -- 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
