Part Number:F28M36P63C2
Tool/software: TI C/C++ Compiler
I have the following struct that is shared between the M3 and C28 processors, and is given a value by a PC via ethernet and shared memory. I am sending the same data values from a PC to both the M3 and C28. I then cast the data buffer into the PID_CONF struct and print out the values of the struct using the following code:
typedef struct _PID_CONF { Float32 tolerance; Float32 Kp; Float32 Ki; Float32 Kd; Float32 maxOutput; Float32 minOutput; Uint16 minStableTimeSec; Uint16 maxSettlingTimeSec; Uint16 period; Uint16 Reserved; } PID_CONF; // Code is the same for the C28 / M3 uint_least8_t * replyData = <this data comes from the PC> PIDCTRL *pid = (PIDCTRL *)replyData; DbgInfo("Setting: %f %f %f %f %f %f %f %u %u %x %x %x %x", pid->setPoint, pid->tolerance, pid->Kp, pid->Ki, pid->Kd,pid->minOutput, pid->maxOutput,pid->minStableTimeSec, pid->maxSettlingTimeSec, replyData[0],replyData[1],replyData[2],replyData[3]);
I am sending the data values (1.0,2.0,3.0, ... 9.0) and this is what I see. The M3 correctly casts the data and prints it correctly, but the C28 does not cast the floating points correctly, only the Uint16 fields.
M3 Setting: 1.0000 2.0000 3.0000 4.0000 5.0000 8.0000 9.0000 6 7 0 0 80 3f
C28 Setting: 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 6 7 0 3f80 0 4000
I also printed out the first 4 words of the raw buffer and noticed the bytes were swapped in the C28, i thought the C28 and M3 were both little endian and have the same IEEE 754 floating point values. Am I missing something obvious?
Also here is some additional information. The function DbgInfo internally uses 'System_vsnprintf' to print the formatted values, and i have add 'System.extendedFormats = "%$L%$S%$F%f";' to my .cfg file so that the prints work with the extended format. I also verified the prints are work correctly on the C28 if I manually set a float field in the PID_CONF struct (e.g., pid->Kp = 5.324). I have tried modifying the struct packing, but that doesn't seem to help either.
Derek