SD Card and Ethernet lead to avrdude: stk500_recv(): programmer is not respondin

Projects Programming
1

Hi I combined the SD card ReadWrite sketch with one of my sketches and as soon as I add

  myFile = SD.open("test.txt", FILE_WRITE);

It breaks my sketch.
I get the error

avrdude: stk500_recv(): programmer is not responding

2

Adding the SD library uses a lot of SRAM. That can do strange things as the sketch is uploaded.

Post your code, so we can see if there are ways to reduce SRAM usage.

3

Oh that would make sense.

Here is my code, I would take a guess that it is probably not very efficient

4

Here is my code, I would take a guess that it is probably not very efficient

Efficient isn't really the issue.

#include <SPI.h>		 
#include <Ethernet.h>
#include <EthernetUdp.h>
#include "Dns.h"
#include <Wire.h>
#include <Ports.h>
#include <PortsSHT21.h>
#include <SHT2x.h>
#include <Time.h> 
#include <SD.h>

Each of these gobbles memory. Some more (I was going to say worse, but that's not fair. They only take what they need) than others.

		Serial.println("Failed to configure Ethernet using DHCP");

You could move this string into PROGMEM, using the F() macro:

		Serial.println(F("Failed to configure Ethernet using DHCP"));

That saves some SRAM.

		Serial.println("DNS resolve...");	 
		Serial.print("DNS fail...");
        Serial.println("DNS resolve...");	 
		Serial.print("Seconds since Jan 1 1900 = " );
		Serial.print("Unix time = ");
		Serial.print("The UTC time is ");		// UTC is the time at Greenwich Meridian (GMT)
        Serial.println("This is the s ");

More stuff that could be moved.

5

The serial print stuff is just there for bug testing, so would commenting it all out be beneficial to reducing ram?

Are there any alternative libraries that you know of that are more conservative towards SRAM? Should I keep the sketch see below 29000 bytes because that is where the funny stuff seems to happen?

Is there anything else I could get rid of that you see as unnecessary? within the code? or a way to trim down the libraries?

6

The serial print stuff is just there for bug testing, so would commenting it all out be beneficial to reducing ram?

Yes.

Are there any alternative libraries that you know of that are more conservative towards SRAM?

No. As I mentioned the libraries are not wasteful of SRAM. They have all been reviewed and trimmed as much as possible.

But an SD card is designed, hardware-wise, to be written to in 512 byte chunks. So, the SD library needs 512 bytes to hold the data that it is to write to the card.

Should I keep the sketch see below 29000 bytes because that is where the funny stuff seems to happen?

If you can. There are no guarantees, though.

Is there anything else I could get rid of that you see as unnecessary?

No. Short of cutting functionality, I don't see a way to improve things. Time to think about a Mega, I think.

7

Hey,
So thats why the SD library kills my SRAM then.
Yes I have been looking into the Mega but the 1280 is an expensive chip.
are there any other storage options that offer at least 4MB of memory that would not suck up SRAM?