On 07/09/2013 05:01 AM, Joel Holdsworth wrote:I am known for misspeaking, so I will try to elaborate on what I had
> 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
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
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
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
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.
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!
sigrok-devel mailing list