[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.