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. <[email protected]> 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.
>
> 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
>
------------------------------------------------------------------------------
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
