DMA FIFO - how do I get the value of "Number of Elements Per Write" inside FPGA application

[Thomas444]

I set the value of "Number of Elements Per Write" in Properties of DMA FIFO with respect to number of sensors connected to my cRIO. The value can be set in powers of two: 1, 2, 4 up to 32. The thing is that I when I change how many elements I "write during one write", I need the RT app to respond to it automatically and correctly, but I haven't found any way to get this value programatically inside the FPGA program. Now I must change this property in LV project and also in a constant in FPGA program. Is there any way to read that property programatically?

The only solution I can think of is to set up bunch of DMA FIFOs, each with different Number of elements per write, and use only one in a single application, but I think this is so bad in so many ways! (Compilation time is the biggest concern.)

Not to be confused with "Get Number of Elements to Write".

Thomas

[Intaris]

FP Control with the value in it?

Why do you need to automatically detect this? Sounds like a choice of protocol, not an on-the-fly change.

[Thomas444]

I don't mean changing it on the fly, I mean between devices. We ship compactRIOs to our customers, each with specific combination of modules and therefore specific FIFO size, for which FPGA must be compiled. Other parameters like sampling frequency of accelerometer module can be retrieved in FPGA code and RT app can read this information so I don't have to specify it anywhere else. I want the same thing with number of FIFO elements per write.

I can also make a front panel indicator, to which a constant is connected, but there is often a mistake as I am often switching between multiple targets, that I forget to change the value in the code or in FIFO properties and after 30m compilation I see the data is messed. You know, two sources of the same information, system depends on both - that is inconvenient. If it can't be retrieved, then I don't know what approach to use in order to get around this issue.

[Intaris]

Well, you might not like my solution.

Due to problems like this (take my most common example of read latency of a BRAM IO node) I have started wrapping a LOT of such "primitives" in Objects and swapping them out in my code (utilising Dynamic Dispatch).  This way you can instantiate a DMA Write object with 1,2,4,8,16 and 32 items per write and as part of the object simply return that value. Wire up the object method to a FP control and voila, you never have inconsistencies again between the two.

It seems very heavy handed at first, but I've grown to love this approach.

[Thomas444]

There is bunch of phrases in your answer I am unfamiliar with, which means there's bunch of things to discover for me in this field. Thank you very much. 😉

[Intaris]

No Problem.

If you want some help with any of the terms, let me know. I learned most of what I know about LabVIEW on these forums. I'm happy to be able to help.

Shane.