t vago's MPGuino workspace thread

[Ardent]

I'm cringing a little at the blinking I/C/T special chars.

When briefly glancing at a display (which should be the case while driving!) it will be easy to miss the "illuminated" indicator.

Case in point: my solder station blinks the power LED when hot, and so I need to look extra long to verify it has been turned OFF as a quick scan can fall between blinks.

[Ardent]

While testing of the potential efficiency impact of some modifications, I found myself pondering the feasibility of a "TEST" page/screen.

On a relatively straight/level lightly-traveled stretch of highway here's what I was doing:

1. Heading in direction "A", accelerate to speed, set cruise, and then at "Marker 1", "RESET Current".
2. Upon reaching "Marker 2", attempt to read "Current MPG".
3. Turn around and write down "Current MPG". "Was that XX.63 MPG or was it XX.36 MPG?"
4. Repeat in direction "B".

Here's what I was envisioning:

1. Set MPGuino to "TEST" screen.
2. Heading in direction "A", accelerate to speed, set cruise, and then at "Marker 1", press Middle Button. MPGuino displays "Direction A/ START", then Instant/Current variables.
3. Upon reaching "Marker 2", again press Middle Button. MPGuino displays "Direction A/ STOP", then "Direction A/ XX.36 MPG".
4. Turn around, accelerate to speed, set cruise, and then at "Marker 2", press Middle Button. MPGuino displays "Direction B/ START", then Instant/Current variables.
5. Upon reaching "Marker 1", again press Middle Button. MPGuino displays "Direction B/ STOP", then "Direction B/ XX.63 MPG", Then "A/B Average = XX.495 MPG".

Advantages:

1. One button start/stop of test.
2. No need to write down results during test.
3. Auto averaging.
4. Multiple runs stored for recording later.

Potential Test Screen Setup:

• To enter: middle button long press
• Start/Stop recording MPG: middle button short press
• L/R buttons scroll through test results. "1A XX.36 1B XX.63 A/B Avg XX.495MG" "2A 2B" etc.
• long press M/R clears current test (bad run)
• long press L/M clears all runs.
• Exit test screen: middle button long press.

[t vago]

Originally Posted by Ardent

I'm cringing a little at the blinking I/C/T special chars.

I know... It was the only way I could think of to distinguish the I/C/T characters from the labels. I suppose I could keep them steady, or something... I'm open to suggestions at this point.

Originally Posted by Ardent

Here's what I was envisioning:

1. Set MPGuino to "TEST" screen.
2. Heading in direction "A", accelerate to speed, set cruise, and then at "Marker 1", press Middle Button. MPGuino displays "Direction A/ START", then Instant/Current variables.
3. Upon reaching "Marker 2", again press Middle Button. MPGuino displays "Direction A/ STOP", then "Direction A/ XX.36 MPG".
4. Turn around, accelerate to speed, set cruise, and then at "Marker 2", press Middle Button. MPGuino displays "Direction B/ START", then Instant/Current variables.
5. Upon reaching "Marker 1", again press Middle Button. MPGuino displays "Direction B/ STOP", then "Direction B/ XX.63 MPG", Then "A/B Average = XX.495 MPG".

Advantages:

1. One button start/stop of test.
2. No need to write down results during test.
3. Auto averaging.
4. Multiple runs stored for recording later.

Potential Test Screen Setup:

• To enter: middle button long press
• Start/Stop recording MPG: middle button short press
• L/R buttons scroll through test results. "1A XX.36 1B XX.63 A/B Avg XX.495MG" "2A 2B" etc.
• long press M/R clears current test (bad run)
• long press L/M clears all runs.
• Exit test screen: middle button long press.

This is a really good idea, and has a really good possibility of being implemented. In particular, I could combine the "Multiple runs stored for recording later" idea with my A-B display I've been tossing around in my head. I could probably fold the "store trips" code into this, too.

Gotta figure out how many EEPROM trip slots can be set aside for this.

[Ardent]

Originally Posted by t vago

I know... It was the only way I could think of to distinguish the I/C/T characters from the labels. I suppose I could keep them steady, or something... I'm open to suggestions at this point.

20x4 display? But seriously, I haven't been able to think of anything.

Originally Posted by t vago

This . . . has a really good possibility of being implemented.

That would be awesome!

Originally Posted by t vago

Gotta figure out how many EEPROM trip slots can be set aside for this.

EEPROM wouldn't need to be used would it?

[t vago]

Originally Posted by Ardent

20x4 display? But seriously, I haven't been able to think of anything.

20x4? Where's the puking smiley?

I can't even imagine the amount of code re-write needed to support a 20x4 screen at this point.

Originally Posted by Ardent

EEPROM wouldn't need to be used would it?

It's either put the stored run pairs into EEPROM, or make the test run feature here conflict with the "x" vs. speed graphs on the AtMegaX28 processors, due to RAM space limitations. AtMega2560 and AtMega32U4 processors would be able to handle the increased RAM usage. More than one run pair was implied above, each run pair would require two trip slots, and each trip slot consumes 40 bytes of RAM as it stands. The "X" vs. speed graphs use a common 15 slots.

[Ardent]

I didn't think about RAM space limitations since I'm only using half of what's available in my two 'guinos.

Perhaps, it could be an option for the larger RAM versions prior to your decision of how/if it could be slimmed down to fit the smaller RAM chips.

[josemapiro]

Originally Posted by t vago

