[t vago]

Originally Posted by skybolt

Thanks. I picked up a mega 2560 today as I couldn't find the relevant flags to get it to compile on any of my other boards. The goal for me is to use a pro mini -- see photog with current hardware, still more miniaturization to come. I was using a Pi 0, but the graphics were jerky -- I might still do something based on the Pi0 but the car interface board/shield will need to be redone for that form factor.

What programming environment are you using for programming your Arduino? I'm using the basic IDE, and telling it what board to use. If you're using anything else, you're going to want to tell your programmer to use an Atmel Mega328p to support your Arduino Pro.

Originally Posted by skybolt

Parallax LCD using a single pin is very attractive for portability -- does that mean the tx pin cannot be used for json output to the Pi? Or is it as straightforward as dedicating another pin for output?

Yah, pretty much. You could use a TWI bus LCD module instead, which would leave your serial TX pin free to use for the JSON output.

Originally Posted by skybolt

One more item: You aren't required to pass 3 values into the JSON file, n values from 0 to at least 10. I like to keep it simple, so it's 3 ranges for each, 2 measures for the first graph (total and bingo fuel remaining), 1 measure for the 2nd (reserve range) and 2 for the 3rd (trip, tank). (Measures are the orange bars), and a single marker for each (marker is the floating white bar).

I will adjust the colors, for some reason I left the 3rd measure white, which looks awful.

It's no big deal for me - I just want the MPGuino code to be able to handle being able to output whatever numbers are required for JSON (or any other conceivable) output.

Turns out that each regular number required five 64-bit divides to turn it into an output string. That'd be twenty 64-bit divides to display the numbers, versus between 4 and 8 for the actual value calculations themselves. Going to test some code tonight or tomorrow which will reduce that down to one 64-bit divide for regular numbers. That should give about an 80% speed improvement. CPU loading has already gone down from almost 102% before yesterday's experimentation, to about 63% after last night. I should hopefully see the CPU loading go down to about 13%. This will enable you to use 4 loops per second, instead of the current 2 loops per second.