LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Typecast byte array to fixed point

To start with, this isn't a "how to" question.  There are several options to do this, and I've already picked (and implemented) one of those options.  Instead, this question is "Hey, I tried something and it didn't work at all. What's going on under the hood in LabVIEW?"

 

So, I've got a widget that is a bit older and uses 12-bit integers on it's end. That data stream is converted into a byte array by the time it gets to me in LabVIEW, so I need to convert the byte array into an array of integers, splitting every other byte along the 4-bit boundary. My first impulse (and ultimately what I did) was to just use the data manipulation functions and move on with my life.

 

But then I thought "hey, I bet I could typecast my byte array into a 12bit fixed point array".  So I tested it.  Not only did it not work, the typecast spit out an empty array.

 

BowenM_1-1620171074220.png

 

Anyway, my experience with using fixed points has been FPGA stuff, and pretty limited at that. Anyone want to shed some light on what's happening here?

 

0 Kudos
Message 1 of 8
(188 Views)

Well, fixed-point does not mean integers.  It means it's the equivalent of a floating point or DBL/SGL number, but instead of the point being... floating... it stays in the same spot. 

 

It's not an integer, it's just a less flexible data type, but it is used in FPGA because it takes up much less space on the grid to do a fixed-point math operation compared to a floating point one.

 

So since it's not an integer, it could never work in the first place....

0 Kudos
Message 2 of 8
(178 Views)

@Kyle97330 wrote:

Well, fixed-point does not mean integers.  It means it's the equivalent of a floating point or DBL/SGL number, but instead of the point being... floating... it stays in the same spot. 

 

It's not an integer, it's just a less flexible data type, but it is used in FPGA because it takes up much less space on the grid to do a fixed-point math operation compared to a floating point one.

 

So since it's not an integer, it could never work in the first place....


Gonna have to respectfully disagree with you there. 

 

If you configure your fixed point such that the integer word length is equal to the word length, you are allocating zero bits of your 12bits to decimal position. 

 

BowenM_0-1620171815922.png

 

 

And, even if that was the case it wouldn't explain why LabVIEW returned an empty array.

 

0 Kudos
Message 3 of 8
(167 Views)

One problem with LabVIEW’s typecast, is that it isn’t really like a C typecast. In LabVIEW’s implementation you don’t change the type you actually make a data copy. Because it is not an in place type swap, LabVIEW may have some problems for non standard data like fixed point.

 

mcduff

Message 4 of 8
(148 Views)

Also keep in mind that your 12-bit fixed-point value is actually stored in a 16-bit register.  Though, I'm not sure why an empty array was the result from your type cast unless it was because you got an invalid value for a 12-bit value (upper 4 bits had at least a 1).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 8
(121 Views)

There is a specific function to convert to a fixed point number. It does not accept arrays, but easy enough to wrap it in a for loop.

 

Fixed Point Type Cast.png

0 Kudos
Message 6 of 8
(113 Views)

Thanks for the response StevenD,

 

...but... I mentioned I already had a solution to the problem that I was happy with. That isn't my question.  (also, your solution doesn't solve the problem because it won't split the byte stream into 12 bit chunks - it's converting a u8 integer into fixed point)

 

Really my question is what's going on under the hood with the first typecast.  I'm interested in why it would return an empty array... I would have at least expected a return of some values, even if it wasn't in the format I wanted.  Notionally typecast is simply "Hey, here is a blob of bits in memory, and here is the definition of how to interpret those bits".  If that's what typecast did in LabVIEW, the typecast would have worked.

 

I think mcduff is the the closest: LabVIEW isn't simply saying "interpret these bits in this way". It tries to somewhat intelligently do the typecast.  Still, nothing I can find explains why I would get an empty array out of the typecast.

0 Kudos
Message 7 of 8
(70 Views)

This thread may have some of the information you are looking for.

 

https://lavag.org/topic/15187-inplace-typecast-possible/

 

 

mcduff

0 Kudos
Message 8 of 8
(61 Views)