On 07/09/2013 05:01 AM, Joel Holdsworth wrote: > On 09/07/13 10:30, Alex G. wrote: >> Secondly, you lose the major strength of USB: separated pipes. A >> well designed USB protocol could be implemented in a week both >> firmware and software-wise. Do you want to end up with distinct >> transport-specific (FTDI FIFO, FX FIFO, usbserial) implementations >> of the same protocol in software? With a well-designed USB >> protocol, you can easily use the same software implementation on >> multiple hardware+firmware implementations. > > Peter: is this true? If so that would be amazing! I had envisioned the > need for a whole slew of protocol variants depending on the hardware > interface. > I am known for misspeaking, so I will try to elaborate on what I had originally meant.
I'll start with an example. It is possible for someone to take a Cortex-M with a high-speed USB PHY and implement fx2lafw, such that sigrok will believe it is a genuine FX2 logic analyzer. There are a few hurdles, however. First, I'd need to make sure that sigrok will not try to upload an fx2lafw image. I need to trick sigrok into believing I am an already initialized fx2lafw. Second, I would need to know what the control requests, such as setting the clock and divisor mean. For this, I need to have knowledge of how the FX2 operates. The problem here is that I need to have internal knowledge of how "that other hardware works" to be able to use its protocol on "this hardware". Now what would have happened if, instead of including FX2-specific messages, fx2lafw (protocol!) had included generic control requests such as "tell me how fast you can go" or "tell me what you can do", and "start probing at this frequency" or "only probe these pins" ? The fx2lafw firmware would take a frequency value, and internally compute the divisor and clock source. Then my firmware would be able to do the same _without_ knowledge of the FX2. It would only need to speak the protocol. Of course, the knee-jerk reaction is that this will complicate the protocol too much. On the other hand, when you look at the grand scheme of things, you have just one protocol, and just one sigrok driver for both these pieces of hardware. There is a lot less host code needed to control both these pieces. It doesn't complicate things; on the contrary, it simplifies life. How so? Well, you will need hardware-specific knowledge in the firmware. There is no way around that. So what you are doing with one well-thought protocol is eliminating the hardware-specific knowledge from the software. You are reducing complexity in software, while adding no more complexity to the firmware. Of course, this is conditioned on the firmware having the word in USB control requests. And this is where I might have spoken too hastily. I don't know just how much control, for example, an FTDI FIFO gives you, or whether it gives you the minimal control you need. It is possible to envision sub-drivers that would handle the minute differences, while keeping the bulk of the host code (pun definitely intended) identical, however, this would contradict everything I have just said. So in the end, it may as well be that an FTDI FIFO is not an appropriate solution for a smart USB protocol. On the other hand, there are a ton of equally or lesser priced alternatives that give the control you need, and as such, the smart protocol still makes perfect sense. I hope this clears up my obnoxious misspeak habit. Alex ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
