Project structure, aim and license?

[Jop... (Jonas F. Jensen).]

Hi,

It's nice to see that there's others also interested in this
project... :)

Anyway, I think we should discuss project structure, goal/aim and
license, just to know where we're going and how...

I guess the goal would be a generic uip port for avr with various apps
and hardware support, right?

In terms of structure... I was thinking that maybe we should start by
checking a fresh uip 1.0 into SVN... Then add a subdirectory for avr-
enc28j60 and various subdirectories for other hardware
configurations... Apps could be stored in the apps subdirectory of the
uip directory layout...
I suggest we try to follow the uip coding style:
http://www.sics.se/~adam/uip/uip-1.0-refman/a00051.html
(At least just as a guideline, it doesn't have to be strictly
enforced).
What ideas do you have?

With regards to the license, I don't mind the New BSD License, however
if we're going to derivate code from Pascal Stang's avrlib, then we
probably should license the code under GPL... I don't know if Google
allows multiple licenses for different parts of the hosted code...
I don't know if we should license the project under BSD, except for a
few things with a different header, or perhaps we rewrite?... or if we
should license under GPL and leave the majority of the files with a
BSD header... As far as I can see there absolutely no license issues
if we go GPL, since we may relicense BSD code under GPL, but not the
other way around... Which may be implied if we'd put GPL code in the
SVN repository of a project that's BSD licensed...
Well, I just thought we should make up our mind about this issue,
right now... What do you think?
How do we resolve this license issue?

//Regards Jonas F. Jensen.

[Jesper]

Great initiative!

1. Project structure
Well, to me the uip structure wouldnt make much sense when we are
building a architecture specific implementation.
I mean the unix directory just sends the wrong impression and so on..
My suggestion is to continue the filestructure of my port (which is
sent to jonathan)
Where we have the uip code seperated by itself.
from root it looks like this:

