Skip to content
C C++ Java Perl
Latest commit 4edeeb5 Feb 21, 2012 @njh njh Converted old uIP types to standard C99 data types.
u8_t   changed to  uint8_t
u16_t  changed to  uint16_t
Failed to load latest commit information.
examples Imported changes from Contiki that makes more extensive use of the ui… Jan 14, 2012
uip Moved old uIP docs out of the way. Jan 9, 2012
.gitignore Add .gitignore, don't cast in such an ugly manner in NanodeMAC! Aug 1, 2011
NanodeUIP.cpp Include <avr/pgmspace.h> for arduino 0022 compatibility Jan 14, 2012
NanodeUIP.h Imported changes from Contiki that makes more extensive use of the ui… Jan 14, 2012
README Remove MAC chip reading code; add example sketch Sep 14, 2011
TODO Oops - remove reference to hello-world.h from NanodeUIP.cpp Sep 21, 2011
clock-arch.h DHCP support Aug 2, 2011
clock.h Minor changes imported from the latest version of Contiki. Jan 9, 2012
dhcpc.cpp Converted old uIP types to standard C99 data types. Feb 21, 2012
dhcpc.h Converted old uIP types to standard C99 data types. Feb 21, 2012
enc28j60.cpp Fix buffer overrun in enc28j60ReadBuffer() Jan 2, 2012
enc28j60.h Use Arduino-defined constants for SPI control lines. More portable. Jan 18, 2012
lc-addrlabels.h Minor changes imported from the latest version of Contiki. Jan 9, 2012
lc-switch.h Minor changes imported from the latest version of Contiki. Jan 9, 2012
lc.h Minor changes imported from the latest version of Contiki. Jan 9, 2012
platform.cpp Added definition for clock_init() Jan 8, 2012
psock.cpp Converted old uIP types to standard C99 data types. Feb 21, 2012
psock.h Converted old uIP types to standard C99 data types. Feb 21, 2012
pt.h Minor updates to pt.h from the latest version of Contiki. Jan 8, 2012
resolv.cpp Converted old uIP types to standard C99 data types. Feb 21, 2012
resolv.h Imported minor changes to the DNS resolver from the latest version of… Jan 14, 2012
timer.cpp Merged in the latest version of timer functions from the Contiki GIT … Jan 8, 2012
timer.h Merged in the latest version of timer functions from the Contiki GIT … Jan 8, 2012
uip-conf.h Converted old uIP types to standard C99 data types. Feb 21, 2012
uip.cpp Converted old uIP types to standard C99 data types. Feb 21, 2012
uip.h Converted old uIP types to standard C99 data types. Feb 21, 2012
uip_arch.h Converted old uIP types to standard C99 data types. Feb 21, 2012
uip_arp.cpp Converted old uIP types to standard C99 data types. Feb 21, 2012
uip_arp.h Converted old uIP types to standard C99 data types. Feb 21, 2012
uipopt.h Converted old uIP types to standard C99 data types. Feb 21, 2012

README

This is a port of the uIP network stack from SICS to the Nanode.  It
presents itself as an Arduino library.

There's an example sketch, "uiptest", which you can access from the
Arduino IDE.  Chose File -> Examples -> NanodeUIP -> uiptest to access
it.  Note that it depends on the NanodeUNIO library (available at
https://github.com/sde1000/NanodeUNIO) being installed to access the
MAC address chip on the back of the Nanode.


Notes on porting decisions:

clock_time_t has to be unsigned long (4 bytes) if we're going to use
the output of millis() as the clock.  This overflows every 50 days -
acceptable.

If we only used an unsigned int (2 bytes) the time would overflow
every 65s and half of this would be the maximum wait possible - some
protocols demand more.  The DHCP client would enter an infinite loop
when its retransmission time grew beyond 32s.

We might get away with using millis()/10 as the clock if we define
clock_time_t to be unsigned int.  It would overflow every 10 minutes
or so, allowing for a maximum wait of 5 minutes.


RAM is very valuable.  The packet buffer takes up most of it (and
applications should construct their data to send directly within this
buffer when possible).  Constant strings in the user's program also
take up RAM; if your "Serial.println" is just outputting a newline,
when you expect it to do something else, your program has probably
outgrown the 2k RAM.  If you can find the build directory, you can run
avr-objdump -h on the .elf file and add up the sizes of the .data and
.bss sections - if this is approaching 2k you're in trouble.

How are we going to manage memory allocation for connection state?
The size is application-dependent, and I think most people are going
to want at least two applications running at once (even if one of them
is just the DHCP client).

uIP as distributed assumes that there's going to be a single TCP
application and a single UDP application.  State for each connection
to these applications is allocated at compile time as a member of the
uIP connection structure.

How much space is an application going to need, per connection?

TCP applications:
(Note: struct psock is 20 bytes)
hello-world: 70 bytes
webclient: 359 bytes
webserver: 128 bytes
telnetd: 75 bytes
smtp: 17 bytes (but implementation looks buggy!)

UDP applications:
resolv: 2 bytes per-connection, plus 41 bytes per cache entry (default 4)
dhcpc: 43 bytes (possibly reducible to 41 bytes)

(On further reflection, per-connection state for UDP is really
pointless.  I expect apps using UDP will have a single copy of their
state allocated in .data and .bss - we just need to store their
appcall function pointer in uIP's UDP connection structure so we can
demultiplex based on destination port number.)

With no applications beyond the DHCP client, uIP currently takes about
1k of RAM.  That leaves 1k for all the application state, the heap and
the stack.  I think it's reasonable to be able to serve three TCP
connections at once by default; if we allow 150 bytes state per
connection that leaves at least 512 bytes for heap and stack.

To allow for multiple applications we need to store a function pointer
per connection so the uIP code can call the appropriate handler.  I
propose to insert this into struct uip_conn and define the
UIP_APPCALL() macro to indirect through it.

How does this function pointer get into the uip_conn structure?  We
need to modify the code that opens a connection to put it there.
Store the pointer for each listening port, and insert it into the
newly-formed connection.
Something went wrong with that request. Please try again.