So, I've been busy adding the finishing touches to my ludicrously over-specified camera intervalometer, making use of every last bit of hardware on the cobbled-together device.
I'd been decidedly miserly with both flash and SRAM (~18000 bytes flash used, 1600 bytes SRAM free) so I linked in the SD library for gratuitous logging purposes - which worked correctly, so I did a bit more coding. (I had a few kilobytes of flash and about 700 bytes of SRAM free at that point). Then things broke.
After much to-ing and fro-ing, it appears that if my sketch goes beyond about 29000 bytes, I get the dreaded 'avrdude: stk500_recv(): programmer is not responding' error. 28000 bytes or so, everything works fine. It doesn't matter what the code is - SD card stuff works just fine again if I comment out a completely unconnected block of code, for example. The following is with the light-sensor trigger commented out and SD logging left in, for example, but it's really not specific as to the code that's removed:
This works:
Binary sketch size: 28290 bytes (of a 32256 byte maximum)
This doesn't work:
Binary sketch size: 29326 bytes (of a 32256 byte maximum)
avrdude: stk500_recv(): programmer is not responding
I'm using Arduino 0022 on a MacBook Pro running MacOS X 10.6.8, and the hardware is a recently acquired Arduino Uno.
The only potential weirdnesses I can think of can be the DS1307 RTC's 1Hz square-wave output hooked up to digital input 2 (makes a beautiful external interrupt - the microcontroller spends most of its time powered down) and the all-buttons-condensed-into-LOW-on-any-pressed on digital input 3, also for wakeup-interrupt purposes. But quite how they'd interfere in such a precise manner, I've no idea.
Try re-flashing your chip with westfw's optiboot bootloader - it only take arround 500 bytes. Someone else with more knowledge can confirm, but I think the default bootloader takes around 2k, hence your problem.
Alternatively remove the bootloader altogether if memory is that tight, and program your raw code with ICSP.
Texy
I'd read somewhere that Arduino Unos came with optiboot installed as default - but it looks like mine might have something else.
Conveniently, my new Arduino Ethernet arrived yesterday (for a different project). While it won't physically fit inside the camera trigger stuff, it accepted the 29326-byte sketch without any issues. Apparently they definitely do come with optiboot installed.
I tried reflashing the Uno's bootloader using the Ethernet as a reprogrammer thingy, with the help of this guide. Unfortunately I couldn't reflash the Uno, but I could reflash the Ethernet using the Uno as a programmer. (While my Arduino was working fine with the FTDI cable, I'd bookmarked that page before it arrived, just in case I did have problems.)
When trying to reprogram the Uno, the Ethernet would get as far as 'Starting Program Mode' but never printed '[OK]'. The other way round, things worked fine. This could be operator error.
I'm going to try reflashing the Uno some other way - either by using the Arduino IDE's more official way of reprogramming using a second Arduino, or through borrowing a proper reprogrammer. Either way, I'll get optiboot onto the device somehow...
While I haven't fixed the original problem yet, converting the code to use the simpler Fat16 library (instead of the chunkily large SD one) resulted in about a 4kB reduction in flash memory used. So I can fit the whole thing in again. Hah!
That fixed it! I deliberately bloated-up my already large sketch with a gigantic PROGMEM string, and this now uploads without problems:
Binary sketch size: 31858 bytes (of a 32256 byte maximum)
I used my Arduino Ethernet to do the reprogramming, but this time I wired it up exactly as specified in the diagram, rather than try to be clever and avoid the ethernet's chip-select pin. It now works.
Huge thanks for pointing me to the previous threads; my previous Googling failed to find them...
