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.
> 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.
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.
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.
> 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.
bye, Michael
--
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
|
