Quote:
Originally Posted by nickdigger
FWIW, i did the calc-data-once thing, hoping to save resources, but it ended up wasting program space (plus the extra ram for the variables), so i de-changed it
|
Unfortunately, the calc-data-once code changes I made are a necessary part of being able to provide editable display screens. Without them, it becomes a nightmare of providing an array of class procedure pointers, with all of the fun that implies.
My code was actually about the same size as the 0.86 code was, for a few weeks. It took adding the ability to save/load/view trip data in multiple EEPROM slots, and the actual screen editing code, to cause my code to bloat out. At that, most of the bloat is text strings.
Quote:
Originally Posted by nickdigger
I've also gotten my cpu load down to 3-5% on a 4x20 LCD, just by tweaking the LCD routines to meet the spec. The killer is delay2 (5 milliseconds) in LcdCommandWrite. It only needs to be 120 microsec. That should eliminate the need for that buffer you added.
|
I never did really look into tuning the LCD hardware support. This would be worth a couple hundred bytes of program space, and about 100 bytes of RAM.
Quote:
Originally Posted by nickdigger
BTW, replacing "sei" with "sreg=OLDsreg", as you recommended in the Chrysler thread, seems to have stopped my weely T2-overflow crashes. Thanks again!
|
No problemo. Nested interrupt bugs are a royal PITA to debug. The best way to debug them, IMO, is to prevent any possibility of having nested interrupts in the first place.