Thanks for the comments, personally, I need a version to get a
keystroke that is non-blocking for my real time application. I process
real-time values 10 times a second, and update the screen once per
second, and also check for key strokes. But, I can see that probably
most would want a blocking version. I will probably make both, but
keep it simple.
On the lcd routine, the overhead for the printf like functionality is
really almost nothing and very compact code. Then you don't have to
mess around declaring temporary strings to format things and write to
the lcd. if you want to write just a string, your can:
lcd_2x24_printf(0, "%s", "my string output");
Also, my routine is guaranteed to truncate the string if the format
you specify is more than 24 characters. (I use vsnprintf()).
And that brings up another point, you should never use sprintf(), use
snprintf(), where the maximum length is given. Well, there are a
number of the string functions that should not be used such as:
strcpy, strcat, vsprintf, sprintf, gets (can write past end of string)
strncpy, strncat (do NOT guarantee termination)
On 4/5/06, brendanmurphy37 <> wrote:
>
> 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
>
>
> Visit your group "ts-7000" on the web.
>
> To unsubscribe from this group, send an email to:
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>
--
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/
|