I am trying to send floating point numbers over UART and am currently running into a problem where the number I send from ORPSoC is not the number I receive on the computer.

My current test involves sending 3 ASCII chars and an int followed by 3 floats. The 3 ASCII chars and the int arrive correctly on the computer. To figure out how to send floating point numbers I am first just sending the byte 0x1 for all 4 bytes of the first float. This is being interpreted correctly on the computer so I am confident the computer side is working correctly. The next float I send is 10.5, and this is arriving as 0x002840E5. The 3rd float is an accelerometer value and is arriving as either 4.59e-41 or 0 depending on how I hold it but nothing in between.

To send the second two floats I am using unions, so I set the float value and then read out the bytes. This is how I have the union set up

union test
{
float data;
char bytes[sizeof(float)];
} testx;

This is in the part as my uart interrupt handler which contains a switch statement to know which part of the UART message it's sending. The case for the 10.5 float is as follows:

testx.data = 10.5f;
uart_putc_noblock(0,testx.bytes[UART0_INFO->byteCounter]);
UART_INFO->byteCounter++;
if(UART_INFO->byteCounter==4)
{
UART_INFO->byteCounter=0;
}

I know the byteCounter is 0 the first time through, and should therefore iterate through the chars.

I'm new to unions so I'm afraid I'm using it wrong and if that's the case I apologize for posting here, but from what I can tell online I am using it correctly. The board I am testing on is the DE0-Nano and I have hardward floating point enabled. Please let me know if you need any more information, and I appreciate the help.

Thanks,

Chris

Sorry for spamming the message board. Turns out my sanity check of sending 0x01010101 wasn't smart, changed that to 0x03020100 so I could identify the order the bytes were received and was able to fix my problem. Turns out it was computer side after all.

Thanks,

Chris