42 replies to this topic

[hanzibal]

Much respected fellow forum members, collegues and friends!

I'm happy to announce that forum member Szymon and I are starting up an open source porting project for porting the uIP TCP/IP stack of Adam Dunkels into NETMF and C# for Netduino - the sounds of much rejoicement and cheerful approval could be heard from the audience...

The initial implementation will be one of IPv4 but may be followed by an IPv6 or even a dual stack implementation. This thread is intended to be a companion to the project for discussing various issues along the path. Szymon has been kind enough to take on the responsibility of managing the project which is soon to be setup at CodePlex for release under an Apache V2 license. While as I will only play a minor role.

Due to a license switch (and somewhat mixed license situation) we are currently awaiting permission from Adam Dunkels to go along with the porting for the Appache license. I have contacted mr Dunkels and expect to receive such permission within days.

A small contribution in the form of porting a driver for the popular ENC28J60 ethernet controller chip from Microchip has already been made by yours truly who hopes to follow up by also porting a driver for the equally popular MRF24WB0MB wifi chip from the same vendor.

As soon as the project is created, up and running, you are all more than welcome and strongly encouraged to contribute to the work of porting the stack, so you may aswell already fire up those code blazing, bit mangling and binary oozing engines for brains of yours into thinking uIP for NETMF and Netduino

Or, to use a quote from a favourite old movie, which I think pretty much says it all:

It's 106 miles to Chicago, we got a full tank of gas, half a pack of cigarettes, it's dark... and we're wearing sunglasses

Hit it!

Meanwhile, maybe we could get started by discussing best practice for incorporating the upcoming stack into the existing networking bits and parts of NETMF. Anyone?

[Stefan]

I would love to think up loud and test stuff when there's something read (I got the ENC28J60 myself). For development I have little time near my own projects, and I still lack knowledge on many grounds so there I can't help you out. For a network stack, what I would love to see is a very simple implementation of socket listeners and outgoing sockets. When that's done I could write all kinds of daemons and networking clients in C#. I just clicked the subscribe-button of this topic so I can follow the process closely

[Szymon]

I would love to think up loud and test stuff when there's something read (I got the ENC28J60 myself). For development I have little time near my own projects, and I still lack knowledge on many grounds so there I can't help you out.

For a network stack, what I would love to see is a very simple implementation of socket listeners and outgoing sockets. When that's done I could write all kinds of daemons and networking clients in C#.

I just clicked the subscribe-button of this topic so I can follow the process closely

Hi Stefan,
Thanks for your feedback. Could you elaborate about "very simple implementation of socket listeners and outgoing sockets"? What would you like this APIs to look like? Should we make it close as possible to existing .NET Socket class or we should take different approach.
http://msdn.microsof...ets.socket.aspx

Any scenario in particular that you think we should address?

Best,
-Szymon

[Stefan]

Hi Stefan,
Thanks for your feedback. Could you elaborate about "very simple implementation of socket listeners and outgoing sockets"? What would you like this APIs to look like? Should we make it close as possible to existing .NET Socket class or we should take different approach.
http://msdn.microsof...ets.socket.aspx

Any scenario in particular that you think we should address?

That's a difficult one. When taking the same approach as the .NET Socket class it would be very easy to use for many people and you can point to the MSDN documentation (that's why I chose to copy existing port classes in this project).

But for sockets, and to make it MicroIP (the U stands for µ which stands for Micro, right?) it probably should be less advanced (read; less complicated).

When I look at the list of methods and properties of the built-in socket class, I don't think the µIP project should require them all. I would try to use the names of existing method though, so iy would be more easy to understand for the developer.

[hanzibal]

