FrontPanel DLL released


A DLL interface to the FrontPanel API has been released. It is available in the Software Downloads section. The DLL Is currently in alpha as not all of it has been thoroughly tested.

Please let me know if this DLL suits (or doesn’t suit) your DLL needs. I’m particularly interested in how well LabVIEW gets along with it as we don’t use LabVIEW here.



I’ve already written the Delphi interface to this. Just one question - what is the calling convention used? There is a #define DLL_EP_PTR which indicates cdecl calling conventions, however, this doesn’t seem to be used anywhere.

Would it be a big deal to ask for the normal stdcall calling conventions to be applied to all the functions in the DLL? I suspect quite a few packages such as LabVIEW will expect stdcall conventions.

Would you like me to upload a copy of the Delphi interface when it’s finished and tested?

  • Niels



It seems that Windows defaults to __cdecl (I thought it defaulted to __stdcall). I’ll take a peek at this. The #defines there are used because the file may be used to support a Linux shared library. I’m not sure how useful that would be, though, since gcc is about the only compiler used on Linux.

I’ll update you on this as things progress. Thanks much for the comment!

And yes, I’d certainly post your Delphi interface on our “3rd party contributions” page or in the Software Downloads section.



Hi Niels-

The DLL has been modified to the __stdcall convention. As you suggest, this will be more usable for 3rd party software. Please check Software Downloads for the revised version as well as the DESTester app using the DLL.


Thanks Jake, that’s excellent. I’ve modified the Delphi libraries for the new calling conventions, and it mostly works. I am finding that the FPGA configuration quite often fails, is this a known issue? This happens with your FrontPanel application as well, not just with the dll.

Also, I’ve converted your test application to Delphi but I am finding that the okUsbFrontPanel_IsTriggered call is always returning false. What can I do to progress this further? Is there any debug info I can extract to help me?

A couple of comments.

The 16bit support enable function does not appear in the .h file - I don’t know if it is required or if the v2 libraries default to 16-bit mode, but it would be nice to have for completeness.

Also, would it be possible to have a version of the ConfigureFPGA function that takes the FPGA code from a memory array instead of a file? This would be useful if one wants to link the FPGA .bit file into the executable rather than having to distribute it in a separate file.

  • Niels



I have never had a problem configuring the device from a Windows machine. There have been off and on problems doing so from Linux, but these should be fixed. I’ll look into the “IsTriggered” issue.

For the 16-bit stuff, are you referring to “Has16BitHostInterface?” If so, I can add that as well. It was an oversight.

A memory-based ConfigureFPGA should not be a problem.



IsTriggered() works fine in the DESTester application. Make sure you’re passing a -mask- and not a bit number.


ConfigureFPGAFromMemory is now available as part of the DLL recently posted to Software Downloads. (It was already part of an internal base class used to build okCUsbFrontPanel – I just made it public).


Thanks Jake, speediest turn-round ever!

I just ran the FrontPanel app with the counter demo, configuring the FPGA 50 times and it failed 17 times… Not so good.

I am using a very fast PC here (Athlon-64/3500+ with XP Pro), could that have anything to do with it?

Is it possible to extract an error code to tell me/you the nature of the failure? I.e. is it the FPGA failing to come out of init, or what…

  • Niels


Hi Niels-

FPGA configuration is a pretty basic task, really, so there isn’t much to report. If the device is not actually configuring (LEDs don’t start counting), then the problem is that the FPGA DONE signal did not get asserted (by the FPGA) indicating a successful configuration.

Have you been able to try on another machine?


Hi Jake,

I’ve just tried this on my laptop (P4-1.4GHz/XP Pro) and my home desktop machine (Athlon-XP 2800+/Win2k). The laptop didn’t show a single instance of the FPGA failing to configure, and the desktop only showed it once (loading the counter bit file, the LEDs didn’t start to count) - this was not reproducible.

Experience (about 10 years of professional Xilinx use) tells me that if the config doesn’t work on a fast machine, it is usually because one of the more subtle configuration parameters is being violated.

(forgive me if I am teaching grannies to suck eggs here!) :slight_smile:

Are you waiting long enough after PROG_B goes high, if you are not monitoring the INIT_B pin (some circuits don’t).

Are you waiting long enough after the config has been clocked in, and before the start-up cycle? The datasheet doesn’t show this, but a short wait (100us or so) is often helpful.

If you are clocking CCLK faster than 66MHz, are you monitoring the BUSY pin?

  • Niels


Hi Niels-

Thanks for trying it on another machine. I’ll see what I can do to scrounge up a fast machine around here.

If I can get this somewhat repeatable here, I will have a look. Unfortunately, aside from the Linux problems I reported, I haven’t heard of any other similar situations. There was one group that had some mysterious problems with pipes flipping least-significant bits. After trying a couple machines, it seemed that a particular hardware configuration caused the glitch somehow. (especially curious since the configuration was fine)

The transfer clock and waiting periods are all machine independent as they are firmware-based. So, finding at least some machine dependence seems to indicate that those aren’t at fault.

I’m always open to folks finding bugs – I’m certainly not immune to them!



Just to close off this topic, there was a bug found in the configuration procedure that would cause it to fail on fast machines. This bug has been fixed as of FrontPanel 1.2.1.