t vago's MPGuino workspace thread

[t vago]

Originally Posted by josemapiro

I've been testing the Multiplexed Analog buttons, and it works but not correctly, the first and third seem to do the same functions

Do you mean that pressing the 1st button does the same thing as pressing the 3rd buttton?
Edit: Also, please make sure to check this post - link - This should fix problems with the code not correctly recognizing button presses.

Originally Posted by josemapiro

, as the middle button only changes the brightness,

The middle button behaves as it should, then. The middle button is supposed to cycle through brightness settings in most modes, and it should cycle through digits when in settings change mode. If you press (precionar?) and hold down the middle button for a second or so, it should display the CPU loading.

Originally Posted by josemapiro

and pro comportace times as the first,

I do not understand - sorry.

Originally Posted by josemapiro

the extra 1 to precionar appears (btn 8 pressed), the extra 2 has not tested because had no 47k resistance.

Yah, that's supposed to happen. The "extra 1" and "extra 2" buttons have not yet been defined to do much of anything in the code, other than have the code say "Button xxx pressed". Eventually, I was going to figure out whether to have 4 arrow keys with a center "enter" button, or buttons that were configured such as for the ScanGauge II.

Originally Posted by josemapiro

What is the tolerance of the resistors you used? I'm using resistors with 5% tolerance.

Mine are 5% tolerance, too.

Originally Posted by josemapiro

I think the problem I'm having now, has to do with the values ​​that each sends resistance, which may vary slightly and complicate the whole process, but at least I can see the system moving.

That's a start. We can work from there to debug this, if there is a bug.

[Ardent]

Originally Posted by josemapiro

I think the problem I'm having now, has to do with the values ​​that each sends resistance, which may vary slightly and complicate the whole process, but at least I can see the system moving.

You should be able to monitor the values that the Arduino sees by adding something like the following where "X" corresponds to the analog pin being used:

Serial.print("adcX = ");
Serial.println(adcX);

. . . and then open the Serial Monitor.

[t vago]

I recommend this:

//#define useSerialPortDataLogging true	// Ability to output 5 basic parameters to a data logger or SD card
//#define useBufferedSerialPort true		// Speed up serial output
...
#define useSerialDebugOutput true

...

	pushHexWord(analogValue[2]);
	pushSerialCharacter(13);

...

then, just re-comment them, once you're done.

[Ardent]

I tested the button code change and it doesn't seem to address the glitch I'm seeing.

I have figured out the usage scenario where it crops up and a usage workaround though.

• If a different button is pressed, it must be pressed slowly to not register as the same button press.

It is particularly noticed when changing settings. When pressing a different button, a slow (~0.25s) press is required. If just "clicked" the click is registered as the previous button pressed.

To reproduce:

1. Press LEFT+RIGHT to enter settings.
2. Slow click (~0.25s+) the RIGHT button.
3. Next, a "quick-click" to either the MIDDLE or LEFT button changes to the next screen that should display by pressing the RIGHT button. This continues indefinitely unless the "click" is slowed to a "press".

[t vago]

I duplicated the effects of this bug, according to Ardent's instructions. It appears to be a fairly serious bug with the debouncing code. The bug does not appear to care whether analog or traditional buttons are configured.

I'll take a look at it, either tonight or tomorrow.

[josemapiro]

Originally Posted by t vago

Do you mean that pressing the 1st button does the same thing as pressing the 3rd buttton?
Edit: Also, please make sure to check this post - link - This should fix problems with the code not correctly recognizing button presses.

Had already done this fix.

The middle button behaves as it should, then. The middle button is supposed to cycle through brightness settings in most modes, and it should cycle through digits when in settings change mode. If you press (precionar?) and hold down the middle button for a second or so, it should display the CPU loading.

I do not understand - sorry.

Very rarely when you press the middle button it does not alter the brightness, and showed the same sequence that shows when pressing the left.

Yah, that's supposed to happen. The "extra 1" and "extra 2" buttons have not yet been defined to do much of anything in the code, other than have the code say "Button xxx pressed". Eventually, I was going to figure out whether to have 4 arrow keys with a center "enter" button, or buttons that were configured such as for the ScanGauge II.

Why not use a system of 3 or 5 buttons, but with a different operation, stop using the buttons on the left, middle and right, and move to using a (top), (bottom), (OK), (yes) and (no).
The operation would be to (top) advance the menu to (bottom) retreat, and (OK) defined the choice, in some menus might be used (yes) and (no) to confirm the choice.

then, just re-comment them, once you're done.

The results I got were:
Without pressing any button the result was: 03FF
Pressing the left: 02BC and 02BD or 02BE
Pressing the middle button: 034D or 034E and 034F
Precionando right: 03A2 or 03A3 and 03A4
Pressing the extra1: 03D3 or 03D4 and 03D2
Extra 2 still have no results.

Thank you
José Rodrigues

[josemapiro]

Originally Posted by Ardent

I tested the button code change and it doesn't seem to address the glitch I'm seeing.

I have figured out the usage scenario where it crops up and a usage workaround though.[LIST][*]If a different button is pressed, it must be pressed slowly to not register as the same button press.

Probably is the same mistake that I mentioned with the middle button, causing it to behave as the previous button.

[Ardent]

Thanks for checking; hopefully it won't be too onerous to fix.

[t vago]

I hope so, too. I found what I believe to be the problem, and have substantially re-written the debounce code to correct the problem. I will be testing the fix tonight, when I get back to my test MPGuino hardware setup.

[t vago]

Got the button press debounce fix working. (current MPGuino code version is at first post of this thread)

Debounce timing adjustments may be made by adjusting the following two lines in the code.

const unsigned int keyDelay = (unsigned int)(t2CyclesPerSecond / 256ul);
const unsigned int keyShortDelay = keyDelay - (5 * keyDelay / 100); // wait 5/100 of a second before accepting button presses