AVR library for LCD and 1wire?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,
I am looking for a library written in GNU C for the AVR which supports
HD44780 LCDs in 8-bit port mode, 1wire (Dallas) and UART. The library will
be used in a commercial project and should therefore be LGPLed or simmilar
license.
I am sure I remember there were several good implementations available from
www.avrfreaks.net
but this site appears to be down.
Any hints?

Thanks and regards
Roland



Re: AVR library for LCD and 1wire?

Quoted text here. Click to load it

If it's for a commercial (or otherwise closed-source) project, you can't
use LGPL'ed software without a lot of hassle (involving providing unlinked
object files instead of source files).  Suitable licenses are
typically either BSD-style, or modified GPL/LGPL/MPL (with a specific
allowance for linking to closed source embedded software).

Quoted text here. Click to load it


Re: AVR library for LCD and 1wire?
Quoted text here. Click to load it


There must be millions of them around but its so easy to write your own its
hardly woth looking for them.

Quoted text here. Click to load it

even simpler, the standard library can be used.

Quoted text here. Click to load it

Ok that might take some thinking about, try looking on the dallas site.

Re: AVR library for LCD and 1wire?
Quoted text here. Click to load it

Suppose you found something appropriate for the One-Wire protocol and the target
micro, which is highly unlikely, and suppose it was LGPL, and suppose you
understood
the LGPL and did not have any nervous legal types on staff. Would it really be a
hassle to comply with the LGPL?

I see this opinion around here, and I don't understand it. Also the likelihood
of being asked for code and objects is very small for black box products, but I
would suggest being preemptive and posting it in a dark corner of your web site.

Re: AVR library for LCD and 1wire?

Quoted text here. Click to load it
target
Quoted text here. Click to load it
understood
Quoted text here. Click to load it
a
Quoted text here. Click to load it
site.

How much of an issue it would be depends very much on the circumstances.
If you include GPL'ed code directly in your application, then you have to
make the entire source code available to anyone to whom you have provided
binaries.  That doesn't mean you have to make it freely downloadable from
your website to anyone who wants it, but you have to include a written
notice valid for three years along with the system you are selling or
giving away, and charge no more than a reasonable distribution cost.

For the GPL, that much is reasonably well known.  The LGPL is subtely
different, and many people (including the O/P) don't fully understand the
difference.  The LGPL was made specificly for libraries on "big" systems
with shared libraries.  You can treat the LGPL'ed code much like GPL'ed
code, or you can *dynamicly* link it to code under any other license (the
headers of LGPL'ed libraries are excepted from the license).  The idea is
that if you sell me a closed-source binary using an LGPL'ed library, I can
update that library and re-link the program to use the new version of the
library.  For programs in "big" systems with dynamic library loading,
there is no problem.  For embedded systems (using static linking), it's a
great hassle if you want to keep your code hidden.

The effects will depend on your market and your product.  If you are
working with "big" systems (say, ucLinux or pc software), there is no
problem.  If the cost is in the hardware, or you are (for other reasons)
quite happy to release your software code, then there is no problem.  If
you are sure your market is highly unlikely ever to read or take up your
written offer of the source code, then you have no problem. But in many
cases, it's an extra layer of complexity that you really don't want, and
you should therefore think just as hard about using LGPL'ed code as GPL'ed
code.


Re: AVR library for LCD and 1wire?
On Mon, 31 Jan 2005 09:38:41 +0100, David

Quoted text here. Click to load it
target
Quoted text here. Click to load it
understood
Quoted text here. Click to load it
be a
Quoted text here. Click to load it
I
Quoted text here. Click to load it
site.
Quoted text here. Click to load it


This does not exclude the use of LGPL'd code in smaller systems. If
one writes a small wrapper for the library, which basically allows the
rest of one's firmware to be able to find out via the wrapper code
where all the library routines are, then the library (+wrapper code)
can be updated without having to re-load or link the main firmware
code. AFAICS this satisfies the LGPL license. The wrapper code
must of course be made available. I think such a open source wrapper
with a suitable license would actually be quite usefull.

I have done a similar thing in the past where I kept my own library
code in a seperate EPROm, from my main code which was still being
written. This was done to speed up download time. I was downloading
s-records over a 9600 serial link. Total program size was almost 500K,
so it took forever. By keeping the debugged library code in a library
I cut the average download size to about 30K of code.

Any errors in my reasoning regarding the LGPL license ?

Regards
   Anton Erasmus


Re: AVR library for LCD and 1wire?

Quoted text here. Click to load it

As far as I can see, you are effectively implementing a system of dynamic
linking, which (by my understanding) is LGPL-compatible.

Quoted text here. Click to load it


Re: AVR library for LCD and 1wire?
Quoted text here. Click to load it
target
Quoted text here. Click to load it
understood

Oops, looks like it was not so unlikely.

Quoted text here. Click to load it
a
Quoted text here. Click to load it
site.
Quoted text here. Click to load it

Not subtle at all. Very big difference.

Quoted text here. Click to load it

LGPL does not make a distinction between big and small systems, and it
explicitly says it does not make a distinction between static and dynamic
linking.

Quoted text here. Click to load it

It's quite likely that the end user cannot make use of any libraries you
supply under the LGPL. That's not your problem.

Where is the hassle? Why is supplying the libraries that you yourself
received as a 'gift' so much of a problem? Just post it on your website.

Quoted text here. Click to load it

I think you have projected your biases on this topic.

Why would I publish under the LGPL?

*) Want to receive credit
*) Want to get back any improvements that someone makes
*) Don't want to publish under GPL (scare people off)
*) Trust the LGPL to do this

If I publish under the LGPL and offer something of value for "free",
or even for sale, I can't help anyone who cannot be bothered to understand
the LGPL.

