I am planning on creating a shared object file that can be placed in
/lib, then you only have one copy on the computer. Here is an example
of the commands to create a shared library:
gcc -c -fpic mylib.c
gcc -o libmylib.so -shared mylib.o
I will look at the code you wrote.
Don.
On 4/4/06, Jim Jackson <> wrote:
>
>
> Don,
>
>
> On Tue, 4 Apr 2006, 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.
>
> Functions for this sort of stuff are ok for new/custom programs, but the
> problem is you have compile this functionailty in to every program you
> want to interface to the keypad or lcd.
>
> Better ways are to build a device driver into the kernel, or to do a user
> space demon that reads a fifo (named pipe) and writes the stuff to the
> LCD. That way you can simply script output from virutally any program to
> the LCD display.
>
> My attempt at this is at
>
> http://www.comp.leeds.ac.uk/jj/linux/lcdd-0.2beta.tgz
>
> keypad scanning could be added to this, so that other programs could read
> the named pipe to get the keypresses, probably by assigning ascii codes to
> keys and/or key combinations.
>
> cheers
> Jim
>
>
>
> ________________________________
> 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/
|