Release Two Workspace (/Fork name TBD)

[dcb]

Originally Posted by bobski

...
Wait... Hybrids are all OBD2, so shouldn't this info be available via the diagnostic port?

You tell me Could be some cars do, could be they all do, could be that none do. It doesn't look like a standard PID though, and the ones that do it may do it differently from each other.

I do know that being prepared to deal with any/all OBD protocols will take quite a few more pieces than reading a hall sensor.

As well reading the hall sensor can work anywhere there is electric current (and presumably can be in done the cpu with trivial additional component expense).

[FalconFour]

Balancing out the elements on the gauge screen, here's the new concept for the Instant (main gauge) display:

MPG I:24 C:26.2>
MPH35.2 MS20.33<

MPG "I/C" will be fixed on the display (and will be able to toggle between metric units in Preferences). Both MPH and MS2 (M/S² as I'm hoping to implement, probably as "MPS" instead, so the "2" doesn't get confused) will be selectable to choose a different data point to display in its place - the fun part was finding a way to fit 3-character descriptors on the display so they can be selected without display limitations (all parameters will have 3-character designations, like MPG, MPH, Gal, Mil, Hrs, etc). And each screen's config will be saved in EEPROM as well.

Now to figure out how to make digit display more flexible.

[bobski]

Originally Posted by dcb

Nice 'duino BTW. The EE department at my college just did a soldering workshop (a learn to solder kind of thing) using Freeduinos as the victims per my suggestion. It actually went remarkably well. Evidently, it was the first time (they've been holding these workshops for years) all the kits worked the first time they were plugged in... No troubleshooting and/or component replacement necessary.

[msc]

dcb, there is more then one way to skin a cat I'm not saying any one way is wrong. I made a suggestion I thought could improve the function and explained the reason behind it. If you don't like it then don't use it. I don't see any benefit to nit picking it further. Many of your points seemed argumentative rather then seeking to advance the technical discussion. I have the feeling if I try to address your comments you will reply with more argument. If there are any points you really want me to comment on I would be happy to address them.

Back to the point of the thread.

FalconFour, I think I sorted out your notations of flow but I don't have a good point of reference to base your interface changes on. I have been putting an MPGuino together based on an Arduino Nano board. I have it wired other then the input signal conditioning and have not gotten around to installing in the car yet. The 0.86 code seems to load and run with Arduino. I have cycled through the pages but I haven't even tried doing the setup yet so I have no experience using the instrument. It's hard to comment on changes to something I haven't really used.

Don't get discouraged by the minimal feedback. This sort of information can be difficult to get people to consider in detail and comment about.

There are a couple features I would like to see. Different people will use the instrument in different ways so many will want different sets of screens in the rotation. There should be a way to select which screens are in the rotation. This could either be by configuration settings or make it really easy to find and comment out the code for each screen.

The clock is near the top of my wish list for new features. A tach is another function I would like. When it comes to added signals I think the vehicle battery voltage stands out as both easy and useful.

To address some requests for auxiliary input channels a universal analog channel may be useful. This would be an uncommitted analog input channel that you can apply a gain and offset then display it. This could be used for the battery voltage or a wide range of sensors like current or temperature.

Mike

[FalconFour]

'S alright. Yeah, I'm working on making it as flexible as possible in all areas, particularly on the display. It's centered around a "main screen", the Instant figures, and allows you to cycle to different modes and menus to see the other data (tank, current, configuration, etc). Thinking of implementing a single button-press to "show this stat in big mode", when a figure is highlighted under the cursor, so anything can be made "big".

Right now I'm working on cross-referencing Arduino code with avr-libc code to kinda "reverse-engineer" MPGuino as elegantly as possible into standard Arduino code... there are a lot of cool and small Arduino functions that would greatly help the project, but the use of low-level AVR timer manipulations is reeeeallly messing up Arduino code and timings... so that's the biggest problem. I started writing out the main display routine but kept getting distracted by my inability to actually test it in the real code, so I've gotta solve that before I figure anything else out. Not very well versed in low level AVR registers like the ADC system (analog-to-digital), which seems to manage the button-inputs and whatnot. That's proving to be quite fun :P

edit: Found it... commented it... now need to figure out how to work around it.

	// turns off timer 0 overflow interrupt (breaks Arduino)
	TIMSK0 &= !(1 << TOIE0);
	// ok, done breaking things!

