[ell-i-developers] Re: Tentative plan for Arduino Ethernet library support
- From: Pekka Nikander <pekka.nikander@xxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Tue, 18 Feb 2014 10:48:36 +0200
> It looks as though there is some amount of ENC28J60 IP stack for Arduino
> already existing. The thread on Adafruit refers to a V6 implementation on
> Arduino. Have you taken a look? It is ported from Contiki, so it is already
> more or less familiar and you should be able to form an educated opinion on
> if it has any value for us. Basically it boils down to two questions:
>
> Is the Contiki IP api abstraction good for us?
IMHO it is not a good API. However, if we want to do it again quick and dirty,
then the stack you point out might be good.
Personally, I'm not interested in doing it again quick and dirty, that I've
done already. I am not happy with the Contiki code quality, it smells slightly
rotten. If someone else wants to do it again, stitching stack together from
our existing code and the Telecom Bretagne code, that is not a big deal -- I
can help. But I don't want to spend my time on *doing* it, as I will not learn
anything and I don't see how it would help us in the long term. On the other
hand, it is a perfect learning project for someone who want to learn how to do
software integration on a bare-metal system.
Sure, for doing such stitching you have to be fluent in C, have basic
understanding how our bare metal runtime works, but not much more than that. I
think there are a few qualifying people on this list. :-)
From my point of view, writing a simple UDP/IP stack is not a big deal, as it
is completely stateless. Hence, it is basically just sending and receiving
packets in a certain format on the top of Ethernet packets. Jari Arkko once
did it in 14 lines of (obfuscated) C, if I remember correctly. For me a
rudimentary but working version will most probably take less than a day.
Writing ARP takes a little bit longer, maybe two days, as there is some state
involved, but that is not that hard either.
TCP is the hard part, and most probably we will not support it at all, as we
are planning to support CoAP, which is UDP based. For TCP-requiring solutions
people can leave our runtime back and go for Contiki, FreeRTOS, or (in STM32F4)
Espruino. Alternatively, if there is real pressure to support also TCP, we can
do it, but it takes some 3-4 weeks worth of my hours. Even in that case I
would be tempted to write a "simplified" TCP that implements only a part of the
TCP protocol, enough to interoperate and act as a server, but not much more.
> https://github.com/dgiannakop/Arduino-CoAP
> Looks otherwise fine, but is hardcoded for XBee only. Refactoring for IP/XBee
> would require inventing and implementing an abstraction layer not yet present
> and looks like a lot of work.
Such hardcoding is not an issue. That is easy to fix. A bigger issue with
this stack is that it is version 8, while I think the current CoAP is version
14 or so. Oops, it is already version 18:
http://tools.ietf.org/html/draft-ietf-core-coap-18
Based on our earlier experiences with node.js CoAP, we need to support version
14 at least.
--Pekka
Other related posts:
