t vago's MPGuino workspace thread, continued

[skybolt]

I have a demo MPiGuino sled running with the Adafruit LCD/button shield. Much nicer having only two wires (in addition to power and ground) to contend with. I changed the two zener diodes to 2.1v to avoid frying the 3.3v Pro Mini and will be testing it in-vehicle today. Because the Adafruit buttons do not generate a hardware interrupt there is no 'wake on button press' so I will verify wake on start.



T_Vago: Does ODO/Scratchpad add a known value to current or tank mileage? Asked another way, can I input mid-tank values from one MPGuino to another, so that I can switch Arduinos mid-tank, maintaining my current tank distance and tank fuel used?

[t vago]

Originally Posted by skybolt

I have a demo MPiGuino sled running with the Adafruit LCD/button shield. Much nicer having only two wires (in addition to power and ground) to contend with. I changed the two zener diodes to 2.1v to avoid frying the 3.3v Pro Mini and will be testing it in-vehicle today. Because the Adafruit buttons do not generate a hardware interrupt there is no 'wake on button press' so I will verify wake on start.

Kewl! Let us know how it goes.

Originally Posted by skybolt

T_Vago: Does ODO/Scratchpad add a known value to current or tank mileage? Asked another way, can I input mid-tank values from one MPGuino to another, so that I can switch Arduinos mid-tank, maintaining my current tank distance and tank fuel used?

Not at this time. Guess I could add that as a compilable option, though, certainly, it would help with my own production/testbed MPGuino. Let me work on that.

[skybolt]

Obeservation: Adafruit LCD does NOT like being powered from the Pi while getting data from the Arduino, even with common ground. Works fine until power from the Pi is interrupted and re-introduced (like getting back in the car and powering up the Pi). This results in garbled output to the LCD, which can only be fixed by powering down the Arduino and powering backup. The real fix is to supply voltage from the 5v regulator stepping down car current for the Arduino, which is capable of supplying current to the LCD. But, if there's a "oh no I just got powered up, let's see if I can re-initialize myself" function on the LCD, you should add it to the bottom of the list. (It's possible the Pi can be forced to supply too much current to the LCD though it's 5v pin, cooking the Pi's regulator. If this is the case then the LCD must be powered via a separate regulator and then this is a non-issue).

[t vago]

Well, there's not a "oh no I just got powered up, let's see if I can re-initialize myself" possibility, as such. There is currently no way to tell whether the LCD got de-synched... Although I just thought of a possibility which might work.

In the meantime, you can force an LCD reset by cycling completely through the LCD brightness settings. Every time that "brightness 0" or "brightness off" is selected, MPGuino also forces an LCD hardware reset. I put that in a while back because every once in a great while, my own MPGuino display would get goobered up for no apparent reason.

[skybolt]

Adafruit shield working great, at least with debug readings. LCD init isn't an issue if LCD is powered from 7805, which works well. Warning: Do NOT use 12v input for Arduino Pro Mini 3.3v (even though the onboard voltage regulator clearly states 12v is acceptable). Fried many boards (regulator KB33).

Cannot compile 20170210 code, with #define useDebugReadings true enabled and #define useAdafruitRGBLCDmodule true enabled. (Your lines may vary as I added some LED blinking code to the JSON function so I could tell when the Arduino was active). Tried disabling #define useBufferedLCD true and #define useTWILCD true (in both locations including the define embedded in ifdef Adafruit ...).

I believe it's tied to your DevLCD code, which appears to be a placeholder for LCD code under development (like Adafruit!)

Compiler output:

