SurferTim:
as you can see there is an infinite loop until the register changes.
Actually, there is a loop until the register stops changing. It is in that loop until the two reads are the same.
yes you are right, i misread the code a bit
SurferTim:
Edit: If the client.available() function seems to lock up, there is another possible cause. Here is the bug and fix.
Google Code Archive - Long-term storage for Google Code Project Hosting.
interesting i will have to take a look at that.
the issue i have currently is that the later part of sendto() in socket.cpp never gets the timeout flag.
my current test case is raw ip to a non existent host, timeout bit in SnIR should be set in this case and i can see that multiple arp requests is being sent on the network and then the device stops doing anything useful.
adding a few Serial.println() showed that sendto() never completed.
did a little workaround to make it exit quicker but then the check to see if there was any data got stuck instead (available())
anyway, i will have to do some more debugging to find the root of my issues.
it may also be possible that i'm running out of ram as suggested elsewhere in this thread.
another question, is there a reason why for example EthernetClient don't have a destructor?
it is very easy to leak sockets by forgetting to call EthernetClient::stop() and a simple fix is to just add a destructor that calls stop().