So, isn't it relevant that I told CubeMx the data size to be 16 bits instead of 8? Because I’m using a 8 bits pointer anyways, so I think if I say that my data size is 8 bits, it would be the same.
Another question, I set the timeout at 1. But I’ve seen timeouts at 5000. What's the criteria behind?
Timeouts depend very much on the needs and constraints of the application, quite difficult to give a general rule, but yes 1ms seems a bit tight...
As for the SPI data transfer size: yes it's extremely relevant.
The SPI peripheral in STM32F7 (IIRC that's what you are using?) will send/receive the data differently if it's in <=8bit or >8bit mode.
If in 16bit mode, the reconstruction suggested by rjb will not work, as the MSByte will be in buffer[1] and the LSByte in buffer[0]: the data register is treated as an uint16_t and (this) Arm is little endian, so the lower address will hold the least significant part.
Note that this is true even if you use direct register access instead of the HAL.
If you are sending and receiving 16bit words, the best option IMO is to use a uint16_t variable, and cast its address to an a (uint8_t *) when passing it to the HAL (if you want to silence the warning).
The C standard guarantees that the cast gives the expected results: address of the first byte in the object.
In this way there's no need for reassembling the received values, assuming, of course, that they
are transmitted as 16bit cvalues MSb first!
The size must still be given in bytes, so it will be something as:
uint16_t val;
HAL_SPI_Receive(&hspi1, (uint8_t *)&val, 2, 10);
Edit: corrected after richardman's finding!