View Single Post
Old 08-15-2013, 09:59 PM   #5 (permalink)
t vago
MPGuino Supporter
t vago's Avatar
Join Date: Oct 2010
Location: Cedar Rapids, IA
Posts: 1,766

The Karen-Mobile - '05 Dodge Magnum SXT
Team Dodge
90 day: 26.72 mpg (US)

Fiat Dakota - '00 Dodge Dakota SLT RWD Quad Cab
90 day: 16.67 mpg (US)

The Red Sled - '01 Dodge Durango SLT 4WD
90 day: 16.96 mpg (US)
Thanks: 799
Thanked 681 Times in 437 Posts
Originally Posted by nickdigger View Post
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.

Originally Posted by nickdigger View Post
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.

Originally Posted by nickdigger View Post
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.
The Fiat Dakota

The Karen-mobile

The Red Sled
  Reply With Quote