t vago's MPGuino workspace thread

[t vago]

Okay, here it is. The code was developed in a standalone text editor, was compiled using Arduino 1.0.5, and uploaded to my MPGuino JBD hardware via a Pololu AVR ISP V2 USB programmer.

Let me know of any thoughts or concerns.

Remember, the code is dependent on the clock speed of your device, so be sure to comment out/in the appopriate lines near the beginning of the file. 16MHz (not tested) and 20 MHz clocks are supported.

I'm thinking of getting rid of the buffered LCD code. The existing code really doesn't benefit all that much from it, any more.

Also thinking of being able to revert a stored EEPROM parameter or screen setting to the "factory" hard-coded default, via keypress.

Also thinking of allowing editing of stored trip values.

And, of course, the Chrysler correction factor code is still a work in progress. However, for the vast majority of y'all, that's not a concern.

Edit: Bloody! Wouldn't you know it? Already had to correct a typo. The Screen Editor should work now.

Edit 2: *facepalm* Corrected another typo - Screen Editor and Trip Save should correctly save to EEPROM, now.

Edit 3: SMH - Should have released the code tomorrow. Fixed typos related to EEPROM storage for the serial enable and the bargraph period stored settings.

[t vago]

Short and sweet instructions:

For the main screen,

Left button - go left one screen
Right button - go right one screen
Long-press left - go left to next screen group

• if at any trip value display, goes to system clock
• if at system clock, goes to tank time-to-empty large number screen
• if at tank TTE large number screen, goes to bargraph
• if at bargraph, goes to system information
• if at system information, goes to tank average fuel economy large number screen
• if at any fuel economy large number screen, goes to last (of 8) trip value display screen

Long-press right - go right to next screen group

• if at any trip value display, goes to instant fuel economy large number screen
• if at any fuel economy large number screen, goes to system information
• if at system information, goes to bargraph
• if at bargraph, goes to tank TTE large number screen
• if at tank TTE large number screen, goes to system clock
• if at system clock, goes to first (of 8) trip value display screen

Short-press left and right -

• if at system clock, goes to System Clock set mode
• if at any other screen, goes to Stored Settings Editor

Long-press left and right -

• if at a trip value display screen, goes to Trip Screen Editor
• if at any other screen, displays "FAIL" for 2 seconds

Short-press left and center - Goes to Trip Save mode, centering on Tank Trip save
Short-press right and center - Goes to Trip Save mode, centering on Current Trip save
Long-press left and center - Resets Tank Trip
Long-press right and center - Resets Current Trip
Short-press Center - cycles through Brightness
Long-press Center - displays CPU loading for selected screen, for 2 seconds

Other screen modes use the following rules (or are supposed to, anyway):
Short-press left - cursor or screen left
Short-press right - cursor or screen right
Short-press center - change digit or trip slot
Long-press center -

• in Trip Save mode, performs selected action
• In all other modes, save value being edited

Short-press left and right - go back one mode
Long-press left or right - Revert edited setting back to saved, or go back one mode

[nickdigger]

Also thinking of being able to revert a stored EEPROM parameter or screen setting to the "factory" hard-coded default, via keypress.

I put this at the top of loadParams():**

  if (RightButton)
  {
    buttonState = buttonsUp;
    return 1;  // don't load parms from eeprom; use default compiled parms
  }

There's a similar check for LeftButton, to reset the saved tank data in the eeprom. The "prompt" for these hidden key features is the "MPGuino" startup screen, which gives you a 1.5 second delay to press (and hold) the key.


** i later removed the option, out of paranoia that i would accidentally clear my settings

[AndrzejM]

Thanks T_Vago! Hopefully I'll test it soon. Of course with a proper feedback

[nickdigger]

Also, you should assign a higher version number (1.00tav? 0.98tav?) It certainly is a full step above and beyond the base. 0.86 might mislead someone to think that flashing your code would be plug-and-play. At a minimum, the stored params will be corrupted.

[AndrzejM]

Originally Posted by nickdigger

Also, you should assign a higher version number (1.00tav? 0.98tav?) It certainly is a full step above and beyond the base. 0.86 might mislead someone to think that flashing your code would be plug-and-play. At a minimum, the stored params will be corrupted.

Fully agree

[t vago]

Originally Posted by nickdigger

Also, you should assign a higher version number (1.00tav? 0.98tav?) It certainly is a full step above and beyond the base. 0.86 might mislead someone to think that flashing your code would be plug-and-play. At a minimum, the stored params will be corrupted.

Yah - probably should change the version #. 1.86tav!

Interesting. My stored parameters go away each and every single time I reprogram my MPGuino. I had assumed this would happen for anyone. Maybe not, hm?

Probably should also change the guinosig byte to something else, especially because the code does change the number (and size) of stored parameters based on what features are compiled in.

[t vago]

Found another couple of typos from modifying the code to be configurable.

The first typo will (and does) cause the bargraph display to increment in 1/2 second increments, regardless of what the stored bargraph period is set to.

What is there:


What it's supposed to be:


The second error concerns the amount of storage space allocated to the window filter stored parameter.

Both have been fixed.

[t vago]

Took an idea from nickdigger, and re-wrote the display value calculation routines on an as-needed basis, instead of calculating everything at once. Had to re-write the fuel economy window filter routine, but that wasn't hard. Compilation of the core code resulted in a 12998 byte program. We'll see if it works. Hopefully, I will have freed up around 216 bytes of RAM.

[AndrzejM]

It's getting better and smaller, running faster using less resources. That's the spirit of hypermilling