I'm close to the limit of sketch size for an Arduino Pro mini: 30678 bytes.
I have yet optimized the code, but I told to myself "maybe you can do something more!".
So I have found a bunch of code repeated in more functions of one object . The code is just extracting a substring from an array of chars and decoding it from hexadecimal chars into an integer value.
So I created a common hexToInt() function and applied it inside 3 functions (pardon, methods) of the object, erasing the preexisting code.
The resulting compiled sketch size is greater than before: 30708
Why? :o
/*
* Parses a sequence of hexadecimal char to an integer value.
* Returns zero if succesful, a no-zero value otherwise
*
* message: the input string, it must be terminated with '\0'
* start: the index from which start to parse
* length: the number of char to be parsed
* value: an integer pointer where the result has to be stored
*/
int ELM327::hexToInt(char* message, int start, int length, int* value)
{
if ((length > 4 ) || (strlen(message) < (start + length)))
return PARSE_INT_ERROR;
// copy the substring to a buffer
char buffer[5];
memcpy( buffer, message+start,length );
buffer[length] = '\0';
Serial.println(buffer);
// convert the buffer contents to an integer
char *endptr;
*value = (int) strtol(buffer,&endptr,16);
// nothing parsed? (See strtod/strtol docs)
if( endptr == buffer)
return PARSE_INT_ERROR;
else
return 0;
}
(Yes, the function has 3/4 lines of codes more than original code to make it more elegant and error-free. Nevertheless, I should observe lower size... or not?)
Try not to imagine that you are smarter than the people who write compilers, particularly if you have to ask questions like this.
I don't think you've given enough detail to say the exact problem, but I'm going to guess the code to put the functon parameters in place could be a problem
The compiler may already be optimizing that code down, and you've just introduced some additional overhead by making it a function (maybe some type conversion is happening?) - the link time optimization now enabled on Arduino IDE is pretty aggressive.
You can bootload your Pro Mini as an Uno, or using MiniCore's generic 328p board def (after doing so, you need to select those boards when uploading) - these use a 512 byte bootloader, getting you an extra 1.5k of usable flash.
CtrlAltElite: Try not to imagine that you are smarter than the people who write compilers, particularly if you have to ask questions like this.
Never said that in my post. If you read those things in my question then your fantasy is running like a crazy horse.
CtrlAltElite:
I don't think you've given enough detail to say the exact problem, but I'm going to guess the code to put the functon parameters in place could be a problem
I'm just trying to follow the "golden rules" reported on this forum when attempting to reduce the code size.
One of this (among 11 other ones) rules state: "group your code and reuse it".
Beyond my special case, I would like to know why (sometimes) this rule doesn't work. Also, I would like to know if is happening to other people than me.
I'm not going to criticize the creators of the compiler, the same I would like to know, for sake of personal curiosity, why sometimes the compiler increases the size. It depends from the type the parameters? From the internal functions called?
DrAzzy:
The compiler may already be optimizing that code down, and you've just introduced some additional overhead by making it a function
Yeah, it can be. So you confirm that this behaviour of the compiler "can happens", yes?
DrAzzy:
the link time optimization now enabled on Arduino IDE is pretty aggressive.
I read somewhere that the default compiler option used by Arduino IDE is the "-Os" one. That is trying to compact the code as much as possible.
DrAzzy:
You can bootload your Pro Mini as an Uno, or using MiniCore's generic 328p board def (after doing so, you need to select those boards when uploading) - these use a 512 byte bootloader, getting you an extra 1.5k of usable flash.
Sounds intriguing... any link for further info? Anyway, I will goggle it. Thank you! 8)
I would like to know why (sometimes) this rule doesn't work.
The compiler will optimize function calls, especially to short functions by "in-lining" the code multiple times instead of creating an actual function and function calls. Yes, even when -Os is specified and this results in slightly bigger code - as near as I can tell, gcc makes the "inline" decision based on an intermediate code representation of the program, so it gets fooled on an 8bit cpu where sometimes a+b is 4x more instructions than other times.
In this case, you haven't shown us the original code, so it's hard to say whether that's happening, or whether your new code is just bigger than the old code (or causes new secondary functions to get pulled in to your image.)
It's hard to say without seeing the original code. The sure way to see what is going on would be to put some debugging statements into the code, or look at the generated assembly.
