Post by thread:Up/Down Scroll Rate

I frequently am involved in the design of products having programmable parameters. Up/Down keys are used to set the values. It is generally desireable to allow the user to press and hold Up or Down and to make the scroll rate faster, the longer the key is held. A simplified version of a way to do this: up/down detected: initialize a register (call it 'period') with some constant, say 'max_period' loop1: inc/dec the parameter. initialize a count-down timer with the value in 'period' loop2: clrwdt may be needed here If key is still pressed continue else done If timer is not done, loop2 else reduce the value in 'period' by 'delta' but not below 'min_period'. go to loop 1 done: The problem with this approach is that, even after juggling min_period, max_period and delta, I have never arrived at a combination that "felt good". While I understand that this is a subjective call, I am curious how others handle this problem and what they though of their results. It would seem that there is a better way. -- Bob Fehrenbach Wauwatosa, WI spam_OUTbfehrenbTakeThisOuTexecpc.com

On Thu, 28 Aug 1997, Bob Fehrenbach wrote: > I frequently am involved in the design of products having programmable > parameters. Up/Down keys are used to set the values. It is generally > desireable to allow the user to press and hold Up or Down and to > make the scroll rate faster, the longer the key is held. > > (method omitted) > > The problem with this approach is that, even after juggling min_period, > max_period and delta, I have never arrived at a combination that "felt > good". While I understand that this is a subjective call, I am > curious how others handle this problem and what they though of their > results. It would seem that there is a better way. I've only done this sort of up/down key action in Z8 code, but it seems to work well. I'll try to impart the essentials... First off, I use a 2ms interrupt timer to call the key (and display driver) routine. (Or use TMR0 in this case to wait on 2ms ticks and do other stuff while waiting). KEY_INT: Save previous key Read to see if a key is currently pressed If pressed: (if not pressed fall through to CLR_KEYCOUNT) Inc key-down tick count (R1 and R0 as a 16-bit counter) If current key = previous key skip CLR_KEYCOUNT -- goto INCDEC_MODE CLR_KEYCOUNT: ; ; Some info on the counter/flags: RR0 (two 8-bit registers, R0 and R1, ; which can also be addressed as a single 16-bit register for certain ; operations) does 3 things: 1) it gets counted up to 3 for initial key ; down events ( a sort of debounce feature) such that a key must be held ; down 8ms or more to actually be counted as a valid key. 2) For keys held ; down a "long time", it will count all the way around to R1=3 (256 times ; later) so an "auto key-repeat" will happen every 256 * 2ms = 0.512 sec. ; 3) The high byte (R0) tells the INC/DEC routines how many half-seconds ; have elapsed with the key held down (this is what determines when it ; switches from slow inc/dec to fast inc/dec). ; ; Oh, there is a single bit-flag used to indicate whether inc/dec is ;fast or slow. ; ; For PIC code for the counter, RR0 would have to be created in ; software, but this fairly simple. ; Clear key delay counter (high byte of RR0 = R0) Clear key down counter (low byte of RR0 = R1) Reset the 'fast/slow' inc/dec flag to 'slow' INCDEC_MODE: ; ; how big a number R1 is checked for determines how fast the auto-key ; repeat happens--voila, a fast/slow inc-dec. In this case, a slow repeat ; happens approx. every 0.5 seconds (2Hz) and a fast repeat (8 times ; faster) at every 64ms (16Hz). If 'fast/slow' flag = fast: If key down counter R1 has rolled over a modulo-32 boundary: Goto DO_KEY Else If key down counter R1=3 (initial valid key time or 256+3 slow repeat) Goto DO_KEY Goto DO_OTHER_THINGS ;meaning, done with key stuff for now, do other ;interrupt routine things, if any. DO_KEY: ; ; Here is where which key was pressed determines what action is taken ; (i.e., inc vs. dec vs. whatever). Also, the data for the key action is ; picked up. ; Get data to be inc/dec'd Look at current key code and goto appropriate action routine. DEC_VAL: ; ; Action routine example to show how slow-to-fast flag is set. ; Decrement data value at a rate of 2Hz for about 2.5 seconds, and if the ; key is still down at a rate of 16Hz. ; If in fast mode already: Goto DECREMENT Else If key delay counter R0 >= 5 ;(After five 0.5 sec repeats, go faster) Set 'fast/slow' flag = fast DECREMENT: Do actual decrement here Goto DO_OTHER_THINGS INC_VAL: SOME_OTHER_KEY: ;(other key-action routines as needed) YET_ANOTHER_KEY: . . . DO_OTHER_THINGS: . . . Return from interrupt END ***** Hope that isn't too confusing ^^;;; It leaves out things like how to pick up the correct parameter to inc/dec, but it does show the core of how I do the slow/fast key repeat action. --Scott /**/

