Hi,

I am trying to port some code I use on an Arduino to my new mbed!!

The following

long to_steps(float steps_per_unit, float units);
{
 return(steps_per_unit * units);
}

Gives an error E120 Return value type does not match the function type? It worked on an Arduino what am I missing?

also with a boolean statement;

bool can_step(byte min_pin, byte max_pin, long current, long target, byte direction)
{
	//stop us if we're on target
	if (target == current)
		return false;
	//stop us if we're at home and still going 
	else if (read_switch(min_pin) && !direction)
		return false;
	//stop us if we're at max and still going
	else if (read_switch(max_pin) && direction)
		return false;

	//default to being able to step
	return true;
}

I get the same error with the above? Why is return false / true not the right return value for a bool function? Again I'm sure its something I'm doing wrong as I am still quite new to C!!!!

Thanks

Michael.

Hi Michael,

Looking at your code:

long to_steps(float steps_per_unit, float units);
{
 return(steps_per_unit * units);
}

there shouldn't be a semi-colon on the end of the function definition. I'm assuming this is just a transcription typo for now, but it may indicate the code you are posting is not the same as giving the errors.

So, I made a simple program:

long to_steps(float steps_per_unit, float units) {
    return(steps_per_unit * units);
}

int main() {
    return to_steps(1.0, 3.5);
}

which compiles fine. Note, I wouldn't recommend using "long"; "int" is much more preferable in a standard C/32-bit world. So the function would look like:

int to_steps(float steps_per_unit, float units) {
    return (steps_per_unit * units);
}

The function multiplies two floating point values together, then (implicitly) casts them to an int(eger) as that is what the return type is - I assume that is what you were after? Other than this minor change and the semi-colon, it looks fine.

Your second code snippit looks fine too, except again it uses types "long" and "byte" (byte is not a C type). I'd change these to "int" and "char" and it should compile fine. int is the "generic" integer variable to use as a rule of thumb.

The error you are getting sounds like there is a mismatch of types somewhere, but i'm not sure it is these functions. Have a little more investigation, and see if you can find out any more. btw, the error messages say what file/line the error is on in case you had missed that.

Simon

Thanks for the reply,

I tried...

bool can_step(long current, long target)
{
 //stop us if we're on target
 if (target == current) 
    return false;
    else
    return true;
}

I get an expected ";" after the first {, If I place a semicolon after the end of the first line I get error E120 again? They need to be longs as they could be very long!

Cheers.

Mike.

Hi Mike,

If you get "expected ;" after the first {, that would make me suspicious that there was a bug in the code before you get to this function definition. i.e. something before "bool". Have a look before that and see if you are missing anything.

Michael Duffin wrote:
They need to be longs as they could be very long!

With a modern 32-bit processor/compiler, int will be at least 32-bits. In an 8 or 16 bit world, it is probably only 16-bits, and "long" (or "long int") is the way to tell it to be 32 bits.

Note:

For any general integer variables, especially to function arguments, I'd always recommend just using "int" as a rule of thumb, unless you have an explicit reason not to. That way code looks more consistent, and people will quickly pick up on the instances where the type is very significant (e.g. explicit storage size) rather than just a number.

When you are being explicit about bit sizes, a good approach is to use the stdint.h definitions which are things like int8_t (signed 8-bit), uint16_t (unsigned 16 bit) etc.

But this is details really and I wouldn't worry too much. The thing to look at in your code is what is causing the error - the compiler often can only pick up the error a little later in the code when the syntax breaks, so if it isn't obvious, try looking further up the code or even /* commenting out */ sections to see what you can remove to prove what is not causing the problem.

In this example, I suspect if you comment out your can_step function, it'll still moan, but on whatever comes after that function instead.

Simon