Most of the main() routines in MPGuino duplicate the efforts of Arduino's wiring.c library (part of its core that's compiled with every program). I've shaved off a number of bytes by "trimming the fat" and de-duplicating efforts, but I'm left with 3 lines that switch things around. Need to figure out how to implement these things in the existing wiring routines, because everything else seems to be pretty standard...

	TCCR2A = 1 << WGM20 | 1 << WGM21; // fast PWM mode for timer 2
	TIMSK2 |= 1 << TOIE2; // enables timer 2 overflow interrupt
	// turns off timer 0 overflow interrupt (breaks Arduino)
	TIMSK0 &= !(1 << TOIE0);
	// ok, done breaking things

[dcb]

Originally Posted by msc

dcb, there is more then one way to skin a cat I'm not saying any one way is wrong. I made a suggestion I thought could improve the function and explained the reason behind it. If you don't like it then don't use it.

I think I was saying option B would be the most pragmatic. If you want more realistic CDA, then use three button interface to enter temp/press.

Also, despite the uino postfix, the main project branch left arduino for reasons already stated, it is not a good fit (because of things like bloat and resources and another layer "designed by committee" lacking version control which introduces instabilities.

I would say (based on experience) re-introducing arduino code and dependencies is a mistake. You won't save any bytes at compile time and invite more version/library headaches. C/C++ is universal, spend some time with the datasheet and at avrfreaks.net. That is the way to fully utilize the chip, not by adding unstable one size fits all libraries in a foriegn language.

Learn the basics on arduino, but lose the training wheels as soon as you can

If it is your primary goal to remake it in arduino, then I cannot watch

[dcb]

Of course, something that might be entirely appropriate to prototype in arduino is a cda program (that hopefully runs on mpguino hardware). So that folks with a mpguino can swap in a CDA chip when they are doing aeromods.

If it plays nice with the rest of the code it could then be integrated.

[FalconFour]

Yeah, I'm finding Arduino can be kinda limiting... but for a guy that's never taken a microcontroller class in his life, it's not too bad. That's not to say I don't understand the goals and architecture of them, but I think it helps invite more people in by using modified Arduino as the platform.

Thankfully, I've already worked around the timer0/timer2 issue - I use timer2 as the event handler (and may even be phasing that out if I can find a way around it) and leave timer0 as the millis()/micros() source. I'm down to 6.2kb after removing the duplicate code and moving it over to Arduino, and that's with all the display and 64-bit math stuff too Just trying to build the UI now, though...

I'm having trouble with one thing, though. I want each display-mode (menus, subscreens, main screen, etc) to have "tab indexes", where each "tab index" is a byte in an array. The display routine will cycle through the "current tab index" array until the current cursor position (tab index selection) matches the current loop iteration, OR if it encounters 0xFF in the list (out of bounds, no cursor on display). Problem is, I can't seem to find an efficient way to set up this array so each display-mode-index is associated with a tab-list-index.

For example:

#define tabRow2 128
#define tabEnd 255
pFunc displayModes = { blah, blah, blah };
char displayTabs[][15] PROGMEM = { {0,2+tabRow1, 8+tabRow2,tabEnd}, {2,0+tabRow1,4+tabRow1,8+tabRow1,tabEnd}, {0,tabEnd} };
memcpy_P(displayTabs[1],currentTabs,15);

... obviously won't compile due to the varying size of the array being assigned to it, and memcpy_P takes a fixed amount (not stopping at null or 255). How can I make this work? :/

[bobski]

Originally Posted by FalconFour

I'm having trouble with one thing, though. I want each display-mode (menus, subscreens, main screen, etc) to have "tab indexes", where each "tab index" is a byte in an array. [...]

What would be the purpose of this structure? An LCD character-write buffer?

[dcb]

Originally Posted by msc

The clock is near the top of my wish list for new features...

I would point out that you can't swing a dead cat without hitting a clock. As well as it takes time/rom to sort out the interface for setting the clock, so what is the value proposition for adding a clock? Again, if you really do not already have a clock, the simplest and most pragmatic option is to reach into the nearest happymeal, then swallow any semblance of vanity you might have and hotglue it to your dash.



msc, a clock would be "nice" but I can't see replacing trip or instant mpg with it or other efficiency parameters. Of course it is open source so you don't need to talk about it, you can just do it and see if it sticks. Just post a patch in the wiki on how to do it. It looks like that is the boat I am in for cda and bsfc.