On Thu, 28 Aug 1997 16:06:55 -0500 Bob Fehrenbach <.....bfehrenbKILLspam@spam@EXECPC.COM> writes: >I frequently am involved in the design of products having programmable >parameters. Up/Down keys are used to set the values. It is generally >desireable to allow the user to press and hold Up or Down and to >make the scroll rate faster, the longer the key is held. > >A simplified version of a way to do this: [method of changing the sampling period deleted] > >-- I have used the much simpler approach of using a constant update rate, but increasing/decreasing the value by more than 1. The increment value increases the longer the button is held down up to some maximum. If the increment isn't a power of 10, changing by more than 1 isn't noticeable to the user, since the display is changing too fast to read any but the most significant digits. When the value is close they will release the button and make a fine adjustment in any case, since it isn't possible to stop a fast-moving value exactly where desired even if it is changing by ones.

> From: Bob Fehrenbach <Describes linear method to go faster the longer a button is held> > The problem with this approach is that, even after juggling min_period, > max_period and delta, I have never arrived at a combination that "felt > good". While I understand that this is a subjective call, I am > curious how others handle this problem and what they though of their > results. It would seem that there is a better way. Bob, It may be that a linear ramp to a faster incrementing rate just doesn't fit your expectations. I ended up using a log scheme for ramping the rate when I wrote some 8088 code that let the user scroll through *lots* of text. Users seemed to like that. However, that sort of sillyness is out of the question on a PIC if you are squeezed for clock cycles or space. Perhaps you could double the rate every so often to get somewhat the same effect, or maybe make a small table of rates. Cheers, Win Wiencke ImageLogicKILLspamibm.net

Engineering Department wrote: {Quote hidden}> > > From: Bob Fehrenbach > > <Describes linear method to go faster the longer a button is held> > > > The problem with this approach is that, even after juggling min_period, > > max_period and delta, I have never arrived at a combination that "felt > > good". While I understand that this is a subjective call, I am > > curious how others handle this problem and what they though of their > > results. It would seem that there is a better way. > > Bob, > > It may be that a linear ramp to a faster incrementing rate > just doesn't fit your expectations. I ended up using > a log scheme for ramping the rate when I wrote some > 8088 code that let the user scroll through *lots* of > text. Users seemed to like that. > > However, that sort of sillyness is out of the question > on a PIC if you are squeezed for clock cycles or space. Silly Logarithms on a cycle-starved PIC? Hmmm, check out: http://www.interstice.com/~sdattalo/technical/software/pic/piclog.html At 103 cycles worst case it's not too unreasonable. > Perhaps you could double the rate every so often > to get somewhat the same effect, or maybe make > a small table of rates. But are you talking about logarithms or powers now? The table solution seems like a very reasonable approach. So far those of you who have suggested this accelerating repeat rate have only mentioned the time constant associated with the initial key press. However, I would think that a time constant associated with the key release would be useful too. This way if you release the key some where in the middle and decide to back space or press the same key again then you wouldn't have to wait for the repeating to take affect. The same table could be used for the key press and for the release. Scott

Hi Bob (Bob Fehrenbach), in <.....vheB0Yi8aAaO089ynKILLspam.....execpc.com> on Aug 28 you wrote: > The problem with this approach is that, even after juggling min_period, > max_period and delta, I have never arrived at a combination that "felt > good". While I understand that this is a subjective call, I am > curious how others handle this problem and what they though of their > results. It would seem that there is a better way. You could make it easier to program, and easier to understand by the customer (and therefore maybe feel better). Key down: inc/dec once. Key still down after 700 ms: enter slow scroll slow scroll: inc/dec each 500ms, enter fast scroll after 3000ms of slow scroll fast scroll: inc/dec each 200ms key up: stop or something similar

