Most efficient way to pack U16 --> U32 Array for Data DMA Transfer?

[SeanDonner]

I have an RT controller that wants to send down data to an FPGA using DMA.  In LabVIEW 8.2, I have no choice but to pass down U32 blocks of data however my my input data is a U16 array.  This leaves me two choices:  1) Wire the U16 Array directly to the DMA node which will coarse it to U32 but I'm wasting 16bit*#of elements 2) Pack the U16 array into a U32 Array prior to sending it down.    I would like to do #2 and I have a method that works (and seems to be pretty efficient) but I have a feeling I am doing it the hard way (or roundabout way).   Is  their a simpler (but just as efficient) way to do this procedure?  Thanks

[SeanDonner]

[altenbach]

If byte order does not matter (and it probably doesn't), just use typecast as follows.

(You might want to tweak it if an odd number of elements is allowed for the input).

Message Edited by altenbach on 11-12-2008 12:20 PM

[SeanDonner]

Thats the kind of solution I was looking for but unfortunately I forgot to mention that byte order does matter and odd # of inputs are allowed.  I could always just check the array size and tack on x0000 if its odd, but I'm guessing the byte order deal pretty much kills this solution?  The only way I can make this byte order work is if I alter the FPGA code, and I'm very reluctant to do that due to compile times and also messing with code that works.  As a side note, I wouldn't have ever thought typecasting would what I want it to do, I was expecting it to just do what coercion does.

[altenbach · Accepted solution]

Here is a solution that pads for even elements and swaps the bytes. There are many ways to do this.

(for efficiency, you might want to place the "reshape array" inside a case structure so it only happens if needed)

Message Edited by altenbach on 11-12-2008 12:39 PM

[SeanDonner]

Thank you, this solution is about 3x faster than mine and a hellava lot easier to grok.  As a side note, the reshape array operation seems to be neglible so I'm going to leave the case structure out.  Reshape Array is another operation that surprised me as the buffer profile tool doesn't show an allocation dot on it (which is great!)

[altenbach]

---

SiegeX wrote:
... unfortunately I forgot to mention that byte order does matter and odd # of inputs are allowed.

---

See, that something that does not make full sense here, because you end up with a mixed byte order, because the 16bit halves are still big endian. What's at the "other" end, exactly?

Anyway, here's a slight simplification of the previous code. (The typecast is better if we can do it all big endian and omit the "decomate/interleave" dance.)

(You could also flatten to a string and back. This has the advantage that byte order is a direct option. I don't know how that is, performance wise.))

Message Edited by altenbach on 11-12-2008 04:31 PM

[SeanDonner]

Sorry, I did say "byte order" counts, what I meant to say was "word order" counts.  Here is whats on the other side on the FPGA.  This is a SubVI that gets called each time a 16bit word has been output and the DMA read in/out is looped via an external shift register.  

Oddly enough, although your newest version is a bit more simplified, it is marginally slower than using typecasting. I find this odd because there are 3 less buffer nodes with this new version with the removal of 'Interleave 1D Array'

 

[altenbach]

---

SiegeX wrote:

Sorry, I did say "byte order" counts, what I meant to say was "word order" counts.  Here is whats on the other side on the FPGA. 

---

But see, you can equally well send things in big endian (and simplify the code dramatically on the sending site)  and all you need to do is switch the output destination of the two outputs of "split number". It's probably worth it. 🙂

(sorry, I don't have any experience with FPGA, so I cannot juge the rest of your code). 🙂