views:

30

answers:

2

I'm working with OKI 431 micro controller. It can communicate with PC with appropriate software installed. An EEPROM is connected in the I2C bus of the micro which works as permanent memory. The PC software can read from and write to this EEPROM.

Consider two numbers, B and C, each is two byte integer. B is known to both the PC software and the micro and is a constant. C will be a number so close to B such that B-C will fit in a signed 8 bit integer. After some testing, appropriate value for C will be determined by PC and will be stored into the EEPROM of the micro for later use.

Now the micro can store C in two ways:

  • The micro can store whole two byte representing C
  • The micro can store B-C as one byte signed integer, and can later derive C from B and B-C

I think that two's complement representation of negative number is now universally accepted by hardware manufacturers. Still I personally don't like negative numbers to be stored in a storage medium which will be accessed by two different architectures because negative number can be represented in different ways. For you information, 431 also uses two's complement.

Should I get rid of the headache that negative number can be represented in different ways and accept the one byte solution as my other team member suggested? Or should I stick to the decision of the two byte solution because I don't need to deal with negative numbers? Which one would you prefer and why?

+2  A: 

An ancient FORTRAN application I used to work for used to store the values for certain fields as positive integers with an implied negative offset. There were 12 bits available to store numbers in, so we would add 1024 to the value before storing it, and subtract it after retrieving it. That would allow us to store numbers in the range from -1024 to 1023 using a positive number in the (external) memory, with a range of 0 to 2047.

Hardly elegant, but very simple. You're essentially doing the sign bit handling in code.

Carl Smotricz
I'd use the minimal possible value for C as the offset, and add an unsigned byte from the EEPROM to get the configured C value.
starblue
+1  A: 

This is very specific to your application and unless I am missing something there do not seem to be any external repercussions to doing it one way or another.
My suggestion is to simply pick one and go with it.
Since you team-mates are suggesting one way and there is really no difference, then going with the team is not a bad solution.

Romain Hippeau