[t vago]

Originally Posted by nickdigger

i can't see how adding buffer code takes less flash space than the standard routines. Just glancing at my .sym file, the total space used for all LCD functions is 448 bytes. Then again, i did optimize the fornication out of it, stealing Arduino library bits where needed, and dropping alot of overhead.

I can. My code does not use any sort of loop-based delay2() function, nor does it use any sort of microSeconds() function. When I attempted last night to completely remove the buffered feature, I had to add back in a delay2() and a microSeconds() and a microSecondsLength() function. That is what caused the bloat to occur.

I attempted again to remove the buffering earlier today, and only gained about 50 bytes. However, CPU utilization went way up, to around 20%, even with using the smallest possible delay with writing LCD bytes. No thanks.

My LCD code takes up 460 bytes, including the buffering.

Originally Posted by nickdigger

I'm also running on a 168, so ram is at a much higher premium for me. Probably not the case with your 328. I'm still trying to squeeze in SD logging (512 just for the buffer) along with my bar graph and speed range tabulator.

I have 1072 bytes of RAM free. I think I had about the same as was with the original 0.86 code. At one point, I had over 1300 bytes free.

Originally Posted by nickdigger

Also, by buffering the LCD output, aren't you really just hiding the true load, which could hit you on future addons?

Not really. Within each loop, all of the true processor-intensive things are done first. Calculating all 15 different output values across three different Trip class variables, windowing the instant.fuelEcon value to smooth out loop variations that occur due to the engine controller doing its OBDII cat monitor/O2 refresh thing, and sending out the serial raw logging data (which is also buffered) - these things really do not take up much time at all (about 2.2% per loop). Formatting and buffering the output values, as needed, takes an additional amount of time - anywhere from 1% to 6%. That amount of time is highly dependent on the particular screen being displayed.

The "true load", as regards outputting LCD characters, consists of waiting. If the code is waiting, then the code is not really doing anything useful.

After all of that is done, the program patiently just sits there and waits for a button press, or for the loop to end. I figure, since the program is anyway not doing anything meaningful during that time, it can process the buffering.

I'm strongly tempted to use the timer2 overflow interrupt handler to handle processing the LCD and serial buffers. If the overflow handler would process the buffer, then there'd be no need at all to worry about CPU loading due to outputting.