requests / wishes / comments
Brought to you by:
mrwastl
Menu
▾
▴
please feel free to post requests, wishes, comments here!
/mrwastl
hey mrwastl, it's reuben. i wrote chardisp using serdisplib.
It's nice to see that development contimues as usual
I want to help, I will try and give this library some publicity...
Maybe if you or I or someone else writes a program that displays useful information using serdisplib more interest will be generated.
I recently aquired another nokia 5110 screen and will get it all wired up to work with serdisplib.
Reuben.
hello reuben,
such a program will be part of the upcoming version (i used the font-stuff of libgd which already includes 5 standard fonts and the ability to load truetype fonts. this program will also be able to display pictures (jpg, png, maybe gif) which is also done using libgd).
i don't know when the new version will be ready to release because it will contain a lot of changes / enhancements / ...
/wolfgang
Wow, thats great, do you think you'll incorporate the font/picture stuff into serdisplib also?
i'm not sure yet.
problem: libgd seems not to be a standard library.
maybe i'll pack font/image processing stuff into a separate library (so that libserdisp's requirements will remain low). what will remain in libserdisp will be the preliminary colour support that will come up with the next release (colour stuff is a work-in-progress though and the first colour display will be part of version next but one)
new displays in the next release:
* t6963-displays (yes, serdisplib now even supports parallel displays)
* 6210/6310/compliant displays (i think all 96x60 nokia displays)
(these two are working fine. some clean-up is necessary and documentation is to be done)
/mrwastl
Maybe you could just offer libgd for download on your site to make it easier. The little chardisp hack-up program that i wrote used fonts from libgd also.
However, I had a problem with speed, there was a delay which was introduced when I started using loadable fonts (even though the fonts werent of any standard, they were just a simple format)
I'm sure you wont get the same problem.
also, I was wondering which distribution/version of linux you're using?
i'm developing serdisplib using redhat 9 (this is my vdr-machine. no need for an update)
libgd is part of virtually every linux-distribution i know, but it is NOT part of (for example) openbsd by default.
/wolfgang
Fair enough, I'm running Gentoo linux on my home network server.
I'm installing ('emerging') gd now as it is not part of this distro by default, but then again not much is.
maybe if i get some time i'll make some ebuilds for the next version of serdisplib (can't be too hard)
Reuben.
reuben.bond@gmail.com
hi !
I have a project close of your :)
http://sourceforge.net/projects/thacidlcd
my goal is to make a library supporting the most possible controllor, with behind functionality "of graphic environment" (widget, 3d engines ...), but also a very flexible program exploiting this library (and others too ;)) to be able to display any kind of information (system, weather, etc...).
For the moment I left only one version the library already exploiting the HD44780, T6963 and a simulator in SDL, and integrating some widgets.
But I already wrote a good part of the other program, I have just still some details to work to be able to leave a functional version.
I follow your project for some time already.
I thought of making a plugin exploiting your library for the main program, but perhaps that a co-operation between our two projects would be more interesting?
what do you think about it?
Lexa (deadog)
i wouldn't pack too much functionality into one library if i was you.
i have this problem just now as next version will contain preliminary colour support and also some graphics stuff (fonts, ...). probably i will split the whole thing up and leave controlling stuff (drivers, device-access, colour) in serdisplib and create a separate library for graphics-stuff.
i want serdisplib to be open to as many (gfx-) displays as possible (colour, serial, parallel) but under the condition of needing as few requirements as possible (no X11, gfx-libraries, ... as prerequirement). stuff that will require such requirements will all go into a separate library (that's the plan).
using serdisplib in your program: why not. the API will not change that much (except of serdisp_setpixel() is now a little redefined in its function and serdisp_colour() will be the function to use) (setpixel() will only understand display-specific colour info in contrary to setcolour() which will understand rgb-colour entries independent to the display used.
well, i think of programming such a program on my own based on xml, sometimes .. but that's the big advantage of programming a library: you can put near everything on top of it .. so if you program a library i will be able to use it too.
one request (just saw that gnome-foundation-logo stuff): please don't put too much 'gnome' into it (better nothing of it). i don't see any cause why such a project should be dependend on any widgetset, be it qt/kde, gtk/gnome or anything other.
/wolfgang
Hum, there is incomprehension (normal, I did not explain large thing).
The project is divided into two parts. The library and a soft for exploiting the bookshop.
The library incorporates the basic drivers. All the functions of the controllers are exploitable there.
A level on the top of the drivers there is a generic exploitation of the functions, common to all drivers.
It is here that there is a concept of widget.
Why put that at it? To facilitate the use of lcd as if it were a conventional graphic interface, but also to allow to easily adapt all that in microcontroleurs (and that why the library is in C, and not C++ or other object language).
The library don't call other external library, except SDL to be able to make debug easily.
The purpose of the external program is simply to display any kind of information on lcd, some is the mean of communication (usb,//, seriel...).
It has a very modular architecture. And if you see the gnome logo, it is because one of the user interfaces of the program, integrated like module actually, will be made in gtk. There will be others, like shell, or wxwidget, etc...
(shell because it's the most simple, and already code, gtk because i want to have a friendly user interface, wxwidget because a friend is addict and want to code it :D)
Another application of this program is to be able to use external scripts to be the more interractif as it possible with the external events (for example, to currently test I had fun to reveal an animation on my lcd when I connect my usb key :) )
(oh, I'm also sorry for my poor english, I'm french ;-) )
Hello, I'd like to be able to get the program you're developing, are you going to setup a website for it?
I''m really interested in the idea of being able to compile LCD programs for PIC processors, using C. Maybe if i get time i can give it go...maybe trying to port serdisplib, or just hacking up a cut-down, simplified version.
oh, sorry, I miss the prec. monitor mail ;-)
Well, I had said it in my first message :-) : https://sourceforge.net/projects/thacidlcd
@vicevirtue
i already thought of doing something like that (using ATMELs because i don't like the complicated memory-handling of PICs - well: i heard that new PICs have linear memory access. that would render things way easier).
it would be nice if you would carry out this project!
but i think it would be better not to port serdisplib (or any other lib) but to create an independent PIC/ATMEL project (using a modular design, a display independent part (protocol, bi-directional) and display-specific modules. so serdisplib (and other libraries) would just need to interface that protocol (bi-directional, so your protocol may return display-specific informations such as depth, dimensions, capabilities, ...)
some years ago i fooled around with PICs. i used PIC-assembler for my stuff but when i remember correctly, you may also use C-programs for this (AVR/ATMELs even have an adapted gcc-compiler and environment for this!)
greetings
/wolfgang
OK.
I rather thought of doing that by define instructions, not a part apart, it is less heavy to manage.
but It should be better to continue to discuss about that on the ThacidLCD's sf forum ;-)
hallo
this is my problem:
epia:/home/achim/kgw/lcd/serdisplib-1.94 # ./testserdisp -n LSU7S1011A
Error: Unable to open /dev/parport0, additional info: ioctl(PPCLAIM) failed for device /dev/parport0 (cause: No such device or address)
can anyone help? i am new to linux
thx Achim
hi achim
are you running your display as root or as user?
if as user:
you need write permissions to /dev/parport0
(look if /dev/parport0 has at least the following permissions: crw-rw--- and user == root and group == lp
looks like this (example):
crw-rw---- 1 root lp 99, 0 Feb 27 13:58 /dev/parport0
if this is not the case:
chmod 0660 /dev/parport0
chown root.lp /dev/parport0
(as root)
then you need to add your user to group 'lp', relogin and you should be allowed to use /dev/parport0.
if /dev/parport0 is still not accessable:
* look, if some other software (cups, ...) is running
if so -> stop cups
* loop (as root), if module 'ppdev' is loaded ->
lsmod | grep pped
/wolfgang
It is very hard for me to implement new connection types. Wouldn't it be better to give every connectiontype a seperate .c and .h file and then do all the stuff in there.
This could be done with a struct of functionpointers like this:
typedef struct contype {
serdisp_CONN_t* (*SDCONN_open) (const char sdcdev[]);
void (*SDCONN_close) (serdisp_CONN_t* sdcd);
void (*SDCONN_write) (serdisp_CONN_t* sdcd, long data, byte flags);
void (*SDCONN_writedelay) (serdisp_CONN_t* sdcd, long data, byte flags, long ns);
long (*SDCONN_read) (serdisp_CONN_t* sdcd, byte flags);
void (*SDCONN_commit) (serdisp_CONN_t* sdcd);
};
and one function like:
contype* get_new_contype_PARPORT( ... some options ...);
in the main init process there should only be this:
switch(sdcd->conntype){
.....
case SERDISPCONNTYPE_PARPORT:
contype * mycontype = get_new_contype_PARPORT( ... options ...);
break;
This would make it much easier to develop new contypes and clean up the code a lot.
Hopefully I made myself clear ? :-)
I would like to help on this.
My main goal is to use a Atmega16 or simular to interface a parallel display.
Greetings, Peter Rustler
PS: Excuse me for my bad english.
yeah, i'm thinking about such a change since quite a long time (because of additional conn. types already in the devel-code)
but not in the next version (don't want to open just another 'construction site' in the code - or the next version will never come to an end ...)
/wolfgang