Don, non-blocking reads can be done on device files and on named pipes too
;-)
On Wed, 5 Apr 2006, Don W. Carr wrote:
> 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
>
>
>
>
>
>
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/
|