LabVIEW
Hexadecimal String To Number conversion
Solved!
@giomarinna wrote:Is possible to set the "default" pin as U16?
The default input type of Hexadecimal String To Number determines the output type.
So, create a constant wired to the input. Right click it to change it's representation from I32 to U16.
I think you should use a type cast though, but we can't really be sure:
We still don't know for sure if 1A5B is 2 bytes or 4....
It would help if the strings in the screenshots of the front panel had it's display style visible... Pretty sure it's on hex display, given the spaces between the words.
Search LabVIEW like a graph!
@giomarinna wrote:
The message is received but with swapped bytes (e.g. i send 1CFF and I receive FF1C).
Use the Swap Bytes function, like I did in the example...
@giomarinna wrote:I tried to use the Type Cast but it returns me a value different from what I expect.
OK... But that doesn't help us help you.
The indicator is probably set to decimal. So it won't display 1CFF. but 7423, 65308 or -228.
A few comments:
1. A Nucleo is a STM32 microprocessor board, which means you are in charge of the communication protocol. This is just a clarification comment for those following, nothing for you to do about this (yet).
2. If you are messing with the display formats of your string and numeric controls/indicators/constants, you need to how the Display Style (for strings) or the Radix (for numerics). You enable that display by right-clicking on the control/indicator/constant and looking in the Visible Items sub-menu. You will then see little graphics showing what the display style/radix is and making the code clearer.
3. Since your data is raw/binary/hex data, the Hexadecimal String To Number is not the function you should be using. That function is for converting what I call ASCII Hex into a numeric. I would personally be using the Unflatten From String to convert the data into a U16.
4. I have plenty of more comments based on how you are reading your data. The Bytes At Port is generally a bad idea as well as your use of the shift register.
So a few more questions before I give any more advice:
1. How often does the STM32 need to send data to the PC?
2. How much control do you really have on the STM32?
3. Do you expect to have other data come across this bus?
@giomarinna wrote:
I'm sending unsigned int 16 bit HEX by my nucleo board in debug mode, so at the moment i can establish when the message is sent. The message is received but with swapped bytes (e.g. i send 1CFF and I receive FF1C).
For this reason I use the Reverse String Function. In the "substring" display I can read the correnct number in string format. Now, I want to convert it into a 16 bit number.
NOTE: Reverse string is not the same as swap bytes. Look closely at all 4 characters in the string vs the hex digit.
@Frozen wrote:
@giomarinna wrote:
I'm sending unsigned int 16 bit HEX by my nucleo board in debug mode, so at the moment i can establish when the message is sent. The message is received but with swapped bytes (e.g. i send 1CFF and I receive FF1C).
For this reason I use the Reverse String Function. In the "substring" display I can read the correnct number in string format. Now, I want to convert it into a 16 bit number.
NOTE: Reverse string is not the same as swap bytes. Look closely at all 4 characters in the string vs the hex digit.
This is why we keep asking for clarification. I believe the OP has the strings in Hex display while you are in Normal display. Those are two totally different values.
@crossrulz wrote:
@Frozen wrote:
@giomarinna wrote:
I'm sending unsigned int 16 bit HEX by my nucleo board in debug mode, so at the moment i can establish when the message is sent. The message is received but with swapped bytes (e.g. i send 1CFF and I receive FF1C).
For this reason I use the Reverse String Function. In the "substring" display I can read the correnct number in string format. Now, I want to convert it into a 16 bit number.
NOTE: Reverse string is not the same as swap bytes. Look closely at all 4 characters in the string vs the hex digit.
This is why we keep asking for clarification. I believe the OP has the strings in Hex display while you are in Normal display. Those are two totally different values.
While that is true, reverse string should never be used in hex to dec conversion.
@Frozen wrote:While that is true, reverse string should never be used in hex to dec conversion.
It is technically equivalent in this case assuming 2 bytes. And further in this case, notice the OP also has a Shift Register containing an ever-growing string. By reversing the string, you are now looking at the last 2 bytes.
Now let me take a step back. The ever-growing string shift register should not exist as the OP should only be reading the values as they come in. But I want a few more details before I really go down that rabbit hole, especially synchronization. But once we have the 2 data bytes, I would use Unflatten From String which includes in input for the Endianness (big or little). This will further eliminate the need for even the Swap Bytes.
@Frozen wrote:
@crossrulz wrote:
@Frozen wrote:
@giomarinna wrote:
I'm sending unsigned int 16 bit HEX by my nucleo board in debug mode, so at the moment i can establish when the message is sent. The message is received but with swapped bytes (e.g. i send 1CFF and I receive FF1C).
For this reason I use the Reverse String Function. In the "substring" display I can read the correnct number in string format. Now, I want to convert it into a 16 bit number.
NOTE: Reverse string is not the same as swap bytes. Look closely at all 4 characters in the string vs the hex digit.
This is why we keep asking for clarification. I believe the OP has the strings in Hex display while you are in Normal display. Those are two totally different values.
While that is true, reverse string should never be used in hex to dec conversion.
That's a bold statement.
It absolutely could be used, if the hex data is binary, not a string.
I'd usually prefer Swap Bytes and\or Swap Words, but I wouldn't rule out reverse string for each and every situation.
wiebe@CARYA wrote:
@Frozen wrote:
@crossrulz wrote:
@Frozen wrote:
@giomarinna wrote:
I'm sending unsigned int 16 bit HEX by my nucleo board in debug mode, so at the moment i can establish when the message is sent. The message is received but with swapped bytes (e.g. i send 1CFF and I receive FF1C).
For this reason I use the Reverse String Function. In the "substring" display I can read the correnct number in string format. Now, I want to convert it into a 16 bit number.
NOTE: Reverse string is not the same as swap bytes. Look closely at all 4 characters in the string vs the hex digit.
This is why we keep asking for clarification. I believe the OP has the strings in Hex display while you are in Normal display. Those are two totally different values.
While that is true, reverse string should never be used in hex to dec conversion.
That's a bold statement.
It absolutely could be used, if the hex data is binary, not a string.
I'd usually prefer Swap Bytes and\or Swap Words, but I wouldn't rule out reverse string for each and every situation.
Alright, alright. I might have gone a bit too far with "never". There are cases where it could work.
Your comment "hex data is binary, not a string" is a bit confusing though. If is binary data, then it is not a string. However, VISA read function always returns a string. Hence the confusion and multiple forum posts like this one.
@Frozen wrote:Your comment "hex data is binary, not a string" is a bit confusing though. If is binary data, then it is not a string. However, VISA read function always returns a string. Hence the confusion and multiple forum posts like this one.
Yes, this is a very confusing thing when trying to talk about instrument communications. I always push back when somebody states "Hex" because it is sometimes flattened data (ex 2 bytes for a U16) and sometimes an ASCII string (ex 4 characters for a U16 using only characters used for hex encoding). So I have taken to stating the former at "raw/hex/binary" (all three really mean the same thing, just depends on who you are talking to which term will be used, so I just state all three together) and the latter as "ASCII Hex".
