2009/3/6 <micro...@virginbroadband.com.au> > > Anyway in any case how does shell get the 'd' or anything from the > > keyboard? > > What are the exact steps? > > I'm a Linux kernel newbie, (although I have heavy embedded MCU coding > background) but I can help with the general approach of this scenario. > First, it's important to note that any interrupt handler should be as > *short* as possible. > This applies to any CPU/MCU system. Once the handler (ISR) has acted upon > the event, it will have relevant data stored somewhere, which then the OS > or "foreground" code can act upon. This is commonly referred to as "bottom > half". > > For a keyboard handler, it will typically use a ring buffer (OSs will use > queues). The ring buffer will have a pointer to the head (where the latest > or newest data was stored) and the tail (where the oldest data resides). > When head and tail are equal the ring buffer is empty. > In your example, the head pointer will point to the character 'd' and the > tail will be one behind. > It's most convenient (and fastest) to assign a buffer size of a power of > 2. > > Note that at this stage it's not per se necessary that further interrupts > or task yielding occurs. > The application code could do something as simple as polling whether there > is data in the buffer by looking at the head/tail pointers on a frequent > basis. > > In the case of an OS, the task of retrieving and processing the keyboard > data will activate if it wasn't active. > Where that keyboard data then is off to will depend on what > shell/application/process is running. The received 'd' character might even > just sit there in the buffer but no one is interested in it... > > Perhaps that gives a very general insight at machine level of what goes on. >
Can you make it simple please ...as simple as the question .. ? -- With Love.. . .Shinooooo