I would like to take this opportunity to make a suggestion. There are many devices that use an up/down mechanism for setting parameters or a round-robbin menu system in which one must keep pressing a selection button until the desired selection appears. These mechanisms are pure Hell for users of the devices who happen to be blind. Since thermostats, timers, and countless other control systems exist in homes and businesses, there is no telling when this problem will occur. My suggestion is to have an abnormal key sequence such as the simultaneous pressing of both the up and down button or some other sequence to start the selection process at a known point in the circle. This might be accompanied by a beep or some audible indication, if there is a sounder, but this feature would be very cheap to implement and would allow a blind person to use the device by learning the order of selections. I don't know how many modern devices are almost impossible to use efficiently due to this type of control mechanism. All I know is that it shows up all the time and is an utter pain to deal with. There is a literary quote that goes something like "It isn't the mountains in the distance, but that little grain of sand in your shoe that can drive a person to madness." That pretty well sums up the feeling about the state of the art in control technology over the last 10 years or so. Martin McCormick

> There > are many devices that use an up/down mechanism for setting parameters or > a round-robbin menu system in which one must keep pressing a selection button > until the desired selection appears. These mechanisms are pure Hell for > users of the devices who happen to be blind. Since thermostats, timers, > and countless other control systems exist in homes and businesses, there > is no telling when this problem will occur. My suggestion is to have an > abnormal key sequence such as the simultaneous pressing of both the up and > down button or some other sequence to start the selection process at a > known point in the circle. This might be accompanied by a beep or some > audible indication, if there is a sounder, but this feature would be very > cheap to implement and would allow a blind person to use the device by learning > the order of selections. I would second this point. Even for people with 20/20 vision, it's often nicer to be able to operate devices by feel than looking at them. I person- ally prefer a slightly different tack though, on devices with numeric key- pads but small displays: precede each menu choice on the display by a number and then allow the user to *either* use arrow keys plus enter (if they do not know what they want) or else use the numeric keys directly (if they do). Of course, it should go without saying that the numeric keypad should be design- ed to be navigable by feel (none of those infernal flat mylar things!) But if the keyboard and display are both used to best advantage, it should be possible to design an interface which is useful for both blind and sighted people alike. [BTW, beepers can be wonderful too. While I think IBM's ProPrinter button interface (which relies on beeps, since there's no display) is a bit of a pain, the beeper is a considerable improvement over having nothing. In addition, it actually cost nothing in the ProPrinter since the "beeps" were (from what I read) actually generated by giving short pulses to the print head (too short to make it strike paper)!

John Payson writes: >I would second this point. Even for people with 20/20 vision, it's often >nicer to be able to operate devices by feel than looking at them. I person- >ally prefer a slightly different tack though, on devices with numeric key- >pads but small displays: precede each menu choice on the display by a number >and then allow the user to *either* use arrow keys plus enter (if they do not >know what they want) or else use the numeric keys directly (if they do). This is another perfectly good solution. Anything to put the system in a known state at a known point. > Of >course, it should go without saying that the numeric keypad should be design- >ed to be navigable by feel (none of those infernal flat mylar things!) That's for sure. Those things don't seem to last very long either. > But >if the keyboard and display are both used to best advantage, it should be >possible to design an interface which is useful for both blind and sighted >people alike. Absolutely. It doesn't need to be loaded with speech generators and artificial intelligence. A little human intelligence at the design stage is still the best policy. Martin McCormick

> >I frequently am involved in the design of products having programmable >parameters. Up/Down keys are used to set the values. It is generally >desireable to allow the user to press and hold Up or Down and to >make the scroll rate faster, the longer the key is held. > Hiya Bob, I have generally avoided changable scroll rates so far. Most of my current projects use the same routine which reads the initial press of the button (either up or down or whatever), waits for 7 ticks of 130 mS per tick (about 1 second), then repeats at the tick rate of 130 mS (about 7 Hz). The funny times that I use come from the slow serial rate that I talk to my display (1 mS per edge, 2 edges per clock, 32 bits per packet ending off with another pair of edges for the strobe line). Hope this helps. Dwayne Reid <EraseMEdwaynerspam_OUTTakeThisOuTplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, Alberta, CANADA (403) 489-3199 voice (403) 487-6397 fax