compile time arithmetic with exponents

Projects Programming
1

Hello,

I'm trying to create a compile time value for a register using natural symbols
Fcpu=16*10^6
prescale1024=1024
Fint=100

OCR2A=Fcpu/(Fint*prescale1024)-1 and its integer truncation should equate 155

Can someone please tell what is the way to have the compiler generate this constant, ideally w/o using runtime resources?

Thanks,

Guy

2

Don't use the XOR function.

3 
Fcpu=16*10^6

In C/C++ the ^ operator is not exponentiation. It is the exclusive OR operator.
There is no exponentiation operator in C/C++. You would have to use the pow() function but that is fraught with danger too.
Just don't be so lazy and write out all the zeros. And declare Fcpu to be a long integer and then set it with this:

Fcpu=16000000L

Pete

4

sorry, I wrote the math expression I wanted not the code

5

guy_c:
Fcpu=16*10^6

The OP could have been at the no-gain/no-loss side by writing:
Fcpu = 16*1E6.

unsigned long Fcpu = 16*1E6;
6

GolamMostafa:
The OP could have been at the no-gain/no-loss side by writing:
Fcpu = 16*1E6.

unsigned long Fcpu = 16*1E6;

Thanks but I don't want to waste a runtime long

7

So, make it a constant.

8

I tried this code

const long Fcpu= 16*1e6;
const int prescale1024=1024;
const int fInt=100;
void setup() {
  Serial.begin(38400);
  while (!Serial);
  byte x=(Fcpu/(fInt*prescale1024))-1;
  Serial.print(x);
}

void loop() {;
  // put your main code here, to run repeatedly:

}

getting 209

on excel =(1610^6)/(1001024)-1 gives 155.25

9 
const int prescale1024=1024;
const int fInt=100;

And the product of those two ints is . .what?

11

guy_c:
getting 209
on excel =(1610^6)/(1001024)-1 gives 155.25

You are expecting result in floating point format; but, you are doing integer math with wrong data types. Declare your x with proper data type and make the corresponding casting at the RHS with the appropriate operand. The machine/program is awaiting to offer you 155.25.

12

Since this is (sopposed to be) computed be the compiler on a cross machine that could be anything, including a ternary one, to yield one constant integer it is strange why the progrsmmer should be conerned about details at all

13

guy_c:
Since this is (sopposed to be) computed be the compiler on a cross machine that could be anything, including a ternary one, to yield one constant integer it is strange why the progrsmmer should be conerned about details at all

Programmers not concerned with detail?
Nah. It'll never catch on.

14

guy_c:
Since this is (sopposed to be) computed be the compiler on a cross machine that could be anything, including a ternary one, to yield one constant integer it is strange why the progrsmmer should be conerned about details at all

Neither the computer nor the compiler is a Natural Entity that it will automatically adjust with the changing environment to sustain survival.

You have made the machine and the compiler, and you know very well what they need as input to provide the result that you want. It is a pre-negotiated system.

You are expecting 155.25 (a number with an integer part and a fractional part); but, you have declared your receiver as byte (byte x) which can accommodate only integer number. Is it right? So, you make a declaration like: float x;.

Now come to the RHS side of your equation: x = (Fcpu/(fIntprescale1024))-1;. Now you have to force (cast) the compiler to take care of the fractional part of the result during calculation. Because * (multiplication) has the higher precedence than the / (division), (fIntprescale1024) will be evaluated first. I would naturally do append cast with it. That is to say:

float x = (Fcpu/((float)fInt*prescale1024))-1;
15

Multiplication and division have the same precedence in C/C++ and would be evaluated left-to-right. But in this "(Fcpu/((float)fInt*prescale1024))", the multiplication is in parentheses which forces it to be evaluated before the division.

Pete

16

AWOL:
Programmers not concerned with detail?
Nah. It'll never catch on.

there are many aspects of the compiler which the programmer -but the compiler's coder himself- is not and does not be concerned with

17

guy_c:
there are many aspects of the compiler which the programmer -but the compiler's coder himself- is not and does not be concerned with

...and we're back to syntax and attention to detail :wink: