Function to dump SD text files over serial

I have written a function that will take the text file name into a file dump function. I plan to plug into serial and use something like hyperterminal to drop it into a file on my laptop

  //dump files from serial connection when appropriate number recieved
  if (Serial.available() == 1) {
    DataDump("SETTINGS.txt");
  } else if (Serial.available() == 2) {
    DataDump("TEMPLOG.txt");
  } else if (Serial.available() == 3) {
    DataDump("TIMELOG.txt");
  } 




void DataDump(String FileName) { //files available ; TempLog; TimeLog; Settings;
  File DumpFile = SD.open(FileName);
  if (DumpFile) {
    while (DumpFile.available()) {
      Serial.print(DumpFile.read());
    }
    DumpFile.close();
  }
  else {
    Serial.println("Dump file error.........");
  }
}//   eg  DumpFile(TEMPLOG.txt) , DumpFile(TIMELOG.txt) , DumpFile(SETTINGS.txt)

I havent tested this yet but my concern is that in the File DumpFile = SD.open(FileName); in the function the FileName wont have be surrounded by “”. So it wont in fact be the text files name but rather a variable???
Can any one see why this wouldnt work and if this is actually possible??

Thanks

  if (Serial.available() == 1) {
    DataDump("SETTINGS.txt");
  } else if (Serial.available() == 2) {
    DataDump("TEMPLOG.txt");
  } else if (Serial.available() == 3) {

You decide what to do based on how much serial data you haven't read? That's bizarre.

void DataDump(String FileName) { //files available ; TempLog; TimeLog; Settings;

Not on my SD card. There is no reason to piss away resources on Strings, when char * works just as well, and does NOT need to be f**ked with to get the open() method to use the data.

  File DumpFile = SD.open(FileName);

The open() method in the version of the SD class that I checked is not overloaded to accept a String.

    while (DumpFile.available()) {
      Serial.print(DumpFile.read());
    }

It would be far faster to read the data in chunks and send the data in chunks.

so I wrote it out properly to check for incoming serial inputs but I think due to a delay I use in the software I could never actually get the serial input. Am I thinking the right way here. is there a serial input buffer that takes whatever you send, whenever you send it or does the software have to be expecting it before it will actively see if something is coming in?

Anyway, ive broken out of the loop so that for a limited time during start up I will wait for the serial input (with no delays), if nothing is received after a given time the rest of the software will run and ignore this bit.

Ive also just read that the mega has 3 serial ports to use. Im only intended on plugging in to dump the text files out over serial so I do I need to specify anything other than Serial. ?? As it streams everything to the serial monitor Im guessing I wont need to change anything as its the same port.

Also, if I store the files names like this
char* timeFile = "TIMELOG.txt";

will that pass through the "" because in the IDE its highlighting it as a string. But im getting no errors.

steven_191:
is there a serial input buffer that takes whatever you send, whenever you send it...

Yes. In the Arduino environment, there is a rx-buffer that gets filled in the background.
63 bytes deep (configurable, variant-dependent), incoming byte will be dropped when this buffer is full.
'whatever, whenever' that's too Shakira. Who is you in 'you send'? Let me try to summarize:
I you receive data it will enter the receive buffer, if you send data it will enter the transmit buffer.
One fills in the background, one empties in the background.
Keep both resources from overflowing and you get a smooth communication.

steven_191:
Ive also just read that the mega has 3 serial ports to use. Im only intended on plugging in to dump the text files out over serial so I do I need to specify anything other than Serial. ??

The Mega has 3 additional serial interfaces.
In your code you can use Serial1, Serial2 and Serial3 instead of Serial.

To read from these from the PC, you will need a serial-USB adapter/converter or the like.

steven_191:
Also, if I store the files names like this
char* timeFile = "TIMELOG.txt";

will that pass through the "" because in the IDE its highlighting it as a string. But im getting no errors.

This definition does not pass anything anywhere.
I you refer to the content of the literal, that timeFile is made pointing to by the definition:
No, the "" are just delimiters for the string, to tell the compiler where your string starts and where it ends.

One more note:

char* timeFile = "TIMELOG.txt";

This will probably work, but it will be used as if "TIMELOG.TXT" had been passed.
So if you want to compare filenames later in your code, you are building yourself a trap with definitions like that.

OK, so I'm making progress. Ive got a response from the SD card file but I believe its all sending back in big chunk of ascii
so do I need to receive each byte and convert it to something else so it reads the same as it does on the card?What is the 'something else'. string or char?

Ive got the data spitting out now over serial. I was using the wrong function in the SD card reading but its working now.

Im using this to read the data which comes out fine onto the serial monitor.

void DataDump(char* FileName) { //files available ; TempLog; TimeLog; Settings;
  Serial.print("begining serial dump of file - ");
  Serial.println(FileName);
  File DumpFile = SD.open(FileName);
  if (DumpFile) {
    while (DumpFile.available()) {
      Serial.write(DumpFile.read());//read until nothing is left
    }
    DumpFile.close();
  }
  else {
    Serial.println("Dump file error.........");
  }
  incoming = 0;
  //wdt_enable(WDTO_8S);//re-enable watchdog
}//   eg  DumpFile(TEMPLOG.txt) , DumpFile(TIMELOG.txt) , DumpFile(SETTINGS.txt)

if the file is excessively large, would I be causing any issue with memory usage or does it handle this a byte at a time or something like that to not overdo itself?
thanks

Serial.write(DumpFile.read());//read until nothing is left

This handles one byte at a time, so no problems with memory usage.