Unexpected behaviour with pow(2,x) in Embedded C

Question

I am a newbie in Embedded C (solo learner). I am using it to drive around a robot (using the ATmega2560 with 14.7456 MHz). I am experiencing some unexpected behaviour with the following code:

int j = 2;

PORTJ = pow(2, j) - 1;

Now I expect 3 to be seen at port J. However, I see 2. Moreover, if I do this:

PORTJ = pow(2, 2) - 1;

then it works fine (that is, I see 3 at port J). The reason I want to do this using a variable is because my actual code is this:

int j = 0;

while(1)
{   
    j = (j + 1) % 9;

    PORTJ = pow(2, j) - 1;

    _delay_ms(500);
}

This works for all values of J except for j = 2. What am I doing wrong here? I have recently started so I don't know much about this. Any help is appreciated.

Answer 1

While this is a programming question, it is one that can turn up quite often in embedded settings, so it's not really off-topic here.

The most likely issue is indeed caused by truncation (not rounding - that does not happen).

A far better approach would be to use a bit shift operator - this will not only be more true to your intent, but faster too, as in basic circumstances it is a primitive operation directly implemented in many ALUs (though not, as pipe points out, the AVR, which can only shift one bit position at a time)

int j = 2;

PORTJ = (1 << j) - 1

(EDIT - thanks to ilkkachu for the correction)

You will find such operations all over the place in I/O macros for many microcontrollers and hardware or bitfield related code on larger systems.

(Incidentally, should you every try to use this to shift or produce a value larger than an int, look up the type rules which apply - they are not necessarily intuitive!)

Answer 2

The problem is that the pow function is unfortunately only specified for floating point numbers. And floating point numbers have inaccuracy, see this.

So when you do 2^2 you might not get exactly 4, but perhaps 3.9999. That's the actual bug. Then 3.9999 - 1 is 2.9999. When you convert this back to an integer type to print it on the port, it will get truncated to 2.

Now as it happens you shouldn't use floating point to begin with, as using floating point numbers in embedded systems is almost always bad design. Only programs that use floating point calculations extensively should need them. For example if you do lots of trigonometry calculations, signal processing, fuzzy logic, AI or similar special-case applications.

In which case you picked the wrong MCU entirely, as an 8 bit MCU with no FPU on chip will be extremely ineffective at processing such calculations! It isn't a PC.

Just forget about float numbers. It is trivial to write an integer version of pow() yourself:

uint32_t intpow (uint32_t base, uint32_t exp)
{
  uint32_t sum;

  if(exp == 0)
  {
    sum = 1;
  }
  else
  {
    sum = base;
    for(uint32_t i=1; i<exp; i++)
    {
      sum *= base;
    }
  }

  return sum;
}

In case you don't need large numbers, you can optimize the above quite a bit by going down to uint16_t or uint8_t, which your 8-bitter MCU will enjoy far more. And as noted in other answers, anything 2^x could be solved with bit shifts.

Also, as mentioned in another answer, consider using look-up tables with pre-calculated values instead, if that's an option.

Answer 3

For this simple example I would make a table (array) of int values that match the bit width of your PORTJ. This table would have ten values indexed from 0 to 9.

Inside the loop the assignment to the port simply becomes:

PORTJ = array[j];

This will be fast and be very small code.

If the entries in the table (array) become true complex calculations do them in a spreadsheet and export the results to your C code file.