Don,
It's only an opinion, but I think for any API you're best to stick to
each function doing one thing only.
For example, I think you'd be better off with an o/p function that
either outputs one character, or alternatively one that puts out the
entire 2 x 24 display. Callers can always use "sprintf" to format
stuff, and then call your API to actually output it. In other words,
just provide one or more simple-to-use and document functions that
users can build on if required.
On the i/p side, again I'd be inclined to keep it simple, and have it
do one thing well, rather than be all things to all people. Also, I'd
stick as closely to the semantics of the closest match. Thus, I'd
have "int keypad_getchar(void);" as blocking, as that's what "getchar
()" does.
Alternatively, you could just provide a device driver, and users can
then call whatever standard functions they like, but you mightn't
want to go to the trouble of doing this.
Just an opinion!
Brendan
--- In "Don W. Carr" <> wrote:
>
> I am creating two simple apis for the lcd display and keypad that I
> would like to share with the rest, but first, I would appreciate any
> comments on the apis, and of course any volunteers to try what I am
> doing that would like a simple interface.
>
> First, for the display, I have created just one api call:
>
> int lcd_2x24_printf(int line, char *fmt, ...);
>
> With this, you can print to either the first or second line, using
> standard printf syntax. Under the hood, I use variable arguments,
and
> vsnprintf to create a string of maximum 24 characters, and write it
to
> one line of the lcd.
>
> Example printing to first line of lcd:
>
> lcd_2x24_printf(0, "Spd: %4.1lf, Dist: %4.1lf", spd, dist);
>
> For the keyboard, I am thinking of two different apis that would be
> either blocking or non-blocking. The blocking version is more or
less
> easy to do, and the only trick is to have a local static that was
the
> last time a character was read so you can do a "usleep()" if
necessary
> to give time for de-bounce.
>
> For the non-blocking, you need a background process or thread that
> chews up a little cpu time constantly checking for keys, and puts
them
> in a buffer so that when the main program checks for keystrokes, you
> can return them from the buffer. Another design is to create a fifo,
> and then a background process would open it for write, and the
> application would open it for read. With this, you could probably
even
> attach the fifo to stdin.
>
> Well, wheather blocking or non-blocking the api would be like
getchar():
>
> int keypad_getchar(void);
>
> I currently have a version that creates a background thread
> automatically on the first call to keypad_getchar(). The
disadvantage
> here is that libpthread.so is not intalled by default!!
>
> Well, any comments would be appreciated, or volunteers that might
like
> to try my code.
>
> Don.
>
> --
> Dr. Don W. Carr
> J. G. Montenegro 2258
> Guadalajara, Mexico
> +52-333-630-0704
> +52-333-836-4500 ext 2930
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|