On Fri, Jul 27, 2012 at 9:08 PM, Peter Stuge <peter@xxxxxxxx> wrote: >> 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. "control protocol and not simply raw data". There is a crate controller, the controller is equipped with control registers (2 or 4 byte width). The registers are used to send commands from pc to the controller. Controller can send commands to modules in the crate to read from/write to module registers. Crates are of types: CAMAC, VME, some custom-made crate systems. The first use case (transfer of buffered data with USB) is in the DAQ datapath. The second use case is for bus adapters. These are used to access crate controllers to test/debug/tune modules on- and off-line (as of data acquisition), ~1 us per r/w cycle is a requirement. There are a lot of modules with different registers and patterns of usage. For better comprehension I can send a tarball with my interface library (LGPLed) to access controllers independently of intermediate buses. > > >> > 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. hit. It is one of options studied by my colleagues already. >> 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. really -- 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
