Bug in M Series C/C+ DDK example (Mac OS, endianness​)

Question

I am trying to get C/C++ examples for the M Series DDK running on Mac OS 10.4 with Xcode 2.2 and have run into an apparent bug. When converting the EEPROM values into usable data (e.g., finding scaling constants), the function "getF32FromEeprom" in "scale.cpp" is called. In the original version, this function is:
f32 getF32FromEeprom (const u8 *eepromMemory, u32 offset)
tEepromF32 value;
value.b[3] = eepromMemory[offset++];
value.b[2] = eepromMemory[offset++];
value.b[1] = eepromMemory[offset++];
value.b[0] = eepromMemory[offset++];
return value.f;
This bit order is backwards for Mac. The example programs work when this function is switched to:
f32 getF32FromEeprom (const u8 *eepromMemory, u32 offset)
tEepromF32 value;
value.b[0] = eepromMemory[offset++];
value.b[1] = eepromMemory[offset++];
value.b[2] = eepromMemory[offset++];
value.b[3] = eepromMemory[offset++];
return value.f;
After making this switch, my board (6259 PCI) happily spits out the correct voltages.
It looks like there are compiler switches in other parts of the code to test for big endian vs. little endian, but this piece of code snuck through.
Is there a list of known bugs in the sample code? I stumbled across a post about a different bug and wonder if there may be more.
Melissa

Answer 1

So far, there's the problem you are describing and a bug in the ADCReset function for 625x devices:
Driver Development Kit (DDK) : inputs return minimum value
Diego