SurferTim:
@hardcore: What is the delay(300) for? I assumed that was a power-up delay.At one point during testing, I was checking the operation of the w5100 by reading one of the registers the begin routine just wrote. I rearranged the code to pass the return value back up the stack with a uint8_t type return rather than void type. With a void return, it will run that begin() routine like all is ok, even when there is no ethernet shield connected. There is something wrong about that. If the shield has failed mechanically, how would you know?
writeRMSR(0x55);
// if it isn't 0x55, return error
if(readRMSR() != 0x55) return(0);
// rest of setup
// return ok
return(1);
The Delay(300); appears to have been put in the library by some other programmer because there was a problem with the ethernet shield taking longer to come up that the arduino.
however when the programmer forces a chip reset, they failed to allow for the physical constraints of the chip, it all depends on just 'how far' into the code you can get in 10mS
The problem with checking other registers, is that one does not know 'how' the W5100 resets internally, you would have to know exactly which registers are configured and which one was configured last but the W5100.
Then there is the issue of doing this over I2C, if the Buss is flapping about , it is possible to get values back for a non existent device.
(I picked up a power reset bug on the Mega with a W5100+SD card, where after a reset you MUST physically turn OFF both devices, BEFORE configuring them)
pinMode(SS_PIN, OUTPUT); // set the SS pin as an output
// (necessary to keep the board as
// master and not SPI slave)
digitalWrite(SS_PIN, HIGH); // and ensure SS is high
// Ensure we are in a consistent state after power-up or a reset
// button These pins are standard for the Arduino w5100 Rev 3
// ethernet board They may need to be re-jigged for different boards
pinMode(ETHER_CS, OUTPUT); // Set the CS pin as an output
digitalWrite(ETHER_CS, HIGH); // Turn off the W5100 chip! (wait for
// configuration)
pinMode(SD_CS, OUTPUT); // Set the SDcard CS pin as an output
digitalWrite(SD_CS, HIGH); // Turn off the SD card! (wait for
// configuration)
The above cleared up loads of problems, specifically because during a reset you do not know HOW the pins will come up, and there were situations where the SD card was selected at the same time as the W5100 was being configured, or visa versa, I have some really nice captures of the SPI bus after a reset ,with and without the above patch.
The other issue is that many of the bugs don't actually appear until you hit the right values, casting from a Uint to an Int can cause a sign extension.
One other issue is the shear sluggedness of the library, on my initial testing of cleaning up the raw driver, I found I could get no speed increase even after some fairly shrewd optimizations, which leads to the conclusion that the delays are being introduced higher up the communication stack.
HC