Hi Seb,
Were you mind reading? ;-)
Sebastien LELONG wrote:
> I've come accross LCD library files. I remember there were lots of posts
> about
> these. There were issues, like:
>
> 1. how do we name lcd libs ? Using a "lcd_" prefix (lcd_hd44780_4) or not ?
> 2. proc/func should be prefixed by "lcd_", as many proc/func in libraries
> 3. should all lcd libraries implements the same interface ? That is, should
> we have the same proc/func names in all lcd libs ?
> 4. what do we do with Richard'ds lcd lib ?
> 5. there were hardware stack issues. Could the last jalv2 compiler (2.4h)
> help us, with its new pragmas ?
>
>
> About 1.: I think we all agree to keep the "lcd_" prefix, to prevent
> namespace
> collision.
I agree (complies with JSG wiki)
> About 2.: as of right now, this is not true. Specifically, lcd_hd44780_4.jal
> has proc/func starting "hd44780". Some would *really* need refactoring
> (hd44780_line{0,1,2,...}), hd44780'put is *exactly* the same as lcd'put.
> Why ? (I cannot see any good reasons we should duplicate this kind of code).
> I know this about "oldskool" jal, but old school doesn't mean duplication of
> code... More, if there's a need of being oldskool compatible, maybe a better
> approach is to put the proc/func in a "lcd_hd44780_oldskool.jal", with
> proc/func using our new lcd_hd44780_4 (with pragma inline, etc...). Eur ?
I have my doubts about the usefulness of the 'oldskool' additions of
Eur. Old programs have to be converted to new libs and naming
conventions anyway, so why not convert them to new libraries too at the
same time?
Apart from this I do not like the redundant and on some places
inefficient code (in terms of program memory use).
I have been working on some improvements for the lcd_44780_4 lib (such
as support for 4-line displays), and I had the intention to remove the
oldskool additions. But I'll wait a little until I have heard others'
opinions.
> About 3.: this is not the case. Should we still try to standardize our libs
> with one interface ? Is it too much work ? Is it too early for now to
> consider this ? Will we never have more than one lcd attached to a PIC ?
We have discussed earlier that different similar libraries may be
useful: some people prefer simple libraries, other suffisticated libs.
I see the device files as the lower layer and function libraries as the
layer between application program and device files. The setup of the
device files is such that libraries can be made to a large extent
device-independent. In the same way I think the function libraries
should be set up such that applications can to a large extent be
library-independent. This requires (among others) a consistent naming
convention, procedures with the same functionality should have the same
name, for example lcd_setup() and lcd_writechar() in one library should
have the same names in another lcd library.
> About 4.: please advise ! Richard's lib has nice high-level procedures
> (lcd_time, lcd_date,lcd_progress, ...). Maybe we could extract them to
> another lcd lib, so people can decide to include it or not.
Nice and useful functions, but indeed a higher level than basic lcd
control. Would it be difficult to split-off these functions into an
'lcd-additions' library? That would also make it possible to use these
higher level functions in combination with other basic lcd_libraries
(provided the procedure names of the libs match!)
> About 5.: jalv2 2.4h has introduced new pragmas not to generate return, but
> goto instead, which may be useful here to save some stack.
I have not tried these new pragmas, but these seem useful, certainly for
libraries with deepeer nesting.
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
