Advisory for Chrysler Returnless Fuel Supply Systems

[josemapiro]

Originally Posted by nickdigger

That's easy for you to say, Jose, with your 16 Analog & 53 Digital I/O =)
I am going to try it though.

Yes I know, that was the reason that made me buy the arduino mega, not want to be limited, and as the price difference between the Uno and Mega was small opted Mega.
Your idea is possible, but you have to change the code so that it is not necessary to press two buttons at the same time, perhaps the solution that the t vago uses in its code, solve this problem by using the time you press the button .

José Rodrigues

[t vago]

Actually, I did a little Excel thought experiment last night, playing with a simulation of 4 buttons using varying resistances. It turns out that it is certainly possible to read 16 different values, and Chrysler actually used to do that with the cruise control buttons. However, how would resistor tolerances be addressed, as resistances change with temperature? Or is this even a concern?

[nickdigger]

re: resistor tolerances

Ideally, the difference between button resistances will be great enough to account for that. The pseudo-code in my head does not translate a precise microvolt reading to a particular button sequence, rather, a "range" will be tested:
if (level < LeftOnly) buttonState= LeftButtonBit;
else if (level < LeftMiddle) buttonState = LeftButtonBit | MiddleButtonBit;
else if et cetera . . .
else buttonState = buttonsUp;

The voltage levels would be stored in a PROGMEM array. After the VoltageLevel-to-ButtonBit conversion has happened, the rest of the button code should work as is. Eh, except for using the PINC interrupt as a trigger. We would simply read the voltage level at every timer2-overflow ISR, to detect a level change. I guess that would nullify your Sleep Mode thing, unless it's possible to use the Analog Comparator as a trigger. This is new to me.

This should probably be set as a compile-time option in the code, as 90%+ mpguino owners will not want to rewire their units. Too bad this wasn't suggested and implemented from the beginning. Understandably, analog inputs and other hardware expansion were not on anyone's mind, when getting the basic Injector-Capture system working was a huge achievement in itself.

[t vago]

Originally Posted by nickdigger

The voltage levels would be stored in a PROGMEM array. After the VoltageLevel-to-ButtonBit conversion has happened, the rest of the button code should work as is. Eh, except for using the PINC interrupt as a trigger. We would simply read the voltage level at every timer2-overflow ISR, to detect a level change. I guess that would nullify your Sleep Mode thing, unless it's possible to use the Analog Comparator as a trigger. This is new to me.

Well, my code really doesn't have a sleep mode, as such. The code just tells the main program when the activity timeout occurs, so that the main program displays the system clock instead of whavever screen happened to be displayed before the activity timeout occurred.

But, yah, you could position the analog read inside the master timer (timer2 overflow) interrupt. That's what my code already does, anyway, with button debouncing. The PINC interrupt says that pins changed, and the master timer handles the debouncing and long-press detection.

Originally Posted by nickdigger

Too bad this wasn't suggested and implemented from the beginning. Understandably, analog inputs and other hardware expansion were not on anyone's mind, when getting the basic Injector-Capture system working was a huge achievement in itself.

Yah, tell me about it. A few times, I wanted to mention the same thing, particularly with the LCD hardware choices that were made. Would have been nice to have stuck all of the LCD data bits onto one port, for instance; or to be able to read from the LCD hardware in addition to writing to it.

[nickdigger]

My inactivity works the same way, only i track the timeout inside the main loop(). First, it shuts off the backlight at 2 minutes, then at 7 minutes it goes to the screensaver (just a clock for now, later i'll add Battery voltage and ambient air temp)

Why would you want to read the LCD?

[t vago]

Originally Posted by nickdigger

Why would you want to read the LCD?

Why, in order to be able to tell for certain when it is ready for another byte. I figure, if the LCD datasheet has this option, might as well use it. Not that it really would add that much of value...

[nickdigger]

Using the datasheet's wait time works pretty well. I suppose you could also do something crazy, like use the user-def character space for off-board, low-speed RAM, i.e., when you're not printing custom Big digits.

[josemapiro]

First of all, thank you for his work that fantastic, I have not tried using it on my board, but will test soon as I can.

Originally Posted by t vago

Actually, I did a little Excel thought experiment last night, playing with a simulation of 4 buttons using varying resistances. It turns out that it is certainly possible to read 16 different values, and Chrysler actually used to do that with the cruise control buttons. However, how would resistor tolerances be addressed, as resistances change with temperature? Or is this even a concern?

If you succeed it to work the buttons optimal, before I tried several options, and when he had to press more than one button at the same time, I always had some failed, for the value to be very near each other, but maybe I have only tried with the combinations that did not work, when I should have worn that worked. LOL

Thank you
José Rodrigues

[t vago]

Did you try with the same resistance values for each button, or did you try different resistances for each button?

[josemapiro]

Originally Posted by t vago

Did you try with the same resistance values for each button, or did you try different resistances for each button?

Tried with equal values ​​and also with different values​​, but the possible combinations are many, and not tried everything, I limited myself to a bit values ​​of resistances that had available.