Wednesday, April 21, 2010

Reading Keyboard Input

This is just a brief post - Kevin's posts and videos are usually clear and succinct enough not to warrant additional cruft by me :) For those who watched the game play video in the keyboard input post, you might have noticed that Kevin was pressing the key repeatedly before the input was accepted.

Due to Nano-RK's task based style, getting user input from the keyboard needs to be a bit of a polling hack. This is because C input methods such as getchar() are blocking methods, meaning that once called the program will not continue until the function has returned. Unfortunately Nano-RK sees this blocking as the task being in use and will not preempt it, so it never switches to the idle task. This causes the task reading user input to eventually violate its period allotted, as well as the additional reserve.

To solve this problem we loop, waiting for the signal in uart_rx_signal, which is registered with the system before. Once the signal is set, and data is ready essentially in the buffer, we then call getchar(), which should return almost immediately with the typed character.

Until we work out exactly how the uart_rx_signal is set and tighten up the timings a little bit, we will continue to experience this lag and missed keystrokes when checking for keyboard input. Fortunately however, using the keyboard for input was only a midway point to prove that we could send user-defined input to the NES. We can now safely put the keyboard aside, since the Firefly node attached to the NES will now be receiving all of its inputs from its corresponding Firefly node in the toy gun.

No comments:

Post a Comment