uCos keyboard listener

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
hi all,

Im writing a simple application in uCos-II that spans a couple of
processes.
First process (inputField) controls input "field" for words. The idea
is to provide a possibility for user to input a word that is sent (by
Message Queue) to another process that prints it on screen. Third
process also listens keyboard:

void KeyListener(void *pdata)
{
   while(1)
   {
  OSSemPend(Priority_over_CPU, 0, &err);  //get exclusive control
  if(kbhit())
  {  
    if(ch == 27) //esc
          OSSemPost(EscPressed);  //signal process that kills
application
  }
  OSSemPost(Priority_over_CPU);    // release control
  OSTimeDly(1);
  }
}

-----------------
Source code for the first process:

void InputField(void *pdata)
{
  while(1)
  {
  OSSemPend(Priority_over_CPU, 0, &err)
  ch = getch();
   if(ch != 13)
    input[next_pos] = ch;  //append to array
   else   //enter pressed->sent written word to another process
    OSQPost(MsgQueue,  (void *)&input[0]);

   OSTimeDly(1);
 }

}



Problem: For some reason the program crashes when task-InputField()
gets
control and tries to listen keyboard (it has lower prio than
KeyListener).  How can I get 2 processes listen keyboard? Should I
somehow encapsulate keyboard functions and provide exclusive access to
them when processes get their turn?

-Juha Rossi

Re: uCos keyboard listener

Quoted text here. Click to load it

While this will probably work, it doesn't take advantage of the
event-driven design which an RTOS is designed to support.  In an
event-driven design, you would want to collect keys by an interrupt
routine, then deliver it to a waiting task when a character, word,
escape, etc. has been detected.  You routine repeatedly calls kbhit() to
determine whether a key is needed.  This isn't done in an event-driven
design, since the event itself (key entry, here) causes the processing
routines to be activated.  When I have nothing to do in an event-driven
system, I put the processor to sleep.  ;-)

Quoted text here. Click to load it

This is looking like a DOS environment.  If so, and if getch() waits for
a key to be entered, you are locking out all tasks waiting on
Priority_over_CPU for service.  Again, an event-driven design is
better.  If it isn't feasible and you must poll, make sure that you are
not spinning in a routine like getch(), with other tasks locked out.
Even it no other tasks are waiting on Priority_over_CPU, you will still
lock out all lower-priority tasks if getch() simply spins, waiting for a
key.  Spinning is something to avoid when using an RTOS.

Quoted text here. Click to load it

Encapsulating keyboard functions is a good idea if there is only one
keyboard.  I would think that one interrupt routine, or possibly an
interrupt routine and one task are sufficient.  As far as exclusive
access, you need to know what to do with each input character.  That is
a system design issue, not simply round robin.  In general, with I
suspect that most keyboard input would be handled by a single task.
About the only time there should be more than one is if the user is
explicitly switching between tasks, such as on a general time-sharing
system.  This sort of design isn't common for an embedded application.

Thad

Site Timeline