Quote:
Originally Posted by skybolt
I'd have been happy to do the drag race code --- I'd have followed your syntax for the other functions ... once you have that done I'll make improvements to the drag function as follows:
1. rename to acceleration stats
2. Add second line to display (subtitle) to list fuel statistics for accel. This makes the drag useful to all users, as hypermilers will want to know how much fuel it takes them to reach cruising speed, or how much fuel to cover the first n feet/meters.
3. Update distance to show hundredths of miles in decimal format, then feet. Supress showing feet until n mph/kph
4. Update all json functions to be metric/imperial friendly.
5. Add serial config utility (I will hijack the LCD display routines to mirror that over serial, add a cursor designator so that 802576 with a blinking 2 on the LCD will appear as 80_2_576. This will allow serial config using the three main buttons.
This will take me some time, but will pay dividends in the long term. Also, I have new name for the project, it's obvious but it fits. "MPiGuino"
Question: is there a global call for metric/imperial designator? i.e., can I call "units" and have it return miles, mph vs km, kph. If this is obvious in the code I will find it.
|
There's no global procedure call for "metric or US". Whenever the driver changes between US or Metric, the code goes through all of the EEPROM parameters that require conversion, and performs the necessary unit conversions. There's an accessible global flag that indicates whether US or metric mode is active, and there's a SWEET64 pseudoinstruction that branches on the state of this global flag. This is mainly used by the prgmFuelEconomy routine, since the US MPG and the metric L/100km are reciprocated.
I figure as long as people can recognize it as having roots with "MPGuino," then I would think that "MPiGuino" should work. The original MPGuino author hasn't been seen in many years now.
1. Yah, "Acceleration Stats" sounds better than "drag race" or "drag function."
2. I'll have to re-write #2 a little bit to measure fuel usage. I had repurposed the fuel measurement elements of the one trip variable set aside for acceleration measurement. Not a big deal, though.
3. Intriguing. I suspect you'll have to do something similar to what I had to do for autoranging the decimal point format function.
4. Has already been done, in a manner of speaking. The code fully supports metric/US measurements, including performing parameter conversions when metric or US measurements are selected.
5. Sounds very doable, but will take a lot of work.