Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Open Source uIP porting project


  • Please log in to reply
42 replies to this topic

#21 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 16 June 2011 - 10:30 PM

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 ?

Since any decision is better than no decision, I suggest you start off with "Architecture specific functions", then continue with these:

Memory block management functions
Clock interface
Timer library
Protosockets library

I'm truly sorry for the delayed response and I hope this won't stop you from contributing to this project. Once the stack is up and running there's really no limits as of what we can do with the mini. I'm truly grateful for any and all contributions!

EDIT: Just realized Szymon had already answered this question.

NOTE: A brand new wireless mini keyboard with trackball is still waiting for it's owner:
Posted Image

#22 Codeblack

Codeblack

    Member

  • Members
  • PipPip
  • 10 posts

Posted 14 July 2011 - 12:27 PM

Excellent initiative! I'm in need of IPv6 & 6LoWPAN implementations.

I received my NetDuino Plus yesterday, after it spending almost a week at Dutch customs :wacko:. I spent last night soldering 2 shields (Moto & BreadBoard) and expect to spend the next few days trying out my first NETMF code and playing with several hardware pieces.

I have many projects in my mind, but the main one has to be home automation. I want to use 6LoWPAN for most devices and WiFi for high bandwidth stuff like audio. For most of the 6LoWPAN devices, I might just use an ATmega128RFA1. But for the ease of development I could also do NETMF with a 802.15.4 radio-chip. Still not sure, my mind toggles almost every minute... :unsure:. For connecting the 6LoWPAN world to the full IP world and for the WiFi/LAN devices I'll definitely use NETMF/NetDuino. To get familiair with the 802.15.4 MCU/radio chips I've ordered an AVR RZ RAVEN dev-kit, with an extra RZ RAVEN USB stick to be used as a 802.15.4 sniffer. All that's needed now is a 802.15.4-shield :D.

I'm not yet sure what to do on top of 6LowPAN. I've heard ZigBee is being adopted to use 6LowPAN. There is also a specification for using REST with 6LoWPAN (CoAP: Constrained Application Protocol), which maybe interesting together with a UPnP-like protocol. I do know that I want all my devices to talk IP and that I want 6LoWPAN on my power/resource constrained devices.

I have no experience with NETMF yet, but I do have over 10 years .NET/C# experience. And many years of C/C++ and assembler before that. I have 2 JeeNodes with some plugs, but I find the development experience with Arduino somewhat dissapointing.

I would very much like to contribute to the uIP port for .NET, if I may. Although I do need to quickly get familiair with NETMF and NetDuino first B).

#23 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 15 July 2011 - 08:09 AM

Excellent initiative! I'm in need of IPv6 & 6LoWPAN implementations.

Thanks, we still need more active contributors though.

I have many projects in my mind, but the main one has to be home automation. I want to use 6LoWPAN for most devices and WiFi for high bandwidth stuff like audio.

Cool stuff that is, I'm also kind of into home automation. Currently I control most of my A/V-equipment (i.e. stereo, tv, etc), selected lighting fixtures and my pool from an iPod touch. Also I'm developing what could easily become a UPnP music renderer.

I'm not yet sure what to do on top of 6LowPAN. I've heard ZigBee is being adopted to use 6LowPAN. There is also a specification for using REST with 6LoWPAN (CoAP: Constrained Application Protocol), which maybe interesting together with a UPnP-like protocol. I do know that I want all my devices to talk IP and that I want 6LoWPAN on my power/resource constrained devices.

Way to go, let everything talk IP!

I have no experience with NETMF yet, but I do have over 10 years .NET/C# experience. And many years of C/C++ and assembler before that. I have 2 JeeNodes with some plugs, but I find the development experience with Arduino somewhat dissapointing.

By the sound of it, you'll do more then well!

I would very much like to contribute to the uIP port for .NET, if I may. Although I do need to quickly get familiair with NETMF and NetDuino first B).

You are ever so welcome in contributing and please be sure to do so whenever your're ready!

#24 Codeblack

