Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: T3.5: SD.open failing

  1. #1
    Member
    Join Date
    Feb 2019
    Location
    Vancouver, BC
    Posts
    31

    T3.5: SD.open failing

    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.
    Code:
    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?
    Attached Files Attached Files

  2. #2
    Member
    Join Date
    Feb 2019
    Location
    Vancouver, BC
    Posts
    31
    addendum:
    • the uSD card is 2GB, formatted FAT32
    • all of the example SD programs run without problem

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,454
    Maybe this

    Code:
          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.

  4. #4
    Member
    Join Date
    Feb 2019
    Location
    Vancouver, BC
    Posts
    31
    Quote Originally Posted by PaulStoffregen View Post
    Maybe this

    Code:
          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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •