STM32f sending uint16_t via uart

Question

im trying to send uint16_t data with this code

uint16_t ADCValue;
uint8_t lowerMessage;
uint8_t upperMessage;
uint8_t message[2];

while (1)
{
      ADCValue = 2375;
      lowerMessage = (uint8_t)ADCValue;
      upperMessage = (uint8_t)(ADCValue >> 8);
      message[0]= lowerMessage;
      message[1]= upperMessage;
      HAL_UART_Transmit(&huart1,message, 8, 1000);
      //HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_9);
      HAL_Delay(2000);  
}

i split the 16 bit integer to 8 bit integers to send. But when i try the send this i recieve this -> Received Data. What should i do to send this data?

Answer 1

In the call to HAL_UART_Transmit you pass 8 as the size. That's the size in bytes you want to send. And your array only have two bytes (i.e. sizeof message is equal to 2).

And on the receiving size, you should of course read two bytes. And treat them as raw bytes without any specific meaning. You should definitely not try to print it as a string, because it isn't. Instead you should take the individual bytes of the array and to the reverse of what you're doing in the sender program, to reconstruct the original uint16_t value.

Answer 2

while (1)
{
      ADCValue = ReadADC();
      /* .... */
      HAL_UART_Transmit(&huart1,(uint8_t *)&ADCValue, sizeof(ADCValue), 1000);
      /* .... */
}

On the receiver side (assuming the same endianness - most systems use it nowadays)

HAL_UART_Receive(&huart1,(uint8_t *)&ADCValue, sizeof(ADCValue), 1000);

HAL library is written quite a bad way (instead of void * they expect uint8_t *) and the cast is to silence the warning. A believe that the 'message' magic you did was to avoid this warning.

Also check the return value for errors.

Answer 3

As mentioned by others, you have wrong message size, it should be "2" there (number of bytes, sizeof() is even more flexible to use).

I will also elaborate one why you see garbage: when you send a byte with, say, number "97", on the receiving side you will see letter "a". Because that's what number 97 (hex 0x61) encodes. You're not sending decimal digits as characters, you're sending 0b01010101 (or whatever individual bits are), and your receiver chooses to interpret it as a char - which is often the desired behavior.

So the data received may very well be correct, but you will still see garbage on the screen, because it's treated as a char. And char 97 is just a letter a. You can experiment with it by manually sensing 97/0x61 and seeing what actually arrives on the receiver.

Here you can find the ASCII table with what char every number encodes. Here is the table from there:

There is a decimal value first, then hex value, then its meaning as a char. For example, notice that 0xFF (dec 255) shows as a symbol ÿ. If you ever open binary file in some hex editor, you will see ÿ all over the place. That's just bytes with all 1s treated as characters.

---

There are various solutions to this problem.

Solution number 1: you turn your entire 16-bit integer into a string of its decimal digits. Before you send something, you convert, for example, ADCValue of 35000 into string '35000' and send all these as chars.

Important note: character "1" is not the same as uint8_t 1. Character 1 is a binary value of 0x31 (dec 49), as per table above. So if you send 0x31 via uart, the receiver will show "1". You need to actually convert every digit of the number into corresponding character.

Advantages of this approach: the receiver gets formatted data, all you need to do is to cast it to integer, and you're done. You will see actual "35000" in the terminal.
Disadvantages: you actually need to turn a decimal number into a string of various lengths depending on length of the number, which is an unpleasant operation that takes processing power of MCU, and you will often have more bytes to transfer for every character of the decimal digit. Sending 2 bytes is shorter than sending 5 byte characters of '35000'. You can find solutions to it on the internet - conversion from 35000 to '35000'.

Approach 2: you pass conversion to integer to the receiver. Send data as raw bytes as you do now, but interpret it on the receiver.

Advantages: you send 2 bytes from MCU just like you do in the question. It's the responsibility of the receiver to interpret them correctly. Every transmission will be strictly 2 bytes, so you can time the whole thing better. Also, if your receiver is a PC, it has infinite computational power for conversion comparing to the microcontroller.

Disadvantages: in the terminal you will actually see garbage, unless your terminal supports treating incoming data not as chars, you should check settings. You need to implement conversion to integer on a receiver and print it out yourself in your application, terminal may or may not be able to do that.

Advice: maybe for test purposes you first implement approach 1, so that you can quickly see in the terminal what actual value of ADC was. When you see in the terminal it measures and sends the stuff correctly, you can delete the intereger to string conversion part from the transmitter and send raw bytes and convert them on the receiver side.

---

Once you fix length of transmission, it is very likely that the data you're sending is correct, it's just the terminal that interprets those bytes as chars.