Keyboard task in RTOS; how to deal with long keypresses etc.?

Hi all
    I'm working on a small embedded project which runs under a simple
RTOS. The Hardware includes a scanned keyboard, LCD display, and
various motors & switches etc.

The User Interface requirements call for various commands and
navigation within the menu system to be selected by means of
combinations of keys, and/or keys being pressed for a longer period of
time. Something like "press cancel key to cancel last entry; hold
cancel key for 2 seconds to revert to start" - that kind of thing.

I'm familiar with scanning a keyboard and generating keycodes etc.,
but in an RTOS envirinment with a dedicated keyboard task I'm not sure
of the best way to proceed with this. I could make available the
keycode + time of pressing/time of releasing', and make the other task
work out the delay time, but this doesn't feel very efficient. Can
anyone suggest other ways of doing this, or point me towards some
prior art?

Thanks for any suggestions.

    Regards
    J^n

On Sep 24, 1:06=A0pm, nic <jkn...@nicorp.f9.co.uk> wrote:
> Hi all
> =A0 =A0 I'm working on a small embedded project which runs under a simple
> RTOS. The Hardware includes a scanned keyboard, LCD display, and
> various motors & switches etc.
>
> The User Interface requirements call for various commands and
> navigation within the menu system to be selected by means of
> combinations of keys, and/or keys being pressed for a longer period of
> time. Something like "press cancel key to cancel last entry; hold
> cancel key for 2 seconds to revert to start" - that kind of thing.
>
> I'm familiar with scanning a keyboard and generating keycodes etc.,
> but in an RTOS envirinment with a dedicated keyboard task I'm not sure
> of the best way to proceed with this. I could make available the
> keycode + time of pressing/time of releasing', and make the other task
> work out the delay time, but this doesn't feel very efficient. Can
> anyone suggest other ways of doing this, or point me towards some
> prior art?
>
> Thanks for any suggestions.
>
> =A0 =A0 Regards
> =A0 =A0 J^n

You need to connect the SCAN or RETURN lines to interrupt enabled i/o
lines of the micro so that you can start a timer and do all you wanted
in ISR.

-dK

On Sep 24, 2:06=A0pm, nic <jkn...@nicorp.f9.co.uk> wrote:
> ...
> I'm familiar with scanning a keyboard and generating keycodes etc.,
> but in an RTOS envirinment with a dedicated keyboard task I'm not sure
> of the best way to proceed with this. I could make available the
> keycode + time of pressing/time of releasing', and make the other task
> work out the delay time, but this doesn't feel very efficient. Can
> anyone suggest other ways of doing this, or point me towards some
> prior art?

a very simple way to deal with that is to maintain a bitmap with
the state of all keys which is globally accessible. The keyboard task
modifies the bitmap, the rest read it and react accordingly.
The disadvantage is that the reading tasks must check the bitmap
faster than the modifying task can modify it in order to not miss a
key. Then there are various remedies against that, of course, but
at the end of the day you will have to choose and figure out yourself
what to do, such discussions are just to give one food for thought
(and some chat for others :-) ).

Didi

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/c14=
dd3c642c448df?dmode=3Dsource

nic wrote:


> I'm familiar with scanning a keyboard and generating keycodes etc.,
> but in an RTOS envirinment with a dedicated keyboard task I'm not sure
> of the best way to proceed with this. I could make available the
> keycode + time of pressing/time of releasing', and make the other task
> work out the delay time, but this doesn't feel very efficient. Can
> anyone suggest other ways of doing this, or point me towards some
> prior art?

Add 2-3 additional bits to the scancode. Such as:

bit15: key was hold pressed for +t1 (autorepeat)
bit14: key was hold pressed for +t2
bit13: key was hold pressed for +t3

You can make t1, t2, t3 configurable for each key for each task (as it 
is done in Win32 API).

There is no need for key release code.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Sep 24, 7:06 am, nic <jkn...@nicorp.f9.co.uk> wrote:

> I'm familiar with scanning a keyboard and generating keycodes etc.,
> but in an RTOS envirinment with a dedicated keyboard task I'm not sure
> of the best way to proceed with this.

Why don't you make your keyboard scanning more or less periodic, and
count how many scan cycles keys have been held down for.

When the key is released, buffer it's normal key code if the held
count is less than the threshold, or it's special key code if it's
been longer.

(I like to give my embedded keyboards bindings to characters that
exist on my PC keyboard, then I can play with my software by feeding
it PC keystrokes, and displaying the output in a window that simulates
the capabilities of the embedded display)

On Sep 24, 7:06=A0am, nic <jkn...@nicorp.f9.co.uk> wrote:
> =A0 =A0 I'm working on a small embedded project which runs under a simple
> RTOS. The Hardware includes a scanned keyboard, LCD display, and
> various motors & switches etc.
>
> The User Interface requirements call for various commands and
> navigation within the menu system to be selected by means of
> combinations of keys, and/or keys being pressed for a longer period of
> time. Something like "press cancel key to cancel last entry; hold
> cancel key for 2 seconds to revert to start" - that kind of thing.
>
> I'm familiar with scanning a keyboard and generating keycodes etc.,
> but in an RTOS envirinment with a dedicated keyboard task I'm not sure
> of the best way to proceed with this. I could make available the
> keycode + time of pressing/time of releasing', and make the other task
> work out the delay time, but this doesn't feel very efficient. Can
> anyone suggest other ways of doing this, or point me towards some
> prior art?

If your user interface is well defined, you can just have the keyboard
task return different keycodes based on the key and duration.

Vladimir Vassilevsky wrote:
> 
... snip ...
> 
> Add 2-3 additional bits to the scancode. Such as:
> 
> bit15: key was hold pressed for +t1 (autorepeat)
> bit14: key was hold pressed for +t2
> bit13: key was hold pressed for +t3
> 
> You can make t1, t2, t3 configurable for each key for each task
> (as it is done in Win32 API).
> 
> There is no need for key release code.

In other words you want to signal key presses only on key release. 
It is rather hard to mark press times without noting the release. 
You also have a problem with multiple simultaneous key presses.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Wed, 24 Sep 2008 04:06:04 -0700 (PDT), nic <jkn_gg@nicorp.f9.co.uk>
wrote:

>I'm familiar with scanning a keyboard and generating keycodes etc.,
>but in an RTOS envirinment with a dedicated keyboard task I'm not sure
>of the best way to proceed with this. I could make available the
>keycode + time of pressing/time of releasing', and make the other task
>work out the delay time, but this doesn't feel very efficient. Can
>anyone suggest other ways of doing this, or point me towards some
>prior art?

Isn&#4294967295;t it this what a multitasking system is all about: Splitting up
jobs into tasks.
I&#4294967295;d keep the tasks simple:
a) One task (maybe interrupt) just scans the keyboard and generates a
status (scan-code) of this action.
This will be sent to a keyboard-task.
b) The keyboard task handles things like autorepeat and special
behaviour for different keys.
It will then feed the GUI-task which has the focus with the mapped
keys (e.g. 2s ESC => "restart").
-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

Hi All
    thanks for the good suggestions, some of which mirror my own
musings so far.

I have plenty of space in my 'keypress code' for adding in some flags
for 'time pressed'. Doing it like the Win32api is one way I was
originally thinking.

And suggesting splitting it into two tasks is a good point too. Again,
there's room for 'virtual' keycodes, corresponding to the user holding
down combinations of keys.

I'll let you know what I come up with...


    Cheers
    J^n