1. Home
  2. Embedded Programming
  3. Keyboard task in RTOS; how to deal with long keypresses etc.?

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

Reply to
nic
Loading thread data ...

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

Reply to
dk

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

formatting link

------------------------------------------------------

formatting link

Original message:

formatting link

Reply to
Didi

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

formatting link

Reply to
Vladimir Vassilevsky

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)

Reply to
cs_posting

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

Reply to
Dingo

... snip ...

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]: 
            Try the download section.
Reply to
CBFalconer

Isn´t it this what a multitasking system is all about: Splitting up jobs into tasks. I´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 @monlynx.de instead !
Reply to
42Bastian Schick

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

Reply to
nic

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.