Indeed.

I'm about to document and extract the common API, which must be implemented
in device library. I can see some weird things in glcd_common.jal regarding
this. For instance, I want to specify mandatory and optional parameters. In
glcd_common, we have:

if !defined(GLCD_X_PIXELS) then
   const GLCD_X_SIZE = 1


else
 ....

GLCD_X_PIXELS must be defined anyway because it's used elsewhere, so we
should remove this logic to explicitely assume it's been previously defined.
Do you agree ?


I was also thinking about letting pen/bg colors being optional, as it is
now:

if !defined(glcd_background_color) then
   const byte GLCD_BACKGROUND_COLOR = 0
end if
if !defined(GLCD_PEN_COLOR) then
   const GLCD_PEN_COLOR = 1
end if

but since color value can have different meaning, I wonder if this is a good
idea. We need to remember that, for a new device lib implementer, each
parameter which isn't required (because "protected" by some "if defined"
logic), will be left as default in the first developement phase. This can
cause confusion: what must be defined in device lib must be exposed (not
defaulting with "if defined").


Please have a look at glcd_common.jal header, I wrote some documentation
about our common API.

I'm waiting for your feedback before exposing mandatory parameters
(GLCD_X_PIXELS, etc...).

Cheers,
Seb


2011/3/28 mattschinkel <[email protected]>

> Another thought... glcd_common glcd_write_char_pbp can go out the door
> if we use the same block write procedures I gave above... if not
> defined already in glcd device library.
>
> Matt.
>
> On Mar 28, 5:15 am, Sebastien Lelong <[email protected]>
> wrote:
> > A good example is glcd_clear_screen. glcd_clear_screen is defined in
> Nokia
> > 3310, but there's also an generic implementation in glcd_common. This
> > generic definition becomes available if none are previously defined.
> Still,
> > there could be two implemention, one generic, one specific.
> >
> > Thus, in glcd_nokia_3310 library, glcd_clear_screen() should be renamed
> to
> > nokia_clear_screen(). In sample code, you instantly know which one you're
> > using, possibly a more efficient one when using nokia_clear_screen().
> >
> > nokia_clear_screen()
> > glcd_clear_screen()
> >
> > Cheers,
> > Seb
> >
> > 2011/3/28 Sebastien Lelong <[email protected]>
> >
> > > I can see other things to rename: when something is specific to the
> glcd,
> > > it shouldn't be prefixed with "glcd_" but something related to the
> display
> > > (eg. "nokia_" for mine). One exception: if the involved procedure is
> part of
> > > the required interface implementation, it'll obviously be prefixed with
> > > "glcd_". For instance, glcd_write_pixel() must be implemented in device
> > > library, as part of the glcd_common API interface. It's prefixed with
> > > "glcd_".
> >
> > > I think this will greatly help understand what's part of the common
> > > interface, what's specific, both at library level *and* sample, user
> code
> > > level.
> >
> > > Cheers,
> > > Seb
> >
> > > 2011/3/24 mattschinkel <[email protected]>
> >
> > >> I took a look to see variables/procedure names that should be change.
> > >> Here are my suggestions.
> >
> > >> procedures:
> > >> GLCD_FONT_USE -> GLCD_FONT (to be like var GLCD_PEN)
> >
> > >> variables
> > >> lcd_background_color -> glcd_background (again, to be like var
> > >> GLCD_PEN)
> >
> > >> and of course, everything that is currently starting with lcd_ should
> > >> change to glcd_
> >
> > >> Is there anything else?
> >
> > >> Matt.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/jallib?hl=en.
>
>


-- 
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to