/var/folders/cq/lyq3h1cs7pqf_5f_vbg2jwwh0000gq/T/arduino_modified_sketch_427538/_20170210_-_mpguino_1.94_tav.ino: In function 'void LCD::writeNybble(uint8_t, uint8_t)':
_20170210_-_mpguino_1.94_tav:7512: error: 'asLCDdelayTimer' was not declared in this scope
initADC(asLCDdelayTimer);
^
_20170210_-_mpguino_1.94_tav:7512: error: 'initADC' was not declared in this scope
initADC(asLCDdelayTimer);
^
_20170210_-_mpguino_1.94_tav:7516: error: 'analogState' was not declared in this scope
while (analogState & asLCDdelayTimer) idleProcess(); // wait for LCD timer delay to complete
^
exit status 1
'asLCDdelayTimer' was not declared in this scope

[t vago]

Originally Posted by skybolt

Adafruit shield working great, at least with debug readings. LCD init isn't an issue if LCD is powered from 7805, which works well. Warning: Do NOT use 12v input for Arduino Pro Mini 3.3v (even though the onboard voltage regulator clearly states 12v is acceptable). Fried many boards (regulator KB33).

Cannot compile 20170210 code, with #define useDebugReadings true enabled and #define useAdafruitRGBLCDmodule true enabled. (Your lines may vary as I added some LED blinking code to the JSON function so I could tell when the Arduino was active). Tried disabling #define useBufferedLCD true and #define useTWILCD true (in both locations including the define embedded in ifdef Adafruit ...).

I believe it's tied to your DevLCD code, which appears to be a placeholder for LCD code under development (like Adafruit!)

I just downloaded and attempted to compile the 20170210 code, with useDebugReadings and useAdafruitRGBLCDmodule enabled. It compiled successfully.

Can you upload here what you have?

[skybolt]

Let me try with a fresh copy of 20170210. In the meantime, here's what I am trying to compile:

[skybolt]

Line 276, I didn't have a board set --- needed to uncomment #define useLegacyBoard true, then it compiles without having debugReadings true. But, then the Adafruit LCD now longer shows any output, just 1 line of black boxes. If I take back out useLegacyBoard and put back in useDebugReadings, the Adafruit LCD works again.

So:
legacyboard = true + useAdafruit + debugReadings false = no display

Nothing set for board (all four board lines around 276 commented out) + useDebugReadings + useAdafruitLCD works, but only with debug readings.

Nothing set for board + useAdafruitLCD + debugReadings commented out = won't compile.

UseLegacyBoard + UseClassicLCD (sic) + debugReadings commented out = compiles and sends readings to the Pi (though possibly inaccurate readings, but that could be my 3.3v zener diodes)

Note: using an 8MHz Pro Mini, with board set to "Arduino Pro or Pro Mini". Arduino 1.8.1, with fairly recent bot not completely recent board definitions. (Last time I updated boards in Feb, lots of things broke).

[t vago]

#ifdef useAnalogLCDdelay
#define useAnalogInterrupt true
#endif // useAnalogLCDdelay

Move this block from line 576 of your code to line 607. Your code will compile successfully after you do this. What is happening is that, for the useAdafruitRGBLCDmodule #define, the useAnalogLCDdelay #define is getting set to true after the above processor directive is compiled. When this occurs, the analog interrupt handler section never gets compiled in, and since the analog interrupt handler section is required for generating LCD hardware delays, the compile fails as you have described. When the useDebugReadings #define is set to true, it masks this error.

Not sure how the Arduino digitalWrite functions will interact with the MPGuino code, but I do not think they'll be a problem.

[skybolt]

Great! Thanks - it tcompiles and I will test it in-vehicle shortly. I expect the instrument readings to be the same as using legacy code (which is giving me anomalous results, but again that is likely tied to the lower voltage zener diodes).

(Note: LCD is monochrome without bg color option - oh the tragedy of 1st world problems) ERROR - scratch that, LCD parameter was set to 99, from the old CONTRAST location. LCD color works great.

current settings and behavior:

276:
//#define useLegacyBoard true

294:
#define useAdafruitRGBLCDmodule true

cut code snipped from 576 and moved it to the new 607 (shifted 4 lines down from 612 after the cut from 576). Tried a few things (commented out 576, added it to 607, etc. - behavior seems consistent.