I know... It was the only way I could think of to distinguish the I/C/T characters from the labels. I suppose I could keep them steady, or something... I'm open to suggestions at this point.

Maybe increase the time that premaneçe visible.

Originally Posted by t vago

20x4? Where's the puking smiley?
I can't even imagine the amount of code re-write needed to support a 20x4 screen at this point.

And for an 2x20 of this change not would be easier? Thus has 4 characters more in each line.
http://www.ebay.com/itm/Character-LC...item2eb84126d9

This is the problem of always wanting to improve, we are never pleased with it with what we already have, which is already excellent.

Thank you
José Rodrigues

[AndrzejM]

I think that implementing code for LCDs like 20x4 or 20x2 is not the best idea. First what about guys like myself who embeded LCD in the car and changing that would be impossible or very hard? Second thing is that putting too many information on the screen makes it harder to read. And we don't want our attention to go away for too long from the road ahead, don't we?
IMHO MPGuino's screen should be as simple as possible to get readings that we need within a blink od an eye. If we need some other info there are different screens that we can switch between.

Anyway I like Ardent's idea of A-B testing and I like new labels too.

I've tried to modify code to get temp reading but without success for now. I just need to understand code better. It's completely different from old metric version that I used to modify. ;-)

[josemapiro]

Originally Posted by AndrzejM

I think that implementing code for LCDs like 20x4 or 20x2 is not the best idea. First what about guys like myself who embeded LCD in the car and changing that would be impossible or very hard? Second thing is that putting too many information on the screen makes it harder to read. And we don't want our attention to go away for too long from the road ahead, don't we?
IMHO MPGuino's screen should be as simple as possible to get readings that we need within a blink od an eye. If we need some other info there are different screens that we can switch between.

Anyway I like Ardent's idea of A-B testing and I like new labels too.

I've tried to modify code to get temp reading but without success for now. I just need to understand code better. It's completely different from old metric version that I used to modify. ;-)

Ok, I thought it was simpler. My problem is that not much realize programming, which sometimes leads me to these situations.
Just have to apologize to t vago, which actually has been restless not only in draft MPGuino, as in putting up with me, which is not easy.
I am also of the opinion that a reading should be easy to avoid distractions on driving.

Thank you
José Rodrigues

[t vago]

Originally Posted by Ardent

I didn't think about RAM space limitations since I'm only using half of what's available in my two 'guinos.

I can live with either/or features. Heck, someone else here stated that the x vs. speed graphs were a gee-whiz-bang neat feature that really didn't add much value over the long run. I happen to agree with that. If that turns out to be a general consensus in the long term, then so be it. The underlying graphing code is still working, and can easily be adapted to other features, without having to tie it to the x vs. speed graphs. That, in my opinion, is worth more than the x vs. speed graphs the code was originally designed to support.

So, what do you think? 4 total saved run sets? That should be enough run sets, and it only adds two more slots to what is being stored in EEPROM (now at 1 current, 1 current idle/EOC, 1 tank, 1 tank idle/EOC, and 6 "expansion" slots). Combine that with the "current" run set that would be stored in RAM, and you have a total of 5 different run sets.

Originally Posted by josemapiro

Maybe increase the time that premaneçe visible.

That might could work. Or, maybe have these blinking special characters appear for 1.5 seconds, then disappear for 0.5 seconds.

Originally Posted by josemapiro

This is the problem of always wanting to improve, we are never pleased with it with what we already have, which is already excellent.

Thank you. With the help of everyone in this thread, it has (and will continue to be) better and better.

Originally Posted by AndrzejM

I think that implementing code for LCDs like 20x4 or 20x2 is not the best idea. First what about guys like myself who embeded LCD in the car and changing that would be impossible or very hard?

This is why I made it a requirement that any code I added would still have to run on legacy hardware, even if the code will also support better or more advanced hardware. This is why I am not currently thinking of supporting anything other than a 16x2 LCD display.

Originally Posted by AndrzejM

Second thing is that putting too many information on the screen makes it harder to read. And we don't want our attention to go away for too long from the road ahead, don't we?

You're talking to a 'Murrican here. We thrive on paying attention to every other bloody thing, instead of actually paying attention to the road! (ugh...)

Originally Posted by AndrzejM

I've tried to modify code to get temp reading but without success for now. I just need to understand code better. It's completely different from old metric version that I used to modify. ;-)

Yah, the code changes saved a lot of code space, and it makes it a lot easier to follow debug traces of 64-bit math processes, but it takes some fair amount of effort to understand. Not really that hard if you have some background in assembly language programming. However, that's the key phrase - "assembly language programming."

Also, I've remembered that NTC-type sensors (like thermistors that are generally used in engine coolant temperature sensors) don't exactly follow a linear relationship. That's going to make it a challenge to program in "universal" sensors.

Originally Posted by josemapiro

Ok, I thought it was simpler. My problem is that not much realize programming, which sometimes leads me to these situations.

The trouble is, programming is actually simple (at first). However, as programs get more and more complicated, simple things, like supporting different displays, themselves get more complicated.

Originally Posted by josemapiro

Just have to apologize to t vago, which actually has been restless not only in draft MPGuino, as in putting up with me, which is not easy.

You have made the extra effort here, josemapiro, just by trying to talk here without knowing English as your mother tongue. Don't worry about it. Your efforts were key in having MPGuino now able to run on an AtMega 2560.