A situation that freezes FrontPanel

FrontPanel
21

As I mentioned to Fabrizio, I have not gotten to the point in my application where I am investigating why my application hangs… as it does not do it very often… when I get to that point I will let you know what I find… currently I use GetDeviceCount to check if the device is there, before attempting a transmission. I checked to see how I could get ahold of the WM_DEVICECHANGE message, but it doesn’t seem to be present in any of my classes… an example would be much appreciated… perhaps it is something only provided in DDK? which I don’t have right now… Windows…

However, it looks that even if I get a WM_DEVICECHANGE, if the device driver locked up, there would be nothing to be done anyway, short of launching every device communication in it’s own thread, which can be shut down when the device fails…

Unfortunately I do not have access to your code. Thus I rely on you to produce a high quality product. It disturbs me, and makes me cringe, when I hear you say " the “right way” is often much more complicated than the simple examples provided" and “We avoided this complexity in our samples” and “for some programmers this is simply too complicated to follow” and “Done right, the PipeTest sample would include multi-threaded access” and “it’s more Microsoft’s charge to show examples of good OS programming”. No, this sounds like excuses to me. I believe there is room for showing simplified codeing methods, but I also believe you have a responsibility to teach and show the “right way” also.

To some of us this is not “toy programming”, it’s the real deal. So I would like to request that you give/make available the “Adult” version of the libraries for which we have no source code, provide full details concerning all the routines, including what they return, and create some meaningful, solid, “done right” examples…

I want to see a robust 20MB/s pipe in / out example based on the isochronous endpoint… that can handle down to 0 size packets when the fifo goes empty… and won’t hang when the power turns off… something that will truely report how many REAL bytes are transmitted (that won’t go and get bytes that arn’t there), something that returns ERROR CODES… and yes, passes down the WM_DEVICECHANGE, and perhaps handles the device threads for me, so I don’t have to go there myself… This is the sample I want to see… pipetest on steroids perhaps… use counters with different clock rates to demonstrate handling of fifo-full and fifo empty, without having the extra wire out with the data waiting count… and all the above features…

Oh, and don’t use types like std::strings, use char, it makes doing things easier when you are library limited, like in win32 DLL’s… and speaking of DLL’s can you tell me what type you are using?

Thanks…

22

Hi Bill-

I’m sorry you’re frustrated with our product.

We provide what we think is a nice product at a very low price point. At the moment, we’re not aware of any competing device that offers a full-blown API to communicate with the device as easily as we have assembled. Our nearest competitor with something even remotely close is priced 2x above ours.

There are a lot of components that need to come together for a successful design. These include the proper design, board layout, firmware code, application code, FPGA HDLs, and so on.

We made a decision to provide an FPGA/PC communication link that we think fits the bill for most people most of the time. Of course it doesn’t solve everything. (for example, we do not support isochronous transfers – only a small fraction of the USB device types out there rely on them – primarily audio capture and webcams)

Additionally, we offer design consulting and contracting for those that can use the help getting their application off the ground. If you’re interested in pursuing this option, please let us know.

P.S. The WM_DEVICECHANGE handling is, indeed, part of the DDK. I believe the DDK is available for free from Microsoft, but I’m not sure. We pay lots of money for our MSDN subscription and it’s just “there”. Linux uses a hotplug interface which varies depending on distribution. Mac OS X uses something similar to Linux, though better specified.

23

Hi Jake?

I would like to say that I like your board… I was going to build one myself until I saw your board advertised on the USB.org website… As my boss said… we couldn’t build that board in the low quantities we currently need, for that price… And hardware-wise I have been very happy with it…

The support software needs a little work.

So here I am trying to prod you guys into delivering a better product that will meet more peoples needs… I don’t really want to go “re-invent the wheel”, I’d rather have an OTS solution that I can plug into the systems I create, and not have to worry about the underlying hardware and software, because I know it will work and it has been well tested. I would believe you want that too…

I also don’t buy your line that none of your customers are interested in Isochronous Streaming Transfers… Why would someone buy a board with an FX2, and a Spartan 3?

So I’ll bite… how much $$$ to fix your code?

-Bill

24

Bill-

You use the term “fix” our code. Can you explain what is wrong with it? If you’re asking for isochronous support to a custom version of firmware, then please email us. We do not quote such things in our public forum.

There simply has not been enough interest in isochronous mode to justify the cost of developing that functionality. Most folks that have asked for isochronous or interrupt transfer modes did not initially understand them. After explaining them, they recognize that the pipe in / pipe out functionality (bulk transfers) is exactly what they want.

To elaborate on this, there are hundreds of reasons to buy an FX2 / Spartan-3 board. Many don’t even include the need to communicate pipe data. Wire and Triggers are perfectly adequate. Pipes add a convenient synchronous transfer for bulk data such as memory contents, code, etc.

