On Mon, May 28, 2012 at 09:49:40AM +0100, Phil Ashby wrote:
Chris Green cl@isbd.net wrote:
I'm doing some programming of a Nanode board (not far removed from Arduino) which has an ethernet interface based on the ENC28J60. ... However the loop that waits for ethernet packets and deals with them seems a bit odd to me, in psuedo-code it's something like:-
while (not reset) { get a packet from ethernet handle DHCP message handle message requesting local display on LCD handle ARP request handle DNS request handle NTP request if (still something left) { if (ping) { respond to ping } if (UDP message for us) { handle our message } } }What I'm not clear about is whether one packet can only be one of the above things. Hence, if a DHCP request of some sort has been received and handled can the *same* packet contain other requests? If not then why is the code going through all the other calls?
Hi Chris - you are correct in assuming that one packet can only be one thing, since a combination of packet type fields (Ethernet frame type, IP frame type, TCP/UDP port number) determine this.
OK, it makes for simpler looking code, no conditionals and/or switch/case but it somehow seems wrong (and a bit inefficient as each handle function gets called even if the packet has already been handled).
Just been and looked at the code in github for the Nanode Ethershield and all I can say is yuk!
https://github.com/Nanode/EtherShield/blob/master/ip_arp_udp_tcp.c
I quote: "The TCP implementation uses some size optimisations which are valid only if all data can be sent in one single packet. This is however not a big limitation for a microcontroller as you will anyhow use small web-pages." Hmmn.
I found the code confusing, badly structured and incomplete (eg: it doesn't work if IP options are sent and there is nothing like the full TCP state machine with various timers, backoff controls and such, only a happy path).
Of course I may have been looking at different code - got a URL?
The code I am working on is derived from the basic code that you have found, it's fundamentally just as horrible.
If you look at some of the Arduino examples you'll see the sort of stuff that sits 'on top' of what you have looked at. It doesn't need to be 'complete' because of the essentially trivial things the examples do, Arduino boards just aren't powerful enough to do a great deal.
I asked the question because I wondered if I was missing something clever in the code but (as nearly always) I think it's just rather badly written.
Looking at all the Arduino (and related) stuff it does seem that the code is rather poor, I think it's mostly written by hardware people and it shows.