Codeblack

    Member

  • Members
  • PipPip
  • 10 posts

Posted 08 August 2011 - 04:52 AM

Hi guys,

Just a quick post to let you know I'm almost ready to start porting. The only thing between me and NetduIP is a 2 week vacation.

I'm done 'playing' with the Netduino :P and got familiair again with basic electronics, PWM, ADC, steppermotors, LCD's and so on. I wrote some posts about it on my blog. There are a few posts left to write during my vacation. Which I'll need to publish afterwards, as my laptop is staying at home on my wife's orders :(.

So, who is or will be contributing to this project as well? And who is volunteering for testing? I don't think I can, or should, take this on alone. I need some people to brainstorm and think together with about how we pull this off. E.g. how close do we stay to the original uIP? It's written in C, we're working in OO, and as Szymon already mentioned, we should leverage what's in NETMF already. And what's the best way to incorporate it into the NETMF/Netduino firmware? How do we support different hardware/shields and make others able to support more? These are just a few questions that came up and that I would really like to talk about with a few people.

And talking about hardware. I have a Netduino Plus, so I'm mostly set for networking with that. But I don't mind ordering some more hardware to be able to test NetduIP on a few other configurations. Like a 'regular' Netduino and the Mini with some of the available shields. So can you guys tell me what hardware you are using? That way I can decide on what to order. Thanks.

#25 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 20 December 2011 - 02:56 PM

Hmm...It appears as if the uIP source is no longer available for download. Adam Dunkels seems to be only interested in his Contiki OS since all the old links to a website only covering that. I can't find it on my computer - anyone who downloaded uIP while it was still there?

#26 mikepo

mikepo

    Member

  • Members
  • PipPip
  • 29 posts

Posted 27 December 2011 - 04:51 PM

Hmm...It appears as if the uIP source is no longer available for download. Adam Dunkels seems to be only interested in his Contiki OS since all the old links to a website only covering that.

I can't find it on my computer - anyone who downloaded uIP while it was still there?



Does this help: http://www.sics.se/~...=uip-1.0.tar.gz

I used Google's "cached" version of the web page to get to the links.

Also, the link to the PDF documentation.

HTH,
Mike

#27 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 28 December 2011 - 12:28 AM

Very much so, it never occurred to me. Thanks!

#28 Codeblack

Codeblack

    Member

  • Members
  • PipPip
  • 10 posts

Posted 30 December 2011 - 08:53 AM

That is a good find. I couldn't find it either, so I've been looking at the uIP TCP/IP stack that's part of Contiki. The separate uIP stack seems outdated to me, and doesn't support IP6 and 6LoWPAN (which are really important to me). Documentation of uIP as part of Contiki can be found here: http://www.sics.se/~...v6/a01101.html. There's also IP6 and 6LoWPAN specific information there. @hanzibal: I've been looking at the porting kit as the way to incorporate the uIP stack in NETMF. Is this the direction you were thinking of? I'm still having some trouble compiling the NETMF for the Netduino. Does anyone here have experience with that?

#29 Jay Sheldon

Jay Sheldon

    Member

  • Members
  • PipPip
  • 10 posts

Posted 25 January 2012 - 05:55 AM

I'm interested in this project. How do I get involved?

#30 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 02 March 2012 - 09:28 PM

Sorry everyone for taking this long to answer to this thread.

As I took the Initiative to this, I was very enthusiastic about it but I was at the same time quite clear about that I wasn't going to be contributing all that much myself. I guess I was hoping that others would take it all on in a much greater sense than seems to be the case.

I'm very much in favor of the mini for it's form factor and I personally like to see more of it in various projects - especially since it provides more than the other boards in terms of both PCB space and memory head room. Therefore I'd also really love to see a uIP implementation for it (and the other boards too).

However, when looking at things in a retrospective I realize that general community interest has turned out to be somewhat scarce. This especially given that chips like Wiznet and others have grown in popularity and use, much due to the fact that they offer an advantage in speed and simplicity of use and interconnection.

Of the said reasons, I would still very much like to see this through, but I'm now inviting for someone else to take more of a lead role.

@hanzibal: I've been looking at the porting kit as the way to incorporate the uIP stack in NETMF. Is this the direction you were thinking of?

Admittedly, I never really put that much thought into just that part of it all, but now that you mentioned it, I think that would be the way to go. Exactly how to integrate uIP into the inner workings of NETMF are for others, more inclined, to answer.

I'm interested in this project. How do I get involved?

Easy, simply sign up for contribution on Codeplex, the wireless keyboard is still yours for the takingPosted Image

#31 Codeblack

Codeblack

    Member

  • Members
  • PipPip
  • 10 posts

Posted 09 March 2012 - 01:08 PM

I'm also still very interested in this project. IPv6 & 6LoWPAN is still the way to go for me. But although NETMF is a logical choice for me, I'm also looking (or at least peeking) at other platforms that have an IPv6 stack already (e.g. those with a working Contiki port). If I choose to stay with NETMF, getting uIP ported is essential. I've had a look at the inner workings of the NETMF Porting Kit a little while ago, but I haven't yet succeeded to build the Netduino solution without errors. And with lots of other things to do, this kind of moved to the background. Meanwhile, hoping this porting project would get started and I could contribute a little along the way :P. In theory I should be able to get my head around it all and get this porting project started. I have plenty of experience with microcontrollers, assembler, C, etc. and I really like the challenge :D. I will have another look at the Porting Kit and uIP.

#32 LibraMan33

LibraMan33

    New Member

  • Members
  • Pip
  • 9 posts

Posted 22 March 2012 - 01:44 PM

Sorry everyone for taking this long to answer to this thread.

As I took the Initiative to this, I was very enthusiastic about it but I was at the same time quite clear about that I wasn't going to be contributing all that much myself. I guess I was hoping that others would take it all on in a much greater sense than seems to be the case.

I'm very much in favor of the mini for it's form factor and I personally like to see more of it in various projects - especially since it provides more than the other boards in terms of both PCB space and memory head room. Therefore I'd also really love to see a uIP implementation for it (and the other boards too).

However, when looking at things in a retrospective I realize that general community interest has turned out to be somewhat scarce. This especially given that chips like Wiznet and others have grown in popularity and use, much due to the fact that they offer an advantage in speed and simplicity of use and interconnection.

Of the said reasons, I would still very much like to see this through, but I'm now inviting for someone else to take more of a lead role.


Admittedly, I never really put that much thought into just that part of it all, but now that you mentioned it, I think that would be the way to go. Exactly how to integrate uIP into the inner workings of NETMF are for others, more inclined, to answer.


Easy, simply sign up for contribution on Codeplex, the wireless keyboard is still yours for the takingPosted Image




something that i would like to mention, really i need a tcp/ip stack and a enc28j60 driver for the netduino.
searching alot and try to do the porting from C++ to C# as u would like to do , or doing right now (too hard)
like to ask if it would be easir to implement the stack with a java code?!!!, i think porting java stack to c# stack would be easier ----> i attach the source code
good work and good luck
ahmed hussien ( http://www.facebook.com/LibertyMan33 )

#33 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 22 March 2012 - 03:00 PM

First of all, thank you for taking an interest in this project.

...if it would be easir to implement the stack with a java code?!!!...

Personally, I find it easier to port from C/C++ but that might be because I know both those languages better than Java.

Btw, not all of us have Facebook so please do upload files to the forum if they're not too big.

#34 LibraMan33

LibraMan33

    New Member

  • Members
  • Pip
  • 9 posts

Posted 22 March 2012 - 06:51 PM

First of all, thank you for taking an interest in this project.


Personally, I find it easier to port from C/C++ but that might be because I know both those languages better than Java.

Btw, not all of us have Facebook so please do upload files to the forum if they're not too big.


sorry now attached , its not mine IAttached File  jpcap-0.6.zip   1.35MB   5 downloads found the implementation in Java ---> no pointers or strange def. (that i mean by easy) and the transformation is straightforward

#35 LibraMan33

LibraMan33

    New Member

  • Members
  • Pip
  • 9 posts

Posted 22 March 2012 - 09:19 PM

also to be able to open java code u will need this program DJ Java Decompiler 3.12 sorry for late ahmed hussien

#36 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 22 March 2012 - 11:40 PM

After taking a look at the Java code it seems to make extensive use of calls into "navtive" C code (for which source code is also provided). Thus I think that going via Java is a large detour and that it would be much easier to simply stick to the plan and port directly from C. Out of sheer curiosity, may I ask why you have such a keen interest in TCP/IP stack based on the ENC28J60?

#37 LibraMan33

LibraMan33

    New Member

  • Members
  • Pip
  • 9 posts

Posted 23 March 2012 - 06:39 AM

After taking a look at the Java code it seems to make extensive use of calls into "navtive" C code (for which source code is also provided).

Thus I think that going via Java is a large detour and that it would be much easier to simply stick to the plan and port directly from C.

Out of sheer curiosity, may I ask why you have such a keen interest in TCP/IP stack based on the ENC28J60?


dear hanzibal

you are correct , thinking why there is no implementation for the stack in c# or even Java makes me nut, why? i don't understand that . is it impossible? but can't see a reason.


it is not a keen about this topic only, i love the world of embedded systems. its my hobby
also programming ,anyway yesterday i connect the tcp/ip sniffer based on your driver (enc28j60), and start to debug the ether frame. the first frame was 208 bytes and i didn't find this frame size as standard ----> actually i figure out that there is an 8 bytes on the start of the frame, do you know what is this

yours
ahmed

#38 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 23 March 2012 - 05:45 PM

Glad to hear you made use of my driver!

Below is an image describing the composition of an ethernet frame.

With my driver you don't see the preamable and delimiter so the first six bytes of a frame you see is the MAC address of the receiver (destination) and the next six bytes is the MAC address of the sender (source). These 12 bytes are then followed by a 2 byte type identifier, then comes the variable length payload (46 to 1500 bytes) and finally there is a 32 bit CRC number (4 bytes).

Posted Image

In conclusion, there's a 6 + 6 + 2 + 4 = 18 bytes overhead for a 46 - 1500 bytes payload. This means you could see frames with lengths ranging from 64 to a maximum of 1518 bytes.

A 208 byte frame should contain an 18 byte header and 190 bytes of data.

#39 LibraMan33

LibraMan33

    New Member

  • Members
  • Pip
  • 9 posts

Posted 24 March 2012 - 12:45 PM

Glad to hear you made use of my driver!

Below is an image describing the composition of an ethernet frame.

With my driver you don't see the preamable and delimiter so the first six bytes of a frame you see is the MAC address of the receiver (destination) and the next six bytes is the MAC address of the sender (source). These 12 bytes are then followed by a 2 byte type identifier, then comes the variable length payload (46 to 1500 bytes) and finally there is a 32 bit CRC number (4 bytes).

Posted Image

In conclusion, there's a 6 + 6 + 2 + 4 = 18 bytes overhead for a 46 - 1500 bytes payload. This means you could see frames with lengths ranging from 64 to a maximum of 1518 bytes.

A 208 byte frame should contain an 18 byte header and 190 bytes of data.


hi hanzibal

thanks for your reply, could you point me to a good reference on building the stack(book, url).
actually i can figure out where to start , building the stack will be a big process.

thanks alot for your help

bye

#40 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 24 March 2012 - 07:16 PM

Sorry, I don't have any information or link to a C# porting guide for uIP. I think this is mostly because there is none and that's exactly why I started this thread in the first place. However the original uIP C language source code is available from the project Codeplex site (see above).

As for me, I more or less did the driver porting blindly, i.e. I simply translated one syntax into another under the influence of some understanding as of the purpose and functionality of the code. Strangely enough, it all worked pretty much straight away Posted Image




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.