Surprisingly we are ok for RAM, its just flash space that is at its capacity.antus wrote:Do you find yourself doing lots of bit level manipulation? There are many sheets of 'bit hacks' out there which are great to optimize code in small embedded applications like this https://cheatography.com/jsondhof/cheat ... bit-hacks/ https://graphics.stanford.edu/~seander/bithacks.html
You might find you can save some bytes using smaller data types too - depending your coding style if your using 32 or 64 bit data bytes in places where you know the range would fit in a single byte (signed or unsigned) you can shrink the ram usage and the code that does the work with those variables by using smaller data types. You have to be careful though, its easy to get too excited and shrink something too far, and it can be difficult to find what you did. Make sure you use git for your code or something, so that you can divide and conquer if something like that comes up by running different firmware revisions to see where it was introduced and what you changed at that time.
I have honestly gone through every line of code to check for variable type sizes, and removed any unused functions. Its just the shear nature of bulk coding to support so many commands for both ELM and DVI sets.
Something thats a bit experimental but seems promising, is I have been reading about libraries can be 'precompiled' and used in projects to help save compiling time, or to ensure end users do not mix/match incorrect libraries.
What this means to me, is I could compile a library using the highest optimization settings, and then use that in the current project that does not have optimizations enabled.
If the ELM,DVI and protocol libraries could be compressed with optimization, then this would save many thousands of bytes without jeopardizing stability.
On other news, OBDXplorer has now been released. Theres a couple fixes already in the works:
1) Seems some laptops with bluetooth are hanging during the auto connect stage. Not too sure why this is occurring since it does not attempt to connect to any comport, only check the 'name' of the port so it only finds OBDX Pro devices. I will need to link something via bluetooth to produce a comport and see if that results in the same hanging.
2) Some PIDs may have the wrong size allocated. This results in logging setup procedure failing as the PCM recognizes the wrong size for the PID is used. This will require going through the supported list of PIDs and testing them out to see which fail to start.