Hi!
(thanks for your quick reply)
> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...]
> Sent: Wednesday, June 08, 2005 2:42 PM
> To: lcd4linux-devel
> Subject: [Lcd4linux-devel] Re: I2C Keyboard implementation
>
> Hi Luis, Paul,
>
> I'm moviing this to the devel list...
>
> > as you know, me and Paul are designing an advanced I2C
> display with a lot of
> > added features such as keyboard buttons.
> Sounds interesting!
>
> > Before we start with the actual hardware design, we would
> like to know how
> > are you planning to read the keys, as we will have to do
> some jogging to
> > read them from our HW implementation, as a lot of stuff is using the
> > available I2C bits.
>
> I must admit that I'm not yet sure how this will be implemented.
well, you should know by now...
> > The best thing to do is to prepare a hook function that we
> will handle, and
> > that would take care of reading the keys between the writes
> to the LCD.
>
> No, there will be no hook. For several reasons. And 'polling'
> before/between/after display writes is a *bad* idea: Due to the
> double-buffering in lcd4linux, there may be no display writes
> for a long
> period of time (when nothing changes on the display). If you want to
> read keys, you have to use a separate thread.
Ok, but we need to 'spinlock' around key polling because writing to
the LCD and reading the buttons uses the same 8 bit bus...
> Have a look into the Crystalfontz driver (or was it MatroxOrbital?)
> These displays have keypads, which send keycodes asynchronously. These
> packets are processed by a separate thread, but just logged and not
> really used (yet).
>
> Another source would be the HD44780 driver, especially for the LCM162:
> It uses a seperate thread for key polling, too. Have a look at the
> drv_HD_LCM162_timer() function.
Ok, will do that once we have the overall design ready.
> I think there will be some sort of a 'event' system. you can
> trigger an
> event (or call it a signal if you like) anywhere in
> lcd4linux, and there
> will be 'handlers' which get the event. If there's no handler for a
> event, it will (more or less) silently be dropped.
>
> Possible event sources are: keypads, timers, ...
>
> A handler will be a Evaluator expression.
Ok, something like a plugin then?
We will need to have the output to the LCD and the input from the keys
in the same driver because of that 'spinlock' issue.
> > The only possible problem that I'm seeing is the lack of proper
> > key-debouncing, but that would preferrably done in your
> side on the code :)
> Oh no, debouncing is your job.
I was afraid of that... unfortunately i have NO idea how to do it
properly...
>
>
> bye, Michael
>
Luis Correia
|