/apps/* # Here all applications for uip is stored in
subdirectories

/arch/* # Here all architecture specific files are stored.
for example enc28j60 driver.. timer/clock implementations that are
specific to avr architecture.
# perhaps a subdirectory dividing each
implementation to specific avr device. (for example /arch/atmega32/*)

/uip/* # Here all uip specific files are stored except
uipopt.h and uip-conf.h these should be stored in /arch/DEVICE/* and
defined for each specific architecture.

/main.c # Should be kept generic and free from architecture
specifics
/config.h # (new file) defining for example which apps should
be installed and CPU freq. (this is later used in arch specific files
for calculating for ex. correct
# SYSTEM_SECOND).

This way all a user needs to do is to define what he wants in config.h
and everything will be compiled for him in a correct manner.
uip-opt.h and uip-conf.h could be discussed into a more smart way
perhaps since these options may vary on different applications.
With this way they would have to be completly filled with #ifdefs


2. Goal/Aim?
Well, good question.. Are we interested in making an "easy to install"
package for users to mainly just download, directly compile and then
use, or are we building a developers skeleton?
In my opinion we should target all users of all levels so installation
and configuration should be kept as easy as possible. If other
developers would so choose, a logical filestructure with good
documentation should provide a sufficient platform..
Perhaps a discussion regarding if configurations should be made from
makefile or in header-file..

3. Coding style
Using uip codestyle is a good idea.. I havent read it to in detail but
I believe it mainly focuses on uip application programming and not
code style in general. So perhaps a more general code style should be
used? However in my opinion the most important part is to keep the
code as architecture independant as posible, and only implement
interfaces later stored in /arch/DEVICE/* subdirectory..
That way users never have to change anything in application details,
only in /arch/..

4. Licensing
Well, I dont know that much about licensing, but if it is as you say,
that perhaps GPL licensing is required in parts of the code why not
make it easy and make all code GPL? What are the benefits to going the
BSD licensing way?

Regards
/Jesper






On 22 Apr, 12:56, "Jop... (Jonas F. Jensen)." <jop...@gmail.com>
wrote:

[jonatha...@gmail.com]

Hi!

I'm so happy to start a project like this... I was looking for other
people that like it as me, and I'm really glad to be working with both
of you!
Now, regarding to the quesitons, here are my thoughs:

1. Project Structure

I like the way that Jesper suggest, I think that the uIP code is just
a module, a function so we should keep it as is.
I think that the main goal of the project will be an easy way to
compile it and make it working quickly, then the user can start making
changes, etc...
So, I suggest something like this:

/apps/ // exactly like Jesper mentioned

/arch/ // Main directory for uC models, brands etc... dont forget
that maybe someone want to use this code to port it to other uC, by
this way we can also share it to other uC...

/drivers/ // here we should put all ethernet drivers, maybe inside
this directory we should put another one called "eth" (for enc28j60,
etc) and other (for example) "mmc" to add mmc/sd support, "lcd" to add
lcd support, etc.

/uip/ // well-known uip code

/main.c and config.c // like jesper said

/makefile // never forget this... :)

2. Goal/Aim

First of all, the main goal for this project is to create and mantain
a solid code that work with uip and avr uC.
This also should have support for other hardware devices, as I
mentioned, like mmc/sd, lcd, sensors, etc... because all of them can
be part of a webserver for example.
Of course, today our main goal is to make a solid port of uip to
avr... later we can talk and work over the support for other hardware
but just to keep in mind.
Another goal of the project should be a good help or documentation,
because I'm new at this world and I found that a lot of code around
the web dont work the first time that someone try to use it, but 1
week later yes... when you found a lot of specific-platform errors,
etc... I think that we should work over an open platform to let people
use it without big problems.
And the final goal... learn more about all of this!

3. Coding Style

I dont have too much problems with this, I think that doxygen work is
good for all people that want to know more about the code, as I said
before, we need a good documentation. Besides this, I agree with
Jesper.

4. Licensing

I dont know anything about this, I think that we should select our
license in google code as GPL... then each file from other people with
other licenses will be mentioned on the header of each file.
Also we should advice about this in our readme or license file...
"this project is GPL, some files from other authors vary from this"


Well, I can't wait to start... when we got these things solved we
should make the changes on the google code and start sending some
advises to other mailing lists to get people over here, besides our
work, the most important thing is have people testing this too.

Regards,

Jonathan

[Jonas Finnemann Jensen]

Hi,
 

1. Project Structure

...

/apps/      // exactly like Jesper mentioned
/arch/      // Main directory for uC models, brands etc... dont forget
that maybe someone want to use this code to port it to other uC, by
this way we can also share it to other uC...
/drivers/  // here we should put all ethernet drivers, maybe inside
this directory we should put another one called "eth" (for enc28j60,
etc) and other (for example) "mmc" to add mmc/sd support, "lcd" to add
lcd support, etc.
/uip/        // well-known uip code
/main.c and config.c // like jesper said
/makefile  // never forget this... :)

I think that's a good idea... Maybe we should rearrange the /lib/ directory, to contain directories of libraries (kind of like the /apps/ directory), things that are not drivers, apps, arch dependent or directly uip related, stuff like filesystems (fat), sha1 and stuff like that...

Perhaps a discussion regarding if configurations should be made from
makefile or in header-file.

I think both things will be necessary... Yes, with a few shell scripts we could do most of it in makefile, but I think header files are more convenient for most of it... but things like activating new apps, drivers etc. requires compiling new things... so they would require configuration in makefile...
However things like hardware specific settings for port etc, should probably be done in a config.h file in a subdirectory of the /drivers/ directory...

3. Coding Style

Well, I agree with you guy... How the code looks is not that important to me either, besides we can always clean that up... But documentation is very important, I don't have any experience with doxygen, but can't take long to learn the tags...

4. Licensing
I dont know anything about this, I think that we should select our
license in google code as GPL... then each file from other people with
other licenses will be mentioned on the header of each file.
Also we should advice about this in our readme or license file...
"this project is GPL, some files from other authors vary from this"

I think GPL is a good idea too... Since it would be considered copyright infringement to distribute GPL code under BSD, which people might assume we do, if we put GPL code in our repository when the primary license of our project is BSD... whereas it's not copyright infringement to distribute BSD code under GPL, it would just make it harder to backport stuff to uip as it's BSD, but if we put a BSD header on those files, they could be dual licensed...

Well, let's get started... Are we starting from scratch or from previous port? I suggest anybody who knows checks in a copy to SVN... I've change the project license to GPL, if you disagree change it back, I just thinks we'll get served best (e.g. Fewest license issues) with GPLv2 and the "or later" in the headers...

--
Regards Jonas Finnemann Jensen.

[jonatha...@gmail.com]

Glad to hear that!!

I have a functional port of uip1.0, running into an ATmega32 with
ENC28J60, also a mmc/sd with fat support from Jesper.
It's working fine for me, I did a few changes, but maybe we can work
over this? just let me know and I will sent them to you...

It's fine for me the change on the google code, also I dont know it
very well, I think that all should be "Owners" of the group? I dont
know, just do what you think is the best.

Regards,

Jonathan

On Apr 22, 7:56 am, "Jop... (Jonas F. Jensen)." <jop...@gmail.com>
wrote:

[Jonas Finnemann Jensen]

Okay...

If you mail me you version, I'll merge it with my port and a clean port of uip and put in on SVN tonight... well, hopefully tonight, depending on how much time it takes...

It's fine for me the change on the google code, also I dont know it
very well, I think that all should be "Owners" of the group? I dont
know, just do what you think is the best.

I think that's fine... Do you guys have a google account so we can add you...

--
Regards Jonas Finnemann Jensen.

[Jesper]

Sounds great..

We should probably have a doc catagory too.
Containing design/system spec. and things like that...

Its easy too become lazy and skip it but those things are invalueable
for other developers when trying to start their own development inside
the project..
Dont know how google group works, is it possible to make the docs a
separate "product" or should we put it in the same SVN as source?

I would gladly sit down and write a system spec. for it, but
unfortunatly I will be very busy the next couple of weeks..
I have major releases to do at work, and a thesis to finish all in the
end of may.. So its gonna be a busy month.. =)

regards

/Jesper

> >http://www.sics.se/~adam/uip/uip-1.0-refman/a00051.html<http://www.sics.se/%7Eadam/uip/uip-1.0-refman/a00051.html>

> > > (At least just as a guideline, it doesn't have to be strictly
> > > enforced).
> > > What ideas do you have?
>
> > > With regards to the license, I don't mind the New BSD License, however
> > > if we're going to derivate code from Pascal Stang's avrlib, then we
> > > probably should license the code under GPL... I don't know if Google
> > > allows multiple licenses for different parts of the hosted code...
> > > I don't know if we should license the project under BSD, except for a
> > > few things with a different header, or perhaps we rewrite?... or if we
> > > should license under GPL and leave the majority of the files with a
> > > BSD header... As far as I can see there absolutely no license issues
> > > if we go GPL, since we may relicense BSD code under GPL, but not the
> > > other way around... Which may be implied if we'd put GPL code in the
> > > SVN repository of a project that's BSD licensed...
> > > Well, I just thought we should make up our mind about this issue,
> > > right now... What do you think?
> > > How do we resolve this license issue?
>

> > > //Regards Jonas F. Jensen.- Hide quoted text -
>
> - Show quoted text -

[Jonas Finnemann Jensen]

Google code has a wiki, I think it would be great for system/design/"project structure" docs/specs... Alternately we might be able to write it as static doxygen pages in the documentation, anybody know if that's possible and how...

I think it's important to have such specs too...

By the way, do you have a google account so we can add you to the GoogleCode project?
http://code.google.com/p/avr-uip/

--
Regards Jonas Finnemann Jensen.

[Jesper]

I took a look at the code-page and had som questions..

What part is based on "AVR port by Louis Beaudoin AVR Port
(www.embedded-creations.com) "
Nothing from my "branch" uses anything from him..

In the parts I sent to Jonathan only uIP and the ENC28j60 driver from
pascal stang is used..
And delay.h & delay.c is from "Jesper Hansen
<jesperh@....snipp....>".. However that part can probably
just be removed, and is easaly replaced.. Only place its used i think
is in the enc-driver.. and one could just as easaly use a timer... or
we can implement our own delay... I think the less external code the
better...

On 23 Apr, 19:37, "Jonas Finnemann Jensen" <jop...@gmail.com> wrote:
> Google code has a wiki, I think it would be great for system/design/"project
> structure" docs/specs... Alternately we might be able to write it as static
> doxygen pages in the documentation, anybody know if that's possible and
> how...
>
> I think it's important to have such specs too...
>
> By the way, do you have a google account so we can add you to the GoogleCode

> project?http://code.google.com/p/avr-uip/

> > > - Show quoted text -- Dölj citerad text -
>
> - Visa citerad text -

[Jonas Finnemann Jensen]

I think it's just a temporary description... I guess we'll be editing it later once we know more about what it's been based on...

The delay things are implemented in avr-libc, I used them in my port they worked just fine there, also enc28j60... :)

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

Hi Guys... sorry by the delay in reply, I wake up today and I feel
sick... I just come to the pc and see your emails...
About the "AVR port by louis..." I just added that because it's a
temporary description... Also, the first port that I used was from
him... I think it was a uip0.6 port...

We will change this when we have a more big idea.

Can I attach here my zip file? I dont know if it will work... please
tell me.

Regards,

--
Jonathan Granade
WebCom-Design

Jonas Finnemann Jensen wrote:
> I think it's just a temporary description... I guess we'll be editing
> it later once we know more about what it's been based on...
>
> The delay things are implemented in avr-libc, I used them in my port
> they worked just fine there, also enc28j60... :)
>
> --
> Regards Jonas Finnemann Jensen.
>
> On Wed, Apr 23, 2008 at 9:58 PM, Jesper <jder...@hotmail.com
> <mailto:jder...@hotmail.com>> wrote:
>
>
> I took a look at the code-page and had som questions..
>
> What part is based on "AVR port by Louis Beaudoin AVR Port

> (www.embedded-creations.com <http://www.embedded-creations.com>) "

> Nothing from my "branch" uses anything from him..
>
> In the parts I sent to Jonathan only uIP and the ENC28j60 driver from
> pascal stang is used..
> And delay.h & delay.c is from "Jesper Hansen
> <jesperh@....snipp....>".. However that part can probably
> just be removed, and is easaly replaced.. Only place its used i think
> is in the enc-driver.. and one could just as easaly use a timer... or
> we can implement our own delay... I think the less external code the
> better...
>
> On 23 Apr, 19:37, "Jonas Finnemann Jensen" <jop...@gmail.com

> <jop...@gmail.com <mailto:jop...@gmail.com>>

[Jonas Finnemann Jensen]

Can I attach here my zip file? I dont know if it will work... please
tell me.

Just try it... or mail it to me directly...

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

Ok, here is the zip file, and I need to made a few corrections...

I made a mistake... I have a 0.9 port of uip... not 1.0.
When I took the jesper code I spent some hours trying to compile it...
without success, so I decided to take the code I needed from there to my
current working uip-avr... later that I did the same with the mmc/sd
driver from jonas.

So, which I attach here is a uip-avr port version 0.9 which was done by
first time by Louis Beaudoin, with a driver for enc28j60, mmc/sd support
from jonas and timer changes by jesper.

Yes, It's like Frankestein... but it works and compile... so let's see
if we will be using this code or maybe jesper port from uip 1.0.

Regards,

PS: Please sorry about the code... it's not clean, but during test I
dont mind in that...

--
Jonathan Granade
WebCom-Design

> > <mailto:jder...@hotmail.com <mailto:jder...@hotmail.com>>> wrote:
> >
> >
> > I took a look at the code-page and had som questions..
> >
> > What part is based on "AVR port by Louis Beaudoin AVR Port
> > (www.embedded-creations.com
> <http://www.embedded-creations.com>
> <http://www.embedded-creations.com>) "
> > Nothing from my "branch" uses anything from him..
> >
> > In the parts I sent to Jonathan only uIP and the ENC28j60
> driver from
> > pascal stang is used..
> > And delay.h & delay.c is from "Jesper Hansen
> > <jesperh@....snipp....>".. However that part can probably
> > just be removed, and is easaly replaced.. Only place its
> used i think
> > is in the enc-driver.. and one could just as easaly use a
> timer... or
> > we can implement our own delay... I think the less external
> code the
> > better...
> >
> > On 23 Apr, 19:37, "Jonas Finnemann Jensen" <jop...@gmail.com
> <mailto:jop...@gmail.com>

> > <mailto:jop...@gmail.com <mailto:jop...@gmail.com>>> wrote:
> > > Google code has a wiki, I think it would be great for
> > system/design/"project
> > > structure" docs/specs... Alternately we might be able to write
> > it as static
> > > doxygen pages in the documentation, anybody know if that's
> > possible and
> > > how...
> > >
> > > I think it's important to have such specs too...
> > >
> > > By the way, do you have a google account so we can add you to
> > the GoogleCode
> > > project?http://code.google.com/p/avr-uip/
> > >
> > > --
> > > Regards Jonas Finnemann Jensen.
> > >
> > >
> > >
> > > On Wed, Apr 23, 2008 at 7:28 PM, Jesper
> <jdere...@hotmail.com <mailto:jdere...@hotmail.com>

> > <mailto:jdere...@hotmail.com <mailto:jdere...@hotmail.com>>>

> wrote:
> > >
> > > > Sounds great..
> > >
> > > > We should probably have a doc catagory too.
> > > > Containing design/system spec. and things like that...
> > >
> > > > Its easy too become lazy and skip it but those things are
> > invalueable
> > > > for other developers when trying to start their own
> > development inside
> > > > the project..
> > > > Dont know how google group works, is it possible to make the
> > docs a
> > > > separate "product" or should we put it in the same SVN
> as source?
> > >
> > > > I would gladly sit down and write a system spec. for it, but
> > > > unfortunatly I will be very busy the next couple of weeks..
> > > > I have major releases to do at work, and a thesis to finish
> > all in the
> > > > end of may.. So its gonna be a busy month.. =)
> > >
> > > > regards
> > >
> > > > /Jesper
> > >
> > > > On Apr 23, 1:10 pm, "Jonas Finnemann Jensen"
> <jop...@gmail.com <mailto:jop...@gmail.com>

> > <mailto:jonathan.web...@gmail.com

> <mailto:jonathan.web...@gmail.com>>> wrote:
> > >
> > > > > > Glad to hear that!!
> > >
> > > > > > I have a functional port of uip1.0, running into an
> > ATmega32 with
> > > > > > ENC28J60, also a mmc/sd with fat support from Jesper.
> > > > > > It's working fine for me, I did a few changes, but maybe
> > we can work
> > > > > > over this? just let me know and I will sent them to
> you...
> > >
> > > > > > It's fine for me the change on the google code, also I
> > dont know it
> > > > > > very well, I think that all should be "Owners" of the
> > group? I dont
> > > > > > know, just do what you think is the best.
> > >
> > > > > > Regards,
> > >
> > > > > > Jonathan
> > >
> > > > > > On Apr 22, 7:56 am, "Jop... (Jonas F. Jensen)."
> > <jop...@gmail.com <mailto:jop...@gmail.com>

> <mailto:jop...@gmail.com <mailto:jop...@gmail.com>>>

[Jonas Finnemann Jensen]

Okay... I take a look at it tonight... I have made port of uip 1.0 I'll merge any interessting bits from this into it... clean it up and commit... so that we can get started, then we may decide to reinvent the wheel ten times later... :)

--
Regards Jonas Finnemann Jensen.

[Jonathan / WebCom-Design]

hahahaha excellent! we should stablish a base version and then start
working over there. also say which part who will do...
I think that before doing nothing, and if we will use that zip i sent,
we need to prepare the structure.

talk later!

--
Jonathan Granade
WebCom-Design

> <mailto:jonatha...@gmail.com

[Jonas Finnemann Jensen]

I think that before doing nothing, and if we will use that zip i sent,
we need to prepare the structure.

I won't... I'll start with a clean copy of uip 1.0, that'll provide most of the structure...

--
Regards Jonas Finnemann Jensen.