The `find` function expects a pointer to a string. We were passing string constants which generated compiler warnings, `warning: deprecated conversion from string constant to 'char*'`. Casting the string constants to a pointer to a char (at least that's what I think this does) makes the warning go away.
This reduces the number of `warning: deprecated conversion from string constant to 'char*'` warnings by 1. It does, unfortunately, increase the sketch size from 30,080 to 30,108 when compiled using Arduino 1.0.1.
While I'm not familiar enough with Arduino programming to fully understand this change, I do know that it reduces the number of `warning: deprecated conversion from string constant to 'char*'` warnings from 14 to 5 (once for each of the calls to debug that pass a string).
If there are problems opening the SD card for access then there's no point continuing as we can't cache the data. Slightly controversially, I've chosen the bump the error codes (number of LED flashes) of a DHCP failure and cache failure. I don't think this is too much of a problem, partcularly because I've bumped the version number.
*NOTE* The main motivation is to reduce the size of the data we're storing in RAM. The sketch before this commit would fail to print when debug was enabled. The image would be downloaded successfully but would appear not to be cached (cache.size() returned 0). * Remove 'dhcp fail' debug statement. The flashing error LEDs, along with the code comment, should provide enough information. * Remove 'failed to clear cache' debug statement. The flashing error LEDs, along with the code comment, should provide enough information. * Remove 'cache cleared' debug statement. The sketch will 'terminate' if we couldn't clear the cache. If it doesn't terminate, we can imply that the cache was cleared. * Remove 'starting request, cache size is' debug statement. This statement wasn't adding any useful information. If our sketch makes it to the 'Attempting to connect to...' line, then we know that the cache was 0, and that we're trying to connect. * Remove 'still connected' debug statement. Both the 'still connected' and 'waiting for data' debug statements are printed within the loop that continues all the time the client is connected. I think that one of these statements is sufficient.
If the connection to printer.gofreerange.com times out (after about 33 seconds) then we try to report the duration of the request. Unfortunately, this relies on `start` being assigned a sensible value, which was only happening after a successful connection. Prior to this fix, when the connection timed out, the duration would be reported as a very large number like 4289767837. This commit also removes the (in hindsight, obvious) compiler warning, `printer.cpp:176: warning: 'start' may be used uninitialized in this function`.
This makes the sketch slightly smaller (saving 16 bytes under Arduino 1.0.1) and is consistent with how we currently terminate when encountering a DHCP error. It'll also make it easier to use `terminalError` in the setup function. Without this change, we would've had to check the systemOK boolean to see whether we could continue with setup.
It's not really an error code as such; it's just the number of times to flash the error LED. This'll be useful to display a different 'code' when the system fails for different reasons.
This delay is to separate the error flashes from the startup flash, so lets keep it with the startup flashes.
After initialization, the error LED will flash three times, indicating a failure to clear the cache. The sketch will then 'terminate' in as much as it won't do anything in the main loop. I've seen the sketch fail to clear the cache on multiple occassions. I'm not 100% sure how it gets in this state but the only solution appears to be deleting the cache ('TMP') or formatting the card in another machine. There's some duplication between `abortDueToCacheFailure` and `recoverableError` that I should be able to factor out later. I've removed the `systemError` function and inlined the switching on of the error LED. This is so that I can use a boolean named systemError to indicate that the sketch should terminate.
Thanks to @techbelly for the nudges in the right direction. Our best guess is that this might be a buffer issue in the Ethernet library.
When the version header was present, the Arduino would download data, but then fail because the cache size (the file on the SD) was apparently zero length. I tried this with other dummy headers, and basically any other header seemed to screw up the Arduino cache. Why sending another header would affect the behaviour of the downloading, or the SD card, I have absolutely no idea :( I've tried making the requests locally via curl, but the responses are completely identical, even down to a binary diff.