On 07/09/2013 06:58 PM, Iztok Jeras wrote: > 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. > You will love what I am proposing after I address your concerns :)
> [...] > 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. > FTDI chips are expensive, and it is possible to find alternatives that are cheaper. If cost is a strong constraint, you can use a cortex microcontroller (~$2) with an external USB HS PHY ($1.50) which will be a little less pricey than an FT232H. You might even be able to connect the PHY directly to the FPGA, and save an additional ~$2 on the BOM. Where FTDI shines is saving you money on firmware development. For this reason, they tend to be more expensive than alternatives that need firmware. The cost argument is not completely thought over if we just say "FTDI", or "Cortex", based on word of mouth. > > > 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. > This is actually not an uncommon misconception. This is one of the shining points of USB. A good API can very easily be implemented over USB. Conversely, a good USB protocol can easily be turned into an API. USB allows you to have an almost perfect 1:1 mapping between API calls and transactions on the wire. Consequently, the API and protocol are almost indistinguishable. This does not, however, turn a protocol into an API or vice-versa. > > > 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. > And I agree with your disagreement. On the host, you have a plethora of OSes, a plethora of API, and a plethora of wrong ways to go about doing what you wish to accomplish. On the device, you have one hardware, one interface, one toolchain, one library, one stack, and, therefore, only one of each to worry about. On the host, you have to worry about the hardware, OS, libraries, etc. Counter-intuitively, moving complexity into firmware has the potential to reduce overall difficulty. > > > 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. > Then this is exactly what makes them ill-suited as components in a USB device. They do too much "device", and too little "component". > [...] > 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. > I find your concerns to be perfectly valid. Although most stem from FUD about USB, It's hard to get a clear overall picture without dissecting each and every one in glorious detail, which I hope to have achieved. Let's return to the "API vs protocol" argument for a little bit, and why it is actually a protocol, not an API. You can have very dissimilar pieces of hardware being controlled by the same software commands. That's an API. You can have the same very dissimilar hardware controlled by the same wire transactions. That's a protocol. What I believe you really want to achieve, and what the name of this thread suggests is to have a common protocol (not API) for the hardware. In the end, what I am proposing, and what Peter was saying, is exactly what you wanted to achieve in the first place. Peter only said not not reinvent the wheel, but instead just get on the bus (pun definitely intended); it makes a much faster, safer, and comfortable journey. 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
