01-04-2022 01:27 PM
Proven Zealot
About Hexadecimal String To Number: I create a constant,
assigned the value 0 and changed the representation in U16 but "number" display still show zero.
1A5B is 2 byte.
The "Data Received" display style is HEX.
The value returned from the Type Cast in the indicator is 12611 when the input string is 1CFF.
Frozen
Understood the difference between Reverse String e Swap Bytes. I'll use the 2nd one.
Knight Of NI
I have not yet established how often i need to send message, I think 0.2 - 1 Hz.
The final goal is to send a big amount of voltage and temp measure coded in hex; each of them is coded by 16 bit hex values.
I want to use the Labview front panel as control panel. The data flow should be always from MCU to Labview.
What do you mean with "How much control do you really have on the STM32?"
01-04-2022 03:20 PM
@giomarinna wrote:
Knight Of NI
I have not yet established how often i need to send message, I think 0.2 - 1 Hz.
The final goal is to send a big amount of voltage and temp measure coded in hex; each of them is coded by 16 bit hex values.
I want to use the Labview front panel as control panel. The data flow should be always from MCU to Labview.
What do you mean with "How much control do you really have on the STM32?"
1. "Knight of NI" is a title I earned. It is not my name. Similar for the "Proven Zealot" you attempted to reply to.
2. If you needed to go faster, I would tell you to go with a faster Baud Rate. You might want to anyways to reduce lag. 115200 is a very common Baud Rate.
3. Voltage and Temperature over the same bus. That is quite doable. More on that below.
4. Messaging is unidirectional. I see no immediate issues with that.
5. My question on control you have on the STM32 is a question of how much you are allowed to change on it. I have been given projects where I just have to talk to something and I have no input on the protocol used. That is usually a pain. Then others I am also doing the microcontroller or I am directly working with the one who is doing the microcontroller and we go back and forth to create the protocol. So for now, I will just assume you can dictate what the messaging protocol is.
Now for the really fun stuff...
I think you should completely throw out what you currently have. You need to have a proper communication protocol before you can go any further. The point of the protocol is to make sure you are grabbing the correct bytes and properly decoding them. It is way too easy to miss a byte and have everything offset and ruining your tests if you don't. My suggestion would be to use 0x02 as a start byte (in ASCII, this character is defined as STX or "Start Of Text"). Then comes the 2 data words (I16 for voltage and I16 for temperature). Then follow that with a checksum of some type. A simple checksum would be to add all of the bytes. Or you could do a CRC of some kind. The point of the checksum is a verification of the message.
Now on the LabVIEW side, what you do is read 1 byte. If it is 0x02, then read 5 more bytes to read the rest of the message. Do the checksum verification. If it passes the verification, then process the data. If the verification fails, ignore it. Go back to reading the 1 byte until 0x02 is read. This is a fairly simple loop with several case structures embedded.
For more information on that, I highly recommend a certain presentation: VIWeek 2020/Proper way to communicate over serial
As far as processing the two words, you can just use Unflatten From String with a cluster of two I16 values as the data type. If needed, you can also set the Endianness (it is sounding like the STM32 likes Little Endian while LabVIEW uses Big Endian by default). You can then unbundle and do whatever math you need to get your actual values.
01-05-2022 05:34 AM
About communication protocol, I'm free to implement what I want, it's the next step. I'll take into account your suggestions.
At the moment I'm still blocked on data conversion. I didn't understand how to use the Unflatten From String.
How to define the type? What do you mean for "cluster of two I16 values"?
01-05-2022 06:22 AM - edited 01-05-2022 06:23 AM
This is what it's all about:
How LabVIEW Stores Data in Memory - LabVIEW 2018 Help - National Instruments (ni.com)
In the related topics:
Flattened Data - LabVIEW 2018 Help - National Instruments (ni.com)
Available on LAVA as one PDF: LabVIEW Data Storage (lavag.org)
01-05-2022 07:56 AM - edited 01-05-2022 07:58 AM
@giomarinna wrote:
At the moment I'm still blocked on data conversion. I didn't understand how to use the Unflatten From String.
How to define the type? What do you mean for "cluster of two I16 values"?
01-05-2022 10:22 AM
@giomarinna wrote:
About communication protocol, I'm free to implement what I want, it's the next step. I'll take into account your suggestions.
At the moment I'm still blocked on data conversion. I didn't understand how to use the Unflatten From String.How to define the type? What do you mean for "cluster of two I16 values"?
Shouldn't the communications protocol be the FIRST step in communications???
01-05-2022 11:16 AM
@billko wrote:
@giomarinna wrote:
About communication protocol, I'm free to implement what I want, it's the next step. I'll take into account your suggestions.
At the moment I'm still blocked on data conversion. I didn't understand how to use the Unflatten From String.How to define the type? What do you mean for "cluster of two I16 values"?
Shouldn't the communications protocol be the FIRST step in communications???
I think establishing any kind of communication is a logical step before making a communication protocol.
We'd skip this step, because we know how the communication works.
If it's one's first take on any HW communication, this conversation does make sense (to me).
01-05-2022 12:06 PM - edited 01-05-2022 12:09 PM
wiebe@CARYA wrote:
@billko wrote:
@giomarinna wrote:
About communication protocol, I'm free to implement what I want, it's the next step. I'll take into account your suggestions.
At the moment I'm still blocked on data conversion. I didn't understand how to use the Unflatten From String.How to define the type? What do you mean for "cluster of two I16 values"?
Shouldn't the communications protocol be the FIRST step in communications???
I think establishing any kind of communication is a logical step before making a communication protocol.
We'd skip this step, because we know how the communication works.
If it's one's first take on any HW communication, this conversation does make sense (to me).
I thought the hardware was already determined. Oops?
I would think that the moment you determined the coms hardware (serial, Ethernet, etc) the next thing is to determine the protocols?
01-06-2022 01:49 AM
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
@giomarinna wrote:
About communication protocol, I'm free to implement what I want, it's the next step. I'll take into account your suggestions.
At the moment I'm still blocked on data conversion. I didn't understand how to use the Unflatten From String.How to define the type? What do you mean for "cluster of two I16 values"?
Shouldn't the communications protocol be the FIRST step in communications???
I think establishing any kind of communication is a logical step before making a communication protocol.
We'd skip this step, because we know how the communication works.
If it's one's first take on any HW communication, this conversation does make sense (to me).
I thought the hardware was already determined. Oops?
I would think that the moment you determined the coms hardware (serial, Ethernet, etc) the next thing is to determine the protocols?
If the first time you connect your hardware, the first bytes you communicate are unexpected, then I suppose the design of a communication would be difficult.
Once you can transfer bytes, then words, then you can work on a protocol.
If there's any change at all, I'd use a ASCII protocol. Binary data is much harder, as binary data can contain any value and you'll lose end termination characters as a means of synchronization. The HW side might get more complicated though... Tiny MCUs might not be up to it.
If an ASCII protocol isn't an option, I'd go for a read\write setup, where the MCU doesn't write anything unless the receiver sends a request. Without an end termination character, the reader has no way to tell where the data starts and ends if there's a stream of data.
Last resort is to prepend each message with a size byte or word.... Still, this data is indistinguishable from any other binary data. Start and stop signatures are also an option, but also just make communication failure less likely.
01-06-2022 05:22 AM
wiebe@CARYA wrote:
Start and stop signatures are also an option, but also just make communication failure less likely.
That is all that these communications schemes actually do: make failure less likely. You will not be able to stop all forms of failure, but you can do a lot to minimize issues.