Lpc2000

Ok so I ported uIP to IAR on LPC2148, and am talking to XP via SLIP.  I now
need to implement PPP.

The closest I've seen that might be suitable is the PPP implementation in
the ethernut code collection:  http://www.ethernut.de/en/download/index.html

Has anyone seen a more suitable PPP implementation for uIP?

Thanks,
Joel

Joel Winarske wrote:
> Ok so I ported uIP to IAR on LPC2148, and am talking to XP via SLIP.  I now
> need to implement PPP.
> 
> The closest I've seen that might be suitable is the PPP implementation in
> the ethernut code collection:  http://www.ethernut.de/en/download/index.html
> 
> Has anyone seen a more suitable PPP implementation for uIP?

Hey Joel,

Cool! If its no problem, could you post a summary of what you needed
to do to get SLIP running between your LPC board and Windows XP.
Did you need to add code to LwIP to support SLIP, or was
it in there already?

I've been looking at the Linux side of things for PLIP and SLIP,
and haven't played with the LPC-side yet. Here's my documentation
on SLIP and PLIP from Linux

http://www.ovro.caltech.edu/~dwh/drivers.pdf

I've downloaded the CVS LwIP and contrib directory, but haven't had
a chance to read through it yet. Is there a good design document
giving details on LwIPs implementation? Like I said, I haven't looked
through the source in detail, so there might be something in there,
but any comments would be appreciated.

As for PPP source, in Linux SLIP is a line discipline inside
the tty layer, and so is PPP. If you can't find something that
already bolts into LwIP, that might be a good place to look.

Cheers
Dave

Hi David,

> Cool! If its no problem, could you post a summary of what you needed
> to do to get SLIP running between your LPC board and Windows XP.
> Did you need to add code to LwIP to support SLIP, or was
> it in there already?

uIP side tweaks:
1. Tweak slipdev_char_poll() and slipdev_char_put() for target
2. The next code line after while(1) in main.c has a typo, should be 
"uip_len = slipdev_poll();"
3. Implement Windows connect handshake "CLIENT"/"CLIENTSERVER" in
slipdev_poll()
4. Comment out the Ethernet header struct, as SLIP does not implement this.
5. Remove all references to ARP since you don't need this with SLIP.
6. In uipopt.h change #define UIP_LLH_LEN from 14 to 0.
7. Change IP address to suite your network.

There is basic info on porting the stack on the uIP website.

For XP connectivity I used this app note:
http://www.pumpkininc.com/content/doc/appnote/an-32.pdf


> I've been looking at the Linux side of things for PLIP and SLIP,
> and haven't played with the LPC-side yet. Here's my documentation
> on SLIP and PLIP from Linux
> 
> http://www.ovro.caltech.edu/~dwh/drivers.pdf

This will be useful for testing with Linux!

> I've downloaded the CVS LwIP and contrib directory, but haven't had
> a chance to read through it yet. Is there a good design document
> giving details on LwIPs implementation? Like I said, I haven't looked
> through the source in detail, so there might be something in there,
> but any comments would be appreciated.

I started on porting lwIP to IAR/ARM, but switched to uIP as it was much
quicker.  lwIP requires a bit more time to correctly port.  There is a
reasonably active lwIP mailing list.  AFAIK there is not an official mailing
list for uIP.

> As for PPP source, in Linux SLIP is a line discipline inside
> the tty layer, and so is PPP. If you can't find something that
> already bolts into LwIP, that might be a good place to look.

lwIP includes PPP support.  \lwip-1.1.0\src\netif\ppp
Ethernut's PPP implementation looks attractive from a size stand point.


Regards,
Joel

Hi Joel,

Thanks for the feedback. I need to download uIP too and take a
look at that. Both were written by Adam Dunkles.

http://www.sics.se/~adam/uip/
http://www.sics.se/~adam/lwip/

I believe the uIP project is the one that is actively being
developed. I had planned to look at LwIP first, as I think
thats what was running on the Olimex demo ported by Crossworks.
I also have an Altera NIOS II development kit that appears
to have a uCOS-II+LwIP demo.

Whats your feeling on the two projects ... take a look at the
LwIP examples, by actually do any new work with uIP?

Cheers
Dave

> uIP side tweaks:
> 1. Tweak slipdev_char_poll() and slipdev_char_put() for target
> 2. The next code line after while(1) in main.c has a typo, should be
> "uip_len = slipdev_poll();"
> 3. Implement Windows connect handshake "CLIENT"/"CLIENTSERVER" in
> slipdev_poll()
> 4. Comment out the Ethernet header struct, as SLIP does not implement
this.
> 5. Remove all references to ARP since you don't need this with SLIP.
> 6. In uipopt.h change #define UIP_LLH_LEN from 14 to 0.
> 7. Change IP address to suite your network.

I forgot to mention IAR needed some tweaks in fsdata.c and there was also
some alignment packing required.

The lwIP PPP code looks to be much cleaner, and perhaps a better port than
the Ethernut implementation.  It appears the lwIP PPP implementation was
pulled from uC/OS-Net.  http://ucip.sourceforge.net/


Joel

> I believe the uIP project is the one that is actively being
> developed. I had planned to look at LwIP first, as I think
> thats what was running on the Olimex demo ported by Crossworks.

