LabVIEW
must be an easier way...
Solved!
Hi for(imstuck),
over night I got an inspiration:
As you interpret some status bits from some device you could do this:
- pick the 4 status bytes from the data stream
- typecast the 4-byte-array to a cluster of 32 bits -> et voila, you're ready!
For this to work you have to setup your status cluster just a little bit different:
Define a cluster with 32 booleans (as strict typedef?!). Label them as you did now, but include the unused bits (labeled as "unused1", "unused2"...). You can even hide the unused bits for better look of the front panel! And you access the relevent information (as you should do right now) by simple unbundle by name functions...
Darin.K wrote:On second thought, leaving behind code that nobody else can understand is a good way to help them realize your genius once you are gone, right? Twiddle away!
Clever does not need to be obscure, and I actually think that my version is very readable to anyone who ever did bitwise operations. I even think it is significantly easier to read than e.g. Gerd's above: No orange wires, no "2^x -1" head scratcher, no multiple SRs. Bitwise OR is probably more natural than "add" for this. 😮
Your version is a more literal implementation of the problem, but it's again complicated by the unecessary presence of the initial array subset. If it's not there, it does not need to be figured out by the next programmer. 😉
Sure, things need to be documented, but that's true for all solutions presented here. I agree, performance for this problem is only a secondary consideration. Still, I do the bulk operation in a singe U32 (4 bytes) while you successively grow an array to 21 bytes. This is over 5x more and requires successive datacopies with each iteration of the loop.
Honing the programming skills on miniatures likes this IS important. This way we don't need to learn new techniques once we need to deal with larger data structures, where the coding choice make a difference between 10ms and 10s, or between "works great" vs. "out of memory". It is a matter of scaleability. 😄 If you only want to learn one algorithm to do a certain operation, learn the one that works under all conditions. 🙂
For better documentation and code readability, I would probably still do a few things slighly differently. For example the mask diagram constant could be formatted in binary so they show as [0, 111111, 111111, 111111, 111]. Also notice that I always show one extra greyed element to document the array size of the diagram constants. If you only show the actual elements, you are never really sure how big the array really is by just looking at the diagram image. (Container size has nothing to do with array size!) Again a potential source for errors. If we make the code more self-documenting, fewer diagram comments are needed.
The documentation cold be a very simple, showing the program purpose with the aid of color. e.g.
Extract the 21 bits shown in red from an U8 array and cast to a cluster of 21 booleans for display.
[xxxxxxxx,xxxxxxxx,xxxxxxxx,xxxxxxxx,xxxxxxxx,xxxxxxxx,xxxxxxxx,...]
The order of the bits in the output should be low to high for each source octet.
Hi altenbach,
"No orange wires, no "2^x -1" head scratcher, no multiple SRs. Bitwise OR is probably more natural than "add" for this."
As I also wrote: the 2^x part was only there for showing the concept and could be easily replaced by an array constant, but to create a mask of x "TRUE" bits is just 2^x-1... Also at this point I was expecting the possibility for different bit masks therefor using more than one SR. And yes, an OR is probably more natural, but the same as an ADD as long as bit ranges aren't overlapping. And well, I recently wrote a similar bitpacking routine, so I surely included to less documentation in the snippet 
