Hi Alex,

You have indeed been able to explain yourself well. But I am not sure I like what you are proposing. Here are my reasons.
Do not take this comments as dressing your previous conversations, I do not know enough about USB to be able to follow.

On Wed, Jul 10, 2013 at 12:40 AM, Alex G. <mr.nuke.me@gmail.com> wrote:
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.

This adds complexity to the device. It requires hardware with a dedicated CPU and firmware. A CPU with programmable firmware is very convenient, but it might cost something extra, so very low cost devices might avoid it.

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.

A protocol as described by you is an API, and APIs need to evolve (there is no way to do it once and right) and adopt to changes in the environment.

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.

I do not agree complexity in hardware/firmware is the same as software complexity on the host. On the host you write code for various devices in more or less the same environment (C library, USB library). While firmware is written for very different environments (various development tools, vast documentation different for each device). At least I believe host environments are much more uniform then device environments.

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.

I only checked 2 devices but it seems FTDI chips do not have user programmable firmware. Except for Vinculum-II devices which have a noname CPU (16bit Harvard architecture).

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.

I tend to overreact in some arguments. Do not bother with mostly negative answers in this reply, I would be glad to follow your lead, especially on anything USB related.


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