Alexey Filin wrote: > >> 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. Well, ok.. > 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. :( You didn't expand on the details, as I asked for, so I can't really comment much more. The point I would like to understand better is why you require 1µs turnaround. Perhaps that is actually not neccessary, and a solution could be created which still meets your application's requirements. But for someone (on the list) to help, you'll need to explain more about what is going on. So far we know that there are two bytes being transfered. The first byte is input, the second byte I don't think we know the direction of. We also don't know *what* the bytes are. Maybe they are some kind of control protocol and not simply raw data. That would be relevant for making a USB solution that works. > > 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 I'm not so sure about that. You will obviously have to carefully study that technology too, to see if it can meet your requirements. Some other ideas might be to build SFP slots into your endpoints and use some plastic fiber off-the-shelf SFPs. > >> 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. It's not about experts, but about money. :) It needs to be a big use case for USB-IF to generate a host controller extension. I'm not even sure that they are too active in the HCI standardization process at all. > I got answer, 1 us delay is impossible with USB. Yeah, this is old news. The question is if your application really needs that, or if some properties of USB and/or other interconnects actually mean that you have less strict latency requirements. //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
