Go Down

Topic: Socket API for enc28j60 (Read 4772 times) previous topic - next topic


hello guys,
I'm trying to add a client class to the EtherCard library from Jean-Claude Wippler
as same as the Ethernet library for WIZnet W51000(arduino Ethernet Shield).
And I noticed that in the Ethernet library there's a socket API and in Ethercard it  doesn't.
did anyone make that? Because I've tried to it same for the enc28j60 but I don't see the socket registers in the enc28j60 's datasheet unlike in the Ethernet's one.


I've written Client and Server-classes for enc28j60. It's not based on ethercard, but wraps Adam Dunkels uip-stack (which has the benefit that this comes with full tcp-support and other stuff)...

Other then ethercard it makes extensive use of enc28j60 internal 8K memory so it supports multiple concurrent connections with plenty of stream-buffer without running into memory-issues.

You find my code on github: https://github.com/ntruchsess/arduino_uip

btw: enc28j60 doesn't have socket-registers as wiznet 5100 as it supports ethernet/mac in hardware only, no higher level protocolls.


Hallo Norbert,

Great work you did on the UIPEther library! I even got it to work with the MQTT library at http://knolleary.net/arduino-client-for-mqtt/ which used to be not possible for enc28j60.

What I was wondering, is there a way to reduce the size? e.g. by excluding the dhcp / dns lookups etc as most of my sketches get a Sketch too big; see http://www.arduino.cc/en/Guide/Troubleshooting#size error. Even though the programs are rather small (collecting some sensor info).

Seems like the UIPEther adds quite a bit of size compared to the ethercard library and I was hoping excluding somehow some of the functions would reduce the consumption of program space


Oct 17, 2013, 07:54 pm Last Edit: Oct 17, 2013, 07:56 pm by ntruchsess Reason: 1
Yes, I know. The stack takes up quite a bit of flash memory because all the protocoll is done by the CPU as enc28j80 just handles the physical interface. The WIZ5100 on the original ethernet-shield does the protocol up to the socket-level on the chip requiring a much smaller amount of code.

you may remove UDP (and with that dhcp and dns as well) by setting UIP_CONF_UDP to 0 in uip-conf.h.
This saves aproximately 5kb of flash.
This has to be done on library-level (because of the way the ide compiles libraries..). Otherwise you would have to include the whole lib into the sketch.

The good new is that UIPEthernet doesn't eat up all ram, as it uses the enc28j60 internal memory for streaming.

- Norbert


Yes, indeed I found that solution already. It indeed helped to make the library much more useful as now I can at least have f few lines of code in there. I'm also seeing my sketch is more stable than with the ethercard library as somehow that seems to lock up quite regular if I don'use the stash cleaning hack.

Anyways, if you have flash memory saving ideas beyond excluding UDP/DHCP/DNS with the UIP_CONF_UDP.
e.g. I was thinking maybe UIPServer could be excluded if I only need to send data to a server (and get the reply), or is that also needed for the client ?



This optimization is done by the linker. If you don't reference UIPServer (EthernetServer) in the executinng code of your sketch, it's not copied to the arduino. The linker just copies the symbols (variables, functions and methods) that your sketch really depends on. It doesn't even copy private static initializing code if a class has only private constructors. You might have noticed the size-difference when using the Serial-object in comparism to not using it that shows up although the Serial-instance is declared implicitly. So there's no gain in using 'ifdefs' on methods you don't need besides some savings in compile-time.
the UIP_CONF_UDP define works, because the code left out is part of the gigantic uip_process-method that can be included by the linker as a whole - Adam Dunkels decided to optimize the code that no unavoidable function-calls are left using labels and gotos instead. While this might improve runtime-performance a bit it doesn't permit leaving out unused code at compiletime since all the code is reachable within the function (it depends on runtime-data whether it's being executed).

So one might leave out a bit of code in uip_process that is not mandatory to establish and maintain a tcp-connection (but you will loose all flexibility and maybe some reliability): there's the ICMP-stuff that is required for ping only (unfortunally no ifdef to leave that out easily, you'd have to modify uip.c). You might decide to use fixed (in the sense of defined as constant in the code) ip and ethernet-address (UIP_FIXEDADDR and UIP_FIXEDETHADDR, I havn't tested whether the UIPClient/Server code compiles or runs with that). Then you might leave out checksums (allways return 0 or 0xffff, you'd have to check which works) by replacing the checksum-code in UIPEthernet.cpp. And you might even use predefined const arp-tables and leave out most of the arp-code (also no existing ifdefs for that, you'd have to write alternative implementations for arp_in() and arp_out()).
If your sketch is a server you might set UIP_ACTIVE_OPEN to 0 which leaves out the code for outgoing connections from uip_process().

And finally you don't need the Server for a client-only sketch. Just declare an Instance of EthernetClient, run Ethernet.begin() and you are ready to execute client.connect().
See: https://github.com/ntruchsess/arduino_uip/blob/master/examples/TcpClient/TcpClient.ino
(repace Ethernet.begin(mac) wich Ethernet.begin(mac,ip) - otherwise it requires dhcp and thus udp...)

- Norbert


Oct 23, 2013, 12:56 am Last Edit: Oct 23, 2013, 02:30 pm by ntruchsess Reason: 1
ok, I could save aprox 500 Bytes of flash without loosing functionality by optimizing Enc28J60Network.cpp. I'd say that's a start, isn't it?
code changes are currently in branch 'dev'

- Norbert


Hallo Norbert,
Great work you did on the UIPEther library! I even got it to work with the MQTT library at http://knolleary.net/arduino-client-for-mqtt/ which used to be not possible for enc28j60.
There is much info on ENC28j60 MQTT - some old, some new some contradicting ... So far I was unable to make sense of it and get it working. Can you perhaps point me to some tried/tested solution - or maybe send me some examples?

- Vladimir

Go Up