From Don Anderson’s “Universal Serial Bus System Architecture”: “Isochronous data delivery is characterized by the need to provide data on a timely basis and is more important than verifying accurate delivery of data. For this reason valid data delivery is not guaranteed during isochronous transfers.” For many applications, integrity of the data is an absolute requirement. For toys like webcams and some audio capture, it isn’t. Additionally, “since a constant data transfer rate is essential for isochronous applications, error detection and recovery are not supported.”

Can you give me details about your application and why the bulk modes are inadequate? This sort of feedback is always useful to direct future development. We have never said we will not support iso. modes, just that there hasn’t been enough genuine interest to do so. If we did, it would likely be at a price premium. What would you be willing to pay?

25

Send me a quote at my email address…

And I do mean fixed code…

Bill

26

Bill-

An email has been sent.

For the benefit of other users on this forum, could you please explain what aspect of our code is broken? We do not (and have not) advertised support for isochronous mode.

27

Hello Jake,

This is what I request:

  1. Rewrite library such that it more resembles a device library. In general,
    a) all functions will return errors which can be looked up via ERNO or equivalent.
    b) all routines will be written in such a way that theycan be used either in blocked or un-blocked mode.
    c) all relevant routines which could potentially lockup, utilize a user supplied timeout value.

  2. Simplify input and output arguments by removing std::strings in favor of the simpler and more universal char], thus allowing use of straight win32 dll’s.

  3. Provide complete function documentation, including all possible return values and arguments, and any error codes with possible causes.

  4. Fix known bugs:
    a) ReadFromPipeOut will return either exactly the number of bytes requested or exactly the number of bytes present. It will not return bytes that are not there… this will require modification on the FX2 side to allow for new data detection, such as an okPipeOut ep_write signal.
    b) Identify and fix the application lockup bug, probably resolved by 1c).

  5. Implement sustained high data rate pipe performance with flow control. This can use either Isochronous or Bulk Endpoints, as long as it can handle data rates down to zero, and upto 15MBytes/sec, minimum, without flow induced data error other than FIFO overflows due to higher than 15MBytes/sec bursts. Isochronous is probably prefereable due to the ability to transmit zero length packets in underflow situations, however Bulk is acceptible.

  6. Include methods to access the WM_DEVICECHANGE device message reliably for windows.

Note: I find it very attractive that you are supporting Linux, I will likely be making use of that in my next project, so do not do anything that will affect compatibility. In fact the new pipe performance must be maintained in the Linux environment.

Note: Can you allow back-ordering when purchasing with my company so that the ladies in our purchasing department don’t get all worked up about things?

I think this is everything…

Bill

PS:

Additionally, while you did not ever promise to provide isochronous transfers, (I’m just suggesting it as a workaround), you did say to me in the very begining that you could provide certain sustained data transfer rates, which are not possible with the present workaround for the okPipeOut and okBufferedPipeOut underflow problem. In fact you never told me about the underflow problem, it was just kind of hidden by the example used…

28

Hi Bill-

Thanks for the suggestions.

Regarding #2, we already provide a Windows DLL which uses char] access. In fact, we suggest folks use the DLL rather than the library. Eventually, we will no longer support the library and instead only support DLL usage.

Regarding #3, have you looked at the API documentation? It is available online and has been installed with FrontPanel as a “compiled HTML” document. It shows all functions, arguments, and return values. If there are any omissions, please let us know.

4a - Pipes, by design, do not know how many bytes are present. There is no handshaking mechanism. Please refer to the FrontPanel User’s Manual (pp 27-28) for documentation on the HDL modules okPipeIn and okPipeOut. Basically, when a word is requested, it must be provided. It is left to the designer to further abstract this into a handshaking mechanism as required. We (and others) have done so using buffers, FIFOs, wires, triggers, other pipes, and so on. The implementation strongly depends on the objectives required for throughput, latency, and other parameters.

4b - We have been unable to reproduce this problem, but are still working on it.

Points 1/5 have been noted as possible improvements to our API. In the interest of not leading you on, it is unlikely we will support isochronous mode anytime soon.

Regarding your postscript, we have never made any claims on sustained transfer rates. In our own designs, we have achieved sustained transfer rates of 20-30 MB/s, but we do not make any guarantees because they depend highly on the computer load, other software running, other USB devices attached, and hardware/software implementation.

On this point, I would like to be very clear because we do not intend to play the marketing game and would like to fix any documents that appear to mislead. We have achieved these sustained rates, but we do not guarantee them. In fact, the words “sustain/sustained” do not appear in any of our documentation or website. Within the forums, the only post I could find on the subject was this one:

http://forums.opalkelly.com/showthread.php?p=37

Also, both okPipeIn and okPipeOut are master interfaces. They is, they request a READ or a WRITE and require a particular response. They also have no input to inform them when an underflow or overflow condition exists in your hardware, so it should be clear that these two interfaces do not provide handshaking.

In the okBufferedPipeIn and okBufferedPipeOut documentation, the following line is present: “Some negotiation will be required between the host, buffered pipe, and user design to assure that FIFO overruns and underruns do not occur. This would typically be done with wires or triggers to indicate to the host when the FIFO can accept additional data.”