Myself, I hate lawyers and legal speak, and believe all laws and contracts
should be transparent to everyone. If there is a gotcha somewhere, I would
be pissed and renege on whatever I though I was offering under a simple
language license. I would recommend everyone else do the same. I would
claim deceit and make things right in another way. But this is not going
to happen, or it would have happened before now.

I think the LGPL is a lot clearer and safer than many bought, non-free
library licenses, but you are welcome to you opinions, of course.



Re: AVR library for LCD and 1wire?
[...]
Quoted text here. Click to load it

I realize I mixed a couple of things here. One, as a publisher under the LGPL,
it is your responsibility to understand what you are doing. The LGPL is a
document you can use - it owes you nothing.

Another, as a user of a library, if you feel you have been tricked into
something,
such as unintentionally obligating yourself to publishing source code that you
did not want to, call bullsh*t and start over from there. But that's just not
going to happen.


[...]

Re: AVR library for LCD and 1wire?

I'm not a lawyer, but I've done my best to read the LGPL and the GPL.  My
comments to your reply are found below, and are my interpretations of what
I've read.  It is quite possible that I'm wrong, and I'm happy to be
corrected if I am, but I've had no luck finding any sort of "definitive"
answers.  I'm confident I understand the rights and responsibilities that
follow the use of GPL'ed code, and also the use of BSD-style, MPL-style,
and the various explicitly modified licenses that are typically used for
libraries such as the avr-libc.  I'm far from sure about the LGPL,
however, and if I wanted to use LGPL'ed code in an embedded system, I'd
ask the author regarding his/her intentions and wishes.  (Use on
dynamically linked systems is another matter.)


On Mon, 31 Jan 2005 17:36:29 +0000, Bryan Hackney wrote:
Quoted text here. Click to load it
target
Quoted text here. Click to load it
understood
Quoted text here. Click to load it
be a
Quoted text here. Click to load it
I
Quoted text here. Click to load it
site.
Quoted text here. Click to load it

Paragraph 6b of http://www.gnu.org/copyleft/lesser.html explicity
describes using "a suitable shared library mechanism for linking with the
Library".  It doesn't distinguish "big" and "small" systems - that's just
my way of drawing a line between embedded systems with staticly linked
programs, and systems with dynamic library loading and linking.

Quoted text here. Click to load it

There is no problem with supplying source copies of the libraries,
including any changes made to the libraries (such changes are "derivitive
works" of the library, and therefore also LGPL'ed).  The question is about
code from the "work that uses the Library", as the LGPL calls it.  That
code (i.e., your application code) is per se not affected by the LGPL.
However, to quote from paragraph 5:

     However, linking a "work that uses the Library" with the Library creates
     an executable that is a derivative of the Library (because it contains
     portions of the Library), rather than a "work that uses the library".
     The executable is therefore covered by this License. Section 6 states
     terms for distribution of such executables.

Section 6 gives two basic ways to fullfill the LGPL requirements when you
distribute your executable linked with the library - you can a) provide
your code "as object code and/or source code, so that the user can modify
the Library and then relink to produce a modified executable containing
the modified Library", or you can b) use a suitable shared library
mechanism.  As with the GPL, you can also simply include a written offer
to provide the object/source code on request.

Given that the compiler and linker for embedded systems are typically not
included in the target's operating system, section 6 also requires that
these be made available.  If you are not able to distribute them (for
example, if they are proprietry applications), then you can't use 6a), and
must use some sort of dynamic linking.

Quoted text here. Click to load it

What biases do you think I have?  I am a heavy user of open source
software, and a heavy user of closed source software.  I believe there is
a place for a variety of licenses, just as there is a place for a variety
of programming languages and processor architectures.  There is also a
place for the LGPL, including in embedded systems, as long as users
remember that with staticly linked systems it is effectively the same as
the GPL.

Quoted text here. Click to load it

Sure - there are plenty of good reasons for choosing the LGPL.  When you
write your code, you are absolutely free to choose the license you want.
But if you write an AVR library for using one-wire devices and license it
under the LGPL, then you will effectively require users to open-source
(GPL, LGPL, or a number of other licenses) their application code as well
as their modifications to your library.  If that's what you want, then
that's fine - as long as both you and your users are aware of this.  If
you want only to require publishing of changes to your library code rather
than the complete application code, then choose a different license, such
as the MPL, or write an exception clause.

Quoted text here. Click to load it

Indeed - I much prefer licenses such as the avr-libc license at
http://www.nongnu.org/avr-libc/LICENSE.txt which begins:

    The contents of avr-libc are licensed with a Modified BSD License.

    All of this is supposed to be Free Software, Open Source, DFSG-free,
    GPL-compatible, and OK to use in both free and proprietary applications.

I am happier considering the intentions of the license than trying to
understand the fine print.  The intentions of the LGPL are quite clear -
if you use an LGPL'ed library in your application, you must allow the end
user to modify the library and use the modified library with that
application.

Quoted text here. Click to load it

The LGPL may be clearer and safer than some non-free licenses, but that
doesn't make it clear or safe.  There are other open licenses that are
better for use in embedded systems.



Re: AVR library for LCD and 1wire?
Quoted text here. Click to load it

[...]

Quoted text here. Click to load it

You are correct. If a linking utility for the executable is not free, then
static linking may be a problem for you. If a linking utility is free, there
is no problem.

Quoted text here. Click to load it

This is not the case for gcc-avr, in which a linking utility is free.

Quoted text here. Click to load it

[...]

Re: AVR library for LCD and 1wire?

Quoted text here. Click to load it

Try this. Has a great bootloader too.
http://www.microsyl.com/



Site Timeline