PDA

View Full Version : ADC keyboard and fast response to user input, possible?



CuriousOne
- 27th June 2020, 22:29
I have and ADC input and two resistor network driving it, so when no button pressed, adc reads 255. On button 1 it returns 128 and on button 2 it returns 0.

Both buttons are used to control same variable value, one increases it, another one decreases. User can either keep button pressed for variable to change, or use short presses to change it. The problem is that when user keeps button pressed, value should not increase too rapidly, user should be able to see changes on display and react in time. Very basically, code looks like this:



MAINCODE:
ADCIN 0,X
IF X=128 THEN Y=Y+1
IF X=0 THEN Y=Y-1
GOSUB DISPLAY
PAUSE 100
GOTO MAINCODE


This works fine if user presses button and keeps holding it - pause 100 statement ensures that variable does not change too fast. But here comes the problem - if user uses short press, he might press it right during PAUSE 100 statement, there will be no response from the system, so it will appear to him as lagging.

The obvious fix would be to add a loop, and move PAUSE statement into it, with lower value, to reduce the lag, like this:



MAINCODE:
FOR Z=1 TO 100
ADCIN 0,X
IF X=128 THEN Y=Y+1
IF X=0 THEN Y=Y-1
IF X=255 THEN GOTO POINTCHECK
PAUSE 1
NEXT
POINTCHECK:
GOSUB DISPLAY
GOTO MAINCODE


But this also does not works properly - depending on how long user pressed the buttons, he's getting final result after he releases the key.

Any ideas?

Meanwhile, my nixie clock thread seems to be gone, so I'm posting picture of freshly developed model here :) - Runs completely on PBP, using 16F887, about 7K of code.

8894

mpgmike
- 28th June 2020, 05:22
You didn't show how you're dealing with ADC; FRC? or are you using the ADCCLK and manually timing it? If I have issues where a quick read proves inaccurate, but a repeated or longer read shows accurate results, increasing the acquisition time almost always fixes things.

CuriousOne
- 28th June 2020, 07:09
There are no problems with ADC readings. It returns stable result.

CuriousOne
- 28th June 2020, 13:35
So what I need.
if user presses key, there should be immediate response, but if he keeps it pressed, variable value should increase slowly, so he won't skip desired value.

Jerson
- 29th June 2020, 03:40
I would try something like this. Of course, you have to

define var key
K_None con 0
K_Inc con 1
K_Dec con 2



AdcSub:
ADCIN 0,x
if x = $FF then key = K_None
if x < 125 then key= K_Dec
if x > 130 then key = K_Inc
return


MAINCODE:

Gosub AdcSub
if key = K_Inc then
y=y+1
goto Mydelay
endif
if key = K_Dec then
y = y-1
Mydelay:
pause 100
endif
Gosub Display
goto Maincode

Acetronics2
- 29th June 2020, 18:57
So what I need.
if user presses key, there should be immediate response, but if he keeps it pressed, variable value should increase slowly, so he won't skip desired value.

Hi,

What's YOUR time lag for " immediate " ...

as always, this is a highly subjective point of view ...

Generally ... " immediate " means ... Interrupt !

Knowing your general way of thinking ... that probably could be much slower than a few microseconds ...

just consider the time spent between your thinking you must strike a key, and the act of striking the key, may be add the time needed to analyze the info that decide you to strike wich key , plus the time to define as a target the right key ... : interesting point of view, no ???

" immediate ", you told ??? :D

Alain

CuriousOne
- 30th June 2020, 05:32
LOL.

Do you have at least TV remote at hands?

when you press say channel up button, it immediately switches the channel (the actual change might occur a bit later, but here we're talking about system response), but if you keep it pressed, it will slowly cycle between channels.

So I think I should do the code in the following way:

Once key is pressed, start counter, say to 100, and do pause 1 inside it. If user releases key before counter hits 100, then do the action. But if user keeps key pressed and counter reached say 200, do the action, reset counter and start again.

Acetronics2
- 30th June 2020, 11:12
Some readings about the very powerful ... BUTTON command could be helpful, then ...

but, of course, you can rewrite it by your own ...

:wink:

Alain

peterdeco1
- 30th June 2020, 17:51
Maincode:
Adcin 0,x
if x=128 then y=y+1
if x=0 then y=y-1
pause 100
if x=255 then pointcheck
if x < 255 then maincode
pointcheck:
Gosub display
goto maincode

retepsnikrep
- 8th July 2020, 16:36
Meanwhile, my nixie clock thread seems to be gone, so I'm posting picture of freshly developed model here :) - Runs completely on PBP, using 16F887, about 7K of code.


Could you post your clock schematic and code please? Maybe in a new thread..

CuriousOne
- 9th July 2020, 05:50
Yes I can, but there are no schematics, I've directly developed PCB. So I can post gerber files for it. It uses 16F887A chip, DS3231 for timekeeping, UC3843 with external mosfet for HV generation and also there are 30 pieces of MPSA42 transistors, which drive nixie tubes. Here how assembled PCB looks. (16F887 not installed in socket).

8903