[t vago]

Originally Posted by skybolt

Regarding metric: it crashes while running --- but otherwise takes? So live data is lost .... I'm not really asking, I'll check the behavior ...

I solved the crashing behavior - it was affecting changing any parameter, not just metric mode. It was due to a bug in the post-parameter-saving display output initialization that I was able to provide a stable workaround for.

I did, however, find another bug that is specific to setting metric mode - the metric parameter conversion routine no longer seems to work at all. That is, distances are still given in miles and fuel quantities are still given in gallons, for instance, when metric mode is active. It's very strange.

Originally Posted by skybolt

I'm fairly certain calling the LCD or writing the JSON output takes longer than any of the primary functions, but I haven't measured yet (it's fairly easy to measure using a quick millis() check) --- If I'm correct, then 38.4 should be plenty fast. Let me run a quick calculation:

json file is about 579 bytes, depending. 38.4bps is 4,800Bps, so about an 8th of a second or 125ms to send the payload. the javascript routines on the Pi are set for 100ms by default, adding a total delay from real-time to .225 per second.

No, the buffered LCD or JSON serial output actually provides fairly quick response. Rather, the nature of SWEET64 being a generalized pseudoprocessor for maximum flexibility, also makes it very slow.

Originally Posted by skybolt

In order to accurately measure acceleration functions the standard loop delays needs to be suppressed. I will have more questions about how to deal with LCD delays ... but all in good time.

The loop delay ( ... delay(500); ... ) was something I got rid of, early on. It offended my tender sensibilities.

Delays are now handled by the primary timer, with a tick of about 1 ms. (I say "about" because a 20 MHz MPGuino actually has a 0.8125 ms tick, and the 16 MHz MPGuino has a 1.024 ms tick). The primary timer cycles down a counter from a preset value to generate a 500 ms wait (which is why processor speed is specified early on in the code). Once the counter goes to zero, the main timer sets a flag bit to signal the main loop to do its display update.

The main loop delay "routine" is now little more than the main loop staring at that flag bit that is set by the primary timer, performing its display updating when that flag sets, clearing that flag, and setting another flag to let the primary timer know it should perform another loop delay.

The accel test function uses a similar mechanism, except that 4 flag bits are used instead of just one. There's a target speed bit, target distance bit, an active bit, and a cancelled bit. This enables the code to sense if many separate conditions arise which would cause the accel test function to cancel, like if the vehicle engine were to stop, or if the vehicle speed dropped back down to zero.

Originally Posted by skybolt

Also, I notice you support the tinkerkit LCD ... does the tinkerkit use fewer pins than the standard method of using 8 (+ 1 for contrast and 3 grounds) wires to connect to the LCD? Both Adafruit and Osepp have shields that claim to use 2 pins to connect to soft buttons and LCD. The soft buttons are irrelevant here but using 1 or 2 pins for LCD communication would make it very easy to attach an LCD for programming and detach it for a small footprint.

Yah, the code is able to turn a Tinkerkit LCD module into a standalone MPGuino. It just needs a few components to interface to the VSS and the fuel injector signals, and a few more components for the switches. Internally, the Tinkerkit LCD module uses the same LCD hookup as the legacy MPGuino (4 bits, plus one for contrast and one for brightness). It uses different pins, though, and my code does not yet support the USB functionality of the Tinkerkit LCD module. I don't think the Tinkerkit LCD module has a serial port, but I remember that it does have an I2C bus.

I am currently using a Arduino Mega2560 as the test platform, which has two serial output ports. One port is being used by a Parallax serial LCD module which uses the serial tx pin, and the other is being used by the JSON output routine. Here's a three-year old video showing the setup.