I dont quite follow, the stack wont use sockets, rather sockets will use the stack (which, in it's turn will use one of several possible ethernet drivers). Am I right or am I missing something here?

[Stefan]

I dont quite follow, the stack wont use sockets, rather sockets will use the stack (which, in it's turn will use one of several possible ethernet drivers). Am I right or am I missing something here?

You are right, that sockets use the stack, but a microversion of a socket class would save some amount of memory and could make things much more easy to do as well. Just a thought

[hanzibal]

Bad news: Adam Dunkels seem unreachable, we must hope he's ok though :-) Good news: While examining the licence of the actual uIP code base, Szymon discovered that current license does not seem to present any obstacles for releasing our upcoming Net MF port under an Apache V2 licence. If really so, we don't need mr Dunkels permission simply because we already have it as per se. This means we're likely good to go and just waiting for Szymon to report back after having created the project @ CodePlex.

[StanDeMan]

Bad news: Adam Dunkels seem unreachable, we must hope he's ok though :-)

Good news: While examining the licence of the actual uIP code base, Szymon discovered that current license does not seem to present any obstacles for releasing our upcoming Net MF port under an Apache V2 licence. If really so, we don't need mr Dunkels permission simply because we already have it as per se.

This means we're likely good to go and just waiting for Szymon to report back after having created the project @ CodePlex.

Hi hanzibal,
Any news about this?
Regards and thanks
Stanislaus

[hanzibal]

Hello, sorry about the latency here but I've been terribly busy elsewhere. Yes, there are some news in that our good friend Szymon has created a project @ CodePlex but as Szymon is also very busy and far too often summoned upon a man, the project has not quite yet reached the published state. However, I expect this event to occur any time soon (provided time is actually as linear as I wish for it to be). I hope to bring more news of this matter shortly.

[hanzibal]

Lo and behold, the open source project of porting uIp to Microsoft .Net Micro Framework and Netduino has become a reality: http://netduip.codeplex.com/ This is true mostly due to the efforts of forum member Szymon. Our wish is now for any and all, who's up for it, to, in hounor and tribute of good spirit (not hard liqueor), best of intentions, freedom of thought, hard work, love of mankind, fear of god and the liking of really funny and generally nice things (such as pop corn, soda, candy floss, mints or any type of sweet for that matter), to start CONTRIBUTING! First runner up get to win a wireless USB keyboard (really nice, yes indeed). Winner will be announced on the project web site no less than one month from now. So once again, please go to this site and sign up for contribution: http://netduip.codeplex.com/ A toast, if I may! Btw, the keyboard is really nice too.

[Michel Trahan]

3 Cheers for Szymon and Hanzibal I'm too much of a newbie to even think of trying ... (and too lazy Stefan would add LOL)

[hanzibal]

Thanks Michael, but lazy I wouldn't know, however I think not since you took the time and effort of writing a post just now and you're the first to do so, rendering everyone else more lazy than you, thus making you the least lazy person in the wotld. As for the newbe stuff, it's totally irrelevant, if you can code, join! Heck, I'm a newby myself and obviously you can code. Got any legitimate reasons for not joining? :-) There's a wireless keyboard just sitting there waiting for it's new owner...

[Stefan]

I'm too much of a newbie to even think of trying ... (and too lazy Stefan would add LOL)

That was a comment when you said: "I'll just let you figure it out so I can download the code"

[Michel Trahan]

That was a comment when you said: "I'll just let you figure it out so I can download the code"

I know, I was having mileage on it lol I have a good work load and still manage to play with the netduino I see myself more as an integrator anyway

And the main reason hanzibal would probably the lack of a netduino plus or an ethernet shield for my netduino ! I can look at the code that exist that we need to translate ... ok I'll check the link, you got me convinced but keep the keyboard for someone who wants it

[hanzibal]

I know, I was having mileage on it lol I have a good work load and still manage to play with the netduino I see myself more as an integrator anyway

And the main reason hanzibal would probably the lack of a netduino plus or an ethernet shield for my netduino ! I can look at the code that exist that we need to translate ... ok I'll check the link, you got me convinced but keep the keyboard for someone who wants it

You guys are not nearly as stupid as you do not look

About the keyboard Micheal: You do wan't the keyboard, you're simply not fully aware of it yet

The Netduino Plus is truly some piece of hardware but in comparison to the mini, it's an elephant and sometimes size actually matters - I guess you already knew that too.

[Michel Trahan]

Here is a list of all modules: Protothreads Local continuations Applications DNS resolver SMTP E-mail sender Hello, world Web client Web server The uIP TCP/IP stack uIP configuration functions uIP initialization functions uIP device driver functions uIP application functions uIP conversion functions Variables used in uIP device drivers uIP Address Resolution Protocol uIP TCP throughput booster hack Architecture specific uIP functions Configuration options for uIP Timer library Clock interface Protosockets library Memory block management functions What do we attack first ?

[Szymon]

Hi all, I think we should start from the bottom and get the basic uIP stack modules running first. Applications can come later as I'm sure they will be useful for testing and as learning examples. But first we should look if any of the bottom level modules have any corresponding functions builtin in the .NET MF already. For example the "Memory block management functions" or "Timer library" I think would find replacements.

[Szymon]

Please let me know who want's to joint the project. Just send me your CodePlex account name so I can add you to project members.

[Michel Trahan]

What can I do ? Already following (Zoner42) and looking at the docs ... need directives please

[hanzibal]

Practically anything if you put your mind to it :-) Seriously though, I think that's a question for Szymon to answer and I guess, in time, he will :-) Speaking of time, the current is wrong of year for coding but we can always hope for a rainy day. Oh Szymon, where art thou?

Edited by hanzibal, 06 June 2011 - 10:39 PM.