T3.5: SD.open failing

[Fenichel]

I have been having difficulty with a datalogger-style project; all of the code for the failing component is in the attachment. This component receives messages from remote components via XBee transceivers, and then it (for now) just stores the incoming data

The problem is all in the tFileBuffer.SaveContents() routine in FileBuffer.inc.

void tFileBuffer::SaveContents()
  { if (NChars > 0)
      { // flush it
        // File SaveFile = SD.open(FileName);           // these fail identically
        File SaveFile = SD.open(FileName, FILE_WRITE);  // ..
        if (SaveFile)
          { // nondegenerate
            SaveFile.seek(SaveFile.size());
            // SaveFile.write(TheBuffer, NChars);  // this should work;
            for (int I = 1; I <= NChars; I++)      // this put in for absolute
              { SaveFile.print(TheBuffer[I-1]); }  //   simplicity in debugging.
            Serial.printf("  saved %d chars in %s, file size now %d\n",
                             NChars, FileName, SaveFile.size());
            SaveFile.close();
          } // nondegenerate
        else
          { Serial.printf("couldn't open %s\n", FileName); }  // this is what always happens

        NChars = 0;
        digitalWrite(pinuSD, HIGH);
      } // flush it
  } // tFileBuffer::SaveContents()

Control comes here long after the SD library routine has been successfully initialized (in the main program's setup), and all that tFileBuffer.SaveContents() has to do is to append the characters of TheBuffer to a file whose name is the value of FileName. Filename can be other things, but here it's always 1.txt.

It doesn't matter whether I try to open 1.txt with SD.open(FileName) or SD.open(FileName, FILE_WRITE). Either way, the open fails.

There's probably an silly error in my use of the SD package. What is it?

 

[Fenichel]

addendum:

• the uSD card is 2GB, formatted FAT32
• all of the example SD programs run without problem

 

[PaulStoffregen]

Maybe this

      void SetFileName()              { sprintf(FileName, "%d.text", FileNumber); }

was meant to be "%d.txt"?

This might work if you use 1.54-beta, where SD has become a thin wrapper for SdFat which supports long filenames.

But if you're using 1.53 or older, the Arduino SD library only supports 8.3 format file names.


Also, the unusual way this code is arranged with includes of code rather than headers and almost all variables effective global scope and the use of full Windows pathnames makes it kinda difficult to read for everyone who's accustomed to the more conventional way C / C++ code is structured.

 

[Fenichel]

Maybe this

      void SetFileName()              { sprintf(FileName, "%d.text", FileNumber); }

was meant to be "%d.txt"?

Yes, of course. I knew it would turn out to have been a slip at that bonehead level, but I stared at the code without seeing it. Thanks.

Also, the unusual way this code is arranged with includes of code rather than headers and almost all variables effective global scope and the use of full Windows pathnames makes it kinda difficult to read for everyone who's accustomed to the more conventional way C / C++ code is structured.

Using .h & .cpp files makes a lot of sense when there is non-trivial time to be saved by not recompiling modules until they've been changed. Using that style means, however, that

• there are twice as many files around, making refactoring more tedious, and
• the hated Arduino IDE tries to take over as editor.

In most of my applications, there is a single, central file for globals that are not defined in the main program. All of the other globally-accessible variables are properties of defined classes, and almost every one of my classes is defined in its own file, so the properties are easy to find, especially since if any sorts of things can be in alphabetic order, they are. I use almost no #defines, so my code, compared to most of the code I've seen, actually has fewer globals whose definitions are hard to find. I find my code easy to navigate, even in big applications. Well, everyone finds his own code easy to navigate, and I recognize that my files might be strange and murky to people who use more conventional style.

You're right about the use of full Windows pathnames. I started using them because I kept getting sandbagged by the Arduino IDE's arcane library-linking rules, but full pathnames are a bad habit.

Thanks again for your help.