uCos keyboard listener

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

Reply to
Juha Rossi
Loading thread data ...

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. ;-)

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.

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.


Reply to
Thad Smith

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.