The Crossworks port is of uIP, as is the FreeRTOS port.  Paul mentions a
0.9.1 version of uIP on his page:
http://www.crossstudio.co.uk/msp430/uip.htm
I sent Adam an email requesting it, perhaps I will get a response.

> I also have an Altera NIOS II development kit that appears
> to have a uCOS-II+LwIP demo.

The lwIP implementation in Altera's NIOS II environment is 0.7.2 I believe.
Perhaps they updated to 1.1 in the recent 5.0 release?

> 
> Whats your feeling on the two projects ... take a look at the
> LwIP examples, by actually do any new work with uIP?

My take is that uIP is best suited for a quiet collision domain, or perhaps
with hardware assist.  Altera had published a very interesting white paper
on offloading portions of the IP stack to hardware in the form of DMA
peripherals.

Working IAR build of uIP/SLIP:
12 312 bytes of CODE  memory 
 4 700 bytes of DATA  memory (+ 30 absolute ) 
 6 464 bytes of CONST memory

This might be interesting to compare against a lwIP/SLIP implementation.


Joel

Joel Winarske wrote:
>>I believe the uIP project is the one that is actively being
>>developed. I had planned to look at LwIP first, as I think
>>thats what was running on the Olimex demo ported by Crossworks.
> 
> 
> The Crossworks port is of uIP, as is the FreeRTOS port.  Paul mentions a
> 0.9.1 version of uIP on his page:
> http://www.crossstudio.co.uk/msp430/uip.htm
> I sent Adam an email requesting it, perhaps I will get a response.

Yep, you're right ... I should have just looked at the Olimex page :)

http://www.olimex.com/dev/lpc-e2129.html

>>I also have an Altera NIOS II development kit that appears
>>to have a uCOS-II+LwIP demo.
> 
> The lwIP implementation in Altera's NIOS II environment is 0.7.2 I believe.
> Perhaps they updated to 1.1 in the recent 5.0 release?

Yeah they did.

> My take is that uIP is best suited for a quiet collision domain, or perhaps
> with hardware assist.  Altera had published a very interesting white paper
> on offloading portions of the IP stack to hardware in the form of DMA
> peripherals.
> 
> Working IAR build of uIP/SLIP:
> 12 312 bytes of CODE  memory 
>  4 700 bytes of DATA  memory (+ 30 absolute ) 
>  6 464 bytes of CONST memory
> 
> This might be interesting to compare against a lwIP/SLIP implementation.

Sounds like a plan. Once I get the Linux drivers stuff finished
(I've got to look into the PCI side of network drivers), I'll
go back to the LPC and NIOS ends of things.

Cheers
Dave

Hi, 

> > I believe the uIP project is the one that is actively being
> > developed. I had planned to look at LwIP first, as I think
> > thats what was running on the Olimex demo ported by Crossworks.
> 
> The Crossworks port is of uIP, as is the FreeRTOS port.  Paul 
> mentions a
> 0.9.1 version of uIP on his page:
> http://www.crossstudio.co.uk/msp430/uip.htm
> I sent Adam an email requesting it, perhaps I will get a response.

Adam sent me something he called 0.9.1.  That's not an official release
of the uIP code, Adam has sent me a number of patches.  In fact, the
better base for this is probably Contiki.

> > Whats your feeling on the two projects ... take a look at the
> > LwIP examples, by actually do any new work with uIP?
> 
> My take is that uIP is best suited for a quiet collision 
> domain, or perhaps with hardware assist.  Altera had published
> a very interesting white paper on offloading portions of the IP
? stack to hardware in the form of DMA peripherals.

I think uIP is easier to port but harder to write applications for.  uIP
can only have a single segment in flight at any moment, so there is no
windowing.  However, uIP's requirements are absolutely minimal and it
conforms to RFC standards.  It has packet reassembly too, which is an
optional compile-in.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

> Adam sent me something he called 0.9.1.  That's not an official release
> of the uIP code, Adam has sent me a number of patches.  In fact, the
> better base for this is probably Contiki.

Thanks for mentioning this.  Contiki has a PPP implementation.


Joel

Joel Winarske wrote:

> > Adam sent me something he called 0.9.1.  That's not an official release
> > of the uIP code, Adam has sent me a number of patches.  In fact, the
> > better base for this is probably Contiki.
>
> Thanks for mentioning this.  Contiki has a PPP implementation.
>
>
> Joel
>
Joel,

IIRC Ethernut (http://www.ethernut.de/)  also got one.

/Ake

>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>


-- 
 ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org



[Non-text portions of this message have been removed]

> Ok so I ported uIP to IAR on LPC2148, and am talking to XP via SLIP.  I
> now need to implement PPP.
> 
> The closest I've seen that might be suitable is the PPP implementation in
> the ethernut code collection:
> http://www.ethernut.de/en/download/index.html
> 
> Has anyone seen a more suitable PPP implementation for uIP?

Follow-up:

I ended up working with the PPP stack from Contiki.  It's a stripped down
version of the lwIP version.  It was an ok start.  After spending some hours
debugging the state machine and becoming familiar with the RFC, I concluded
there was a better approach.  I ended up implementing the RFC's "Automaton"
with IAR's visualState (free demo version).  The end result is an RFC
compliant state machine verified, and tested in less than three hours.  This
software is very effective.


Joel