sde1000 / nanodeuip Goto Github PK
View Code? Open in Web Editor NEWPort of uIP library to Nanode
Home Page: http://wiki.hackspace.org.uk/wiki/Project:Nanode/UIP
Port of uIP library to Nanode
Home Page: http://wiki.hackspace.org.uk/wiki/Project:Nanode/UIP
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.
You might want to point out in the readme that DHCP can cause issues for a 450-byte packet size. The default DHCP Offer packet is 590 bytes. Some routers have a configuration to reduce it down to the ~300 necessary bytes, but others do not. (See http://www.linksysinfo.org/index.php?threads/dhcp-reduce-packet-size.20699/ for one example).
In fact, RFC2131 says, "A DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP datagram size an IP host must be prepared to accept [3]. " No help to those of us on MCU's!
From e7db1e7d356eaff1d6f8c53a6e017673bd55748c Mon Sep 17 00:00:00 2001
From: maniacbug
Date: Sun, 1 Jan 2012 21:50:05 -0800
Subject: [PATCH] Fixed a buffer overrun bug in enc28j60ReadBuffer. This
writes all over memory it doesn't own. Bad stuff.
---
enc28j60.cpp | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/enc28j60.cpp b/enc28j60.cpp
index 3d5630e..ee04647 100644
--- a/enc28j60.cpp
+++ b/enc28j60.cpp
@@ -86,7 +86,6 @@ void enc28j60ReadBuffer(uint16_t len, uint8_t* data)
*data++ = SPDR;
}
disableChip();
- *data='\0';
}
static word enc28j60ReadBufferWord() {
--
1.7.5.4
From 5f386f3 Mon Sep 17 00:00:00 2001
From: maniacbug [email protected]
Date: Sun, 8 Jan 2012 14:24:33 -0800
Subject: [PATCH] Packet slicer.
Allows processing of (and ignores checksums on) packets which are smaller than the packet header believes. This is very useful in highly-constrained memory environments. The most likely case of a sliced packet is the network later truncated it because the packet is larger than the UIP buffer.
uip.cpp | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/uip.cpp b/uip.cpp
index 8e577a9..5618d50 100644
--- a/uip.cpp
+++ b/uip.cpp
@@ -690,6 +690,8 @@ void
uip_process(u8_t flag)
{
register struct uip_conn *uip_connr = uip_conn;
if(flag == UIP_UDP_SEND_CONN) {
@@ -876,7 +878,8 @@ uip_process(u8_t flag)
} else {
UIP_LOG("ip: packet shorter than reported in IP header.");
@@ -950,7 +953,10 @@ uip_process(u8_t flag)
UIP_STAT(++uip_stat.ip.drop);
UIP_STAT(++uip_stat.ip.chkerr);
UIP_LOG("ip: bad checksum.");
UIP_LOG("Ignoring because packet was sliced.");
goto drop;
@@ -1100,7 +1106,10 @@ uip_process(u8_t flag)
UIP_STAT(++uip_stat.udp.drop);
UIP_STAT(++uip_stat.udp.chkerr);
UIP_LOG("udp: bad checksum.");
UIP_LOG("Ignoring because packet was sliced.");
goto drop;
Hi guys,
I am developpin' on an arduino UNO board rev 3 and I have plugged into it a ENC28J60-H ethernet shield.
I'm using the NanodeUIP,NanodeUNIO librairies for my application and I don't know how to get an IP address usin' DHCP. I've also tried the uiptest example but it doesn't work at all.
Maybe I'm just an ignorant newbie in the Arduino World but I definitively don't know how to make it works.
Please I need some help.
Cheers
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.