On 2 Oct 2008, at 08:03 , Sebastien LELONG wrote:
>
> Hi all,
>
> 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.
OK.
<aside> About namespaces: should procedures functions be named like:
device_function()
or as:
function_device()
Right now, we have both :-(
</aside>
> 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 ?
All oldskool junk can be tossed. But line/postition procedures
should be explained better. I switch between a 16 and 20 char LCD and
it is confusing.
Also, lcd_clearscreen should set cursor at the first position.
> About 3.: this is not the case. Should we still try to standardize
> our libs
> with one interface ?
As much as possible.
> Is it too much work ? Is it too early for now to
> consider this ?
No, no. Because it is a matter of principle.
> Will we never have more than one lcd attached to a PIC ?
No, but we will have different ones. I do so now.
> 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.
Another lib. An LCD lib is used quite early in the learning process
(either an LCD or a serial connection and with USB these days, the
latter is harder).
So newbies should not be confronted with a huge lib with all kinds of
possibilities.
print.jal takes care of a lot of number formatting.
Everything else should go in a separate lib.
> 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 can help with that, but we need to agree on 1..4 first.
You're the Benevolent Dictator, you have our answers. Make a decision.
---
ir EE van Andel [EMAIL PROTECTED] http://www.fiwihex.nl
Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands
tel+31-546-491106 fax+31-546-491107
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
