"376 Integer const expected" error on passing "const unsigned int" function arg to Delay_ms()

[steve42lawson]

The following code causes a "376 Integer const expected" compiler error message:

Code: Select all

// FYI I trimmed this code down to the essentials to showcase my issue.

const unsigned int ERR__ALL_FUBAR  = 15;
sbit pin_o_error at LATA7_bit;

void handle_error(const unsigned int);

void main()
{
    handle_error(ERR__ALL_FUBAR);
}	

void handle_error(const unsigned int error_num)
{
    // Set period of error pin to "error_num" # of milliseconds
    pin_o_error = 1;
    Delay_ms(error_num);   // <-- Compile error "Integer const expected"
    pin_o_error = 0;
}

Why?

Isn't error_num an "Integer const"?

The MikroC PRO Help document shows the following function prototype for Delay_ms:

Code: Select all

void Delay_ms(const unsigned int time_in_ms);

If I change Delay_ms() to VDelay_ms() the compile error goes away. So, the code is fine.

I would like to use Delay_ms() because, according to the Help document, it's more precise than VDelay_ms();

[Smart_Aleck]

Hi,

the difference between Delay_ms() and VDelay_ms() is, that the parameter passed is a variable.

Creates a software delay in duration of time_in_ms milliseconds (a constant).

If you try to set the Delay_ms() to a constant value, instead of passing the error_num it should work.
Just give it a try, to check if this is the cause.
Even you set the type to "const unsigned int", it might be treated as variable by the compiler.

Personally I would set the prototype definition to the same setting as the function call.

Code: Select all

void handle_error(const unsigned int error_num) ;

[steve42lawson]

I did all of that -- as reported in my original post <see above>. And, yes, I know the difference between Delay_ms() and VDelay_ms() -- also indicated in my original post <see above>.

[Smart_Aleck]

Hi,

I think the Delay_ms() is simply limited to constants. The documentation says

This is an “inline” routine;

The higher precision of this routine, compared to VDelay_ms() has its price, it isn't as flexible.
It seems you need to decide for either, precision or flexibility.

What are you trying to do? From the code snippet it looks like you want to indicate the error number by the length of a pulse on pin_o_error.
Depending on the number of different errors, you might get away with a switch/case and several Delay_ms(). You loose a little bit of flexibility,
but keep the precision.

[steve42lawson]

You nailed it. My goal is to implement a "low-level" error indication as a back up for my higher level UART error handler. Errors are also displayed on an LCD on the "console". The idea is to have some form of error indication in the absence of access to the higher level indicators.

And, I thought of another way to do this -- one that allows the use of Delay_ms():

Code: Select all

// Alternate way to achieve my objective while still using Delay_ms().
// Downside: Adding new error cases is a little more involved.
// BTW: This will be running at a clock speed of 16MHz, so the switch timing hit will be negligible.

#define ERR__ALL_FUBAR    1  // 11 ms
#define ERR__ALL_NUTBAR   2  // 13 ms
#define ERR__ALL_CROWBAR  3  // 15 ms

sbit pin_o_error at LATA7_bit;

void handle_error(const unsigned int);

void main()
{
	handle_error(ERR__ALL_FUBAR);
}	

void handle_error(const unsigned int error_num)
{
	pin_o_error = 1;
	switch (error_num)
	{
		case ERR__ALL_FUBAR  :
			Delay_ms(11);
			break;
		case ERR__ALL_NUTBAR  :
			Delay_ms(13);
			break;
		case ERR__ALL_CROWBAR  :
			Delay_ms(15);
			break;
		default:
			// Indicate unknown error number
			Delay_ms(101);
	}
	pin_o_error = 0;
}

Bottom line: My question was "Why?" I was hoping someone could explain why a function argument passed as "const unsigned int" is not considered a "constant", and WHY, even though the Help Doc shows the prototype as:

Code: Select all

void Delay_ms(const unsigned int time_in_ms);

i.e. the EXACT same data type as my "constant"... WHY the compiler complains.

Or, actually, based on the note: "This is an “inline” routine", [as you pointed out] the function prototype is more like:

Code: Select all

inlne void Delay_ms(const unsigned int time_in_ms);

Does this boggle anyone else's mind?!?

[Smart_Aleck]

Hi,

as you have the source files, you might take the chance to look inside.

Let's take the rest of the description of the help file.

This routine generates nested loops using registers R13, R12, R11 and R10. The number of used registers varies from 0 to 4, depending on requested time_in_ms.

This sounds to me, as the routine is generated "inline", based on the time_in_ms value. In other words, it's probably a kind macro that generates the routine at the place where you call it,
using the processor registers as counters. It's still a normal function, therefore the prototype definition is fine. But it's also "inline", in the code, not a function call in the normal sense.
If you make two calls, it will be generated two times, or three times and so on. This is not a subroutine like VDelay_ms().

At least for me, that's a very clear picture, and also explains why the value must be a real constant.
Maybe the terms "at compile-time" and "at run-time" gives you another idea. The constant time_in_ms must be fixed at compile-time, your error_num does not follow the rule, it is valid only at run-time. The compiler seems to be smart enough to detect this discrepancy.

Nevertheless, you found a solution, that is almost identical to my proposal.

BR
SA

[steve42lawson]

So, the real issue is with the documentation. Instead of "constant", it should say "literal constant" or merely "literal". The omission of that qualifier gave me the impression the Delay_ms() function was capable of more than it is, which was a time waster! One simple word would have saved me considerable effort!

Quality communication is important!

BTW: When you say "real constant" I assume you mean "literal constant". Because, "const unsigned int" IS a real constant.

And, yes, sometimes context can inform, but not in this case. There is no context, in the documentation, to lead me to the understanding that "constant" means "literal".

[frank.malik]

Hi,

you are right, the correct wording would be "literal constant", and yes, the documentation should be a little bit clearer about this.

br
SA