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?
Phil. PS: http://code.google.com/p/avr-uip/ looks rather better!
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.
On 28/05/12 10:41, Chris Green wrote:
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.
I wouldn't even go that far, people used to working professionally at this level of microcontroller usually write quite nice code as you need to be as optimal as possible to squeeze into the memory/flash/runtime limitations and yet do anything useful.
That said optimal and easy to read don't always go hand in hand.
But the truth is that the Arduinio project is just full of shit code even the code examples built into the IDE are poor, loads of libraries on arduino.cc are also badly written.
But that isn't the point of Arduino, it's not supposed to be a basis for any serious or commercial project, it's an educational project to present the straightest path to getting something up and running as quickly as possible so new users get instant gratification.
Hence most of the examples and libraries are written to be easy for a beginner to understand rather than efficient.
On Mon, May 28, 2012 at 09:44:05PM +0100, Wayne Stallwood wrote:
On 28/05/12 10:41, Chris Green wrote:
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.
I wouldn't even go that far, people used to working professionally at this level of microcontroller usually write quite nice code as you need to be as optimal as possible to squeeze into the memory/flash/runtime limitations and yet do anything useful.
'Quite nice' in some ways but often not in the way that would be accepted as 'best practice' by a software engineer.
That said optimal and easy to read don't always go hand in hand.
That's very true, though even Arduino systems have way more memory than I was used to working with back in the 1970s and 1980s when I started.
It's often neat, elegant code which takes less space anyway.
But the truth is that the Arduinio project is just full of shit code even the code examples built into the IDE are poor, loads of libraries on arduino.cc are also badly written.
But that isn't the point of Arduino, it's not supposed to be a basis for any serious or commercial project, it's an educational project to present the straightest path to getting something up and running as quickly as possible so new users get instant gratification.
Instant *hardware* gratification isn't it? It's certainly what
The Arduino home page says "Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments. "
An "electronics prototyping platform" says it - hardware.
Hence most of the examples and libraries are written to be easy for a beginner to understand rather than efficient.
But they're not are they? (easy to understand that is)
-
Chris Green -
Phil Ashby -
Wayne Stallwood