LabVIEW FPGA Advanced Interface Tools Discussion

[Tobias Gilbert]

Oh I guess it is also a FXP problem. So an integer cast will solve it... 🙂

[griffindore]

Yes, FXP isn't supported by this tool because of lack of support in the C API. An integer cast to/from on either side will allow you to work around it.

[Pie566942.0]

I've just studied this seriously for the first time since you showed it to me a few years ago. If I didn't express my admiration for your work at the time, then let me say now, this is freaking sweet.  Thanks for putting it together.  I’ve been challenged for the past few days trying to architect a reusable DMA logging daemon.  After serious consideration, I think your tool is the only way to get it done correctly.

Regardless of the data source, the framework for streaming to disk is mostly the same.  When the data source is an FPGA DMA FIFO, I need a way to decouple the logging framework from the FPGA VI refnum if the daemon is going to be reusable (Save As… doesn’t count as reusable).

My first thought was to launch two processes, one to peek the DMA FIFO and poke it onto a Q, the other to peek the queue and log to disk.  While this is completely data source agnostic, I don’t like it because I'd have two processes to manage per FIFO.  What (I think) your code will let me do is peek FIFOs by bitfile\name.  That would be…amazing.  Does anyone have thoughts on how to design a DMA FIFO logging daemon in a single process decoupled from any particular FPGA VI refnum without using this tool?

One question for the developer: do you know what would be required for the tool to support execution on the development computer (simulation)?

-Steve

[Pie566942.0]

I just put this tool to another amazing use: an FPGA debug interface.  Rather than using the standard Read/Write control in my host to look at every single register (many of which exist for debugging), I now peek at debug registers by name.  It's saved me so much time and is much more intuitive than the standard interface.  NI must consider productizing this tool.

-Steve

[StephenB]

Hey Steve,

Glad to hear that.

Yes it is being considered heavily. Lots of stuff going on about it... just trying to find the right design and the right time.

Did you try this in 2012? I heard it broke but I haven't tried it yet. Its on the todo list.

[David_Staab]

StephenB wrote:

Did you try this in 2012? I heard it broke but I haven't tried it yet. Its on the todo list.

Woah...I just downloaded this and queued it up to use in a project that will likely be migrated to LV 2012 soon. Has anyone tried it in 2012 on a cRIO or sbRIO? I'd love to hear confirmation that it'll work before going through the effort of migration.

[Pie566942.0]

Hi Stephen,

Something about the mil-aero industry doesn't like to live on the bleeding edge of software.  My work so far has been in 2011 SP1.

Best,

Steve

[StephenB]

David_Staab wrote:

StephenB wrote:

Did you try this in 2012? I heard it broke but I haven't tried it yet. Its on the todo list.

Woah...I just downloaded this and queued it up to use in a project that will likely be migrated to LV 2012 soon. Has anyone tried it in 2012 on a cRIO or sbRIO? I'd love to hear confirmation that it'll work before going through the effort of migration.

It will work... I've heard that it has been wounded but not fatal

Aka... some stuff moved around inside the LabVIEW dir that needs to get fixed up in our wrappers.

[StephenB]

Pie566942.0 wrote:

Hi Stephen,

Something about the mil-aero industry doesn't like to live on the bleeding edge of software.  My work so far has been in 2011 SP1.

Best,

Steve

Same reason I don't have 2012 installed yet

[David_Staab]

StephenB wrote:

Aka... some stuff moved around inside the LabVIEW dir that needs to get fixed up in our wrappers.

What's that mean? Which features are broken? What happens if I start in 2011 and upgrade to 2012?