Searching \ for '[PIC]: Newbie begs your counsel' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/begin.htm?key=pic
Search entire site for: 'Newbie begs your counsel'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Newbie begs your counsel'
2001\03\23@143556 by E. C. Short

flavicon
face
I am hoping to develop a simple mid-range PIC MCU application that
requires the input of key-pressed data from four distinct keys.  It is
imperative that no key-press ever be missed.  But the code has other
things to do and cannot be continually scanning for these inputs.

In short, my question is:

Is there a way of getting key-pressed data (just 2-bits in my case) to
the MCU without actively scanning for it ?

I've been reading all the info I can find, and the only similar examples
I come across involve keypad scanning.  Maybe I'm a bit naive, but isn't
it risky to rely on scanning to intercept the data as it is enterred? What
if your code is busy servicing an interrupt and misses a key-press?

Wouldn't it be better if the data appeared on its own somehow, latching
itself into a register while anouncing its arrival by perhaps simultaneously
triggering an interrupt?  So upon detecting the interrupt, the code could
stop what it is doing, retrieve the keypad input and re-enable the interrupt
for any subsequent key-presses?

Am I asking too much ?  I haven't enough knowledge or experience to know
this, but I'm betting that there are plenty of people who do.

Your help will be much appreciated !
                                     Ed Short

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@145029 by Spehro Pefhany

picon face
At 02:25 PM 3/23/01 -0500, you wrote:
>
>I've been reading all the info I can find, and the only similar examples
>I come across involve keypad scanning.  Maybe I'm a bit naive, but isn't
>it risky to rely on scanning to intercept the data as it is enterred? What
>if your code is busy servicing an interrupt and misses a key-press?

It's not risky at all. You just scan fast enough that you never miss any
(reasonable) key presses. You might have to scan every 10 or 20 milliseconds.
You will reject short closures as they will probably be switch bounce.

If it takes your microcontroller err.. PIC 20 microseconds to do the scan,
that leaves it 99.9% of its throughput to do other things.

If it was some other kind of signal that might only be present for a few
dozens of microseconds or less, you'd another way of doing it.

Best regards,


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@145320 by Lawrence Lile

flavicon
face
I can think of three ways to guarantee you never miss a keypress:

1.  Put the keypad on a port with interrupts.  Some PICs have an "interrupt
on change of PortB".  If your program sees this interrupt, it then reads the
port and decides which key was pressed.  All this happens in a half-dozen
machine cycles, too fast for the key switch to change.

2.  Use a dedicated PIC, say a 12C508, to scan your keys.  If this PIC has
nothing else to do but scan keys, it can't miss.

3.  Scan your keypad on a timer interrupt, that is brief enough that you
can't miss a keypress.  I would suggest that if you are scanning the keypad
every 25 milliseconds, that you could not possibly miss a keypress, since
the switches cannot operate very fast.

-- Lawrence Lile
http:/members.socket.net/~llile/




{Original Message removed}

2001\03\23@151629 by Eisermann, Phil [Ridg/CO]

flavicon
face
Ed wrote:
"
I've been reading all the info I can find, and the only similar examples
I come across involve keypad scanning.  Maybe I'm a bit naive, but isn't
it risky to rely on scanning to intercept the data as it is enterred? What
if your code is busy servicing an interrupt and misses a key-press?
"

The thing is, the PIC (or other micro) is scanning them pretty fast,
compared to human reaction time. Say you scan the keypad every 20mS. Or even
slower at 50mS. (thats milli-seconds). Can you press a key and release it
that fast? Maybe, if you tried. Are you likely to press it that fast in
normal use? Not likely. Consider what 50mS means. The frequency is 1/50mS,
or 20Hz. That means you could press the key 20 times per second, and the
code would still read the key.

So, unless you have an extremely long interrupt, it is extremely unlikely
that you will miss the key. I personally think that, for a keypad
application, 10 keys pressed per second is more than adequate. So that gives
you a scan rate of 100mS. use a scan rate of 50mS, consider two identical
readings in a row to be a valid keypress (e.g. debounced), and I don't think
you'll have any problems.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@154922 by Olin Lathrop

face picon face
> Is there a way of getting key-pressed data (just 2-bits in my case) to
> the MCU without actively scanning for it ?

Yes.  One way is the port B interrupt on change feature.

> I've been reading all the info I can find, and the only similar examples
> I come across involve keypad scanning.  Maybe I'm a bit naive, but isn't
> it risky to rely on scanning to intercept the data as it is enterred? What
> if your code is busy servicing an interrupt and misses a key-press?

Key presses are very slow events compared to (reasonable) interrupt
handling.  There is no problem if it takes several mS to first notice the
key is down.  You have to debounce it anyway, so no rush.

Especially if you need timing for other tasks, I would check the keypad in a
periodic interrupt, or in the foreground loop with timing from a periodic
interrupt.  I usually use 1mS (1000Hz) interrupt as a master clock, and
don't believe any external mechanical switch has actually changed state
until the new state has been constant for 50mS.  At 20mHz clock, 1mS is 5000
instructions.  Checking the keypad will only use a tiny fraction of that.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@164614 by Quentin

flavicon
face
You mentioned that you use mid range, most of them got a interupt on the
upper 4 bits of PortB. I would agree with the others that this is your
best bet.

However, if you for some reason would not want or cannot use this
interupt, there is another method where you can quickscan all the keys
simultaniously by checking all the data lines for a change. If there is,
call to service the keys. The quickscan could be a short code (or call
to sub) that you can put in all over your program.

Something like:
Say you use portA 0 to 3 for the keys:

quickscan        Movf        porta,w
                      andlw       b'00001111'        ;if any of the
lower 4 is set (key pressed), Z will not be set
                      btfsc         status,z
                      goto         scankey               ;service keys
and return from there
                      return

Quentin

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@180820 by Chris Carr

flavicon
face
Ed, I think that you believe that when you operate a mechanical switch then
the opening and closing of contacts produces a nice electrical square wave
output. In the real world contacts bounce producing crap (noise) when the
switch changes state. This means that to ensure that you are actually
reading the correct state of a switch you should sample, wait a suitable
period and sample a second time. If both states are identical then assume
switch is in that state.

This is one reason why sampling is so popular. Instead of wasting time,
waiting, go off and sample other switches.

Regards

Chris

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\24@043937 by Peter L. Peres

picon face
It helpd to define what a keypress is. If a keypress is a signal condition
that exists for more than 10 msec then theory says that if you have a
latency of one half of that or less in the method of aquiring it, it will
be aquired successfully.

So if you 'loop' fast enough to read the keys every 5 msec or have
response latency for interrupts of less than 5 msec then you should not
miss any key events. The 10 msec comes from the typical minimum acceptable
keypress time which is 100 msec, divided by 10 to make 'very sure'. You
will need some debouncing anyway.

With some keys it is possible to 'key' even shorter pulses by hand. In
that case the 'minimum keypress time' can be taken as 3x the contact
bounce time given by the manufacturer, and the latency will have to be 1/2
or even 1/3 of the bounce time.

hope this helps,

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\24@044003 by Peter L. Peres

picon face
>slower at 50mS. (thats milli-seconds). Can you press a key and release it
>that fast? Maybe, if you tried. Are you likely to press it that fast in
>normal use? Not likely. Consider what 50mS means. The frequency is
>1/50mS,

FYI humans with suitable training can actuate very normal keys for <1msec.
They do not succeed every time, but they try hard and repeatedly.
Especially if it is some kind of a contest or if there is something to be
gained (or to be lost by some other party). (Hint: The proper stroke for
this is sometimes called 'tangent whack', using one or more fingers. I
think it is called flick somewhere else).

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\24@094013 by Bob Ammerman

picon face
----- Original Message -----
From: Peter L. Peres <plpspamKILLspamACTCOM.CO.IL>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Saturday, March 24, 2001 2:57 AM
Subject: [PIC]: Newbie begs your counsel


> It helpd to define what a keypress is. If a keypress is a signal condition
> that exists for more than 10 msec then theory says that if you have a
> latency of one half of that or less in the method of aquiring it, it will
> be aquired successfully.

Actually, if the condition is certain to last for 10 msec, your latency to
detect it can be as much as 9.99999... ms.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...