#include errors when using SdFat in particle dev

Hello,

I’ve been using the particle photon for sometime now and I am having the hardest time getting any examples to work in either the web IDE or when #include libraries. It seems to happen whenever I try to incorporate an example library into an app I am trying to make. Or in the case of the Particle Dev IDE it simply doesn’t work at all.

I keep getting stuck with “insert library.h name here”: No such file or directory.

Perhaps this is an easy fix, but honestly I’m having a hard time effectively finding examples or documentation on how to do this exactly. It feels buggy, how can I do this better or fix my current issue?

Try posting a full screenshot of your Dev window.

And with Build (aka Web IDE) you just said you have problems, but not which.
Seen the docs here
for Build
https://docs.particle.io/guide/getting-started/build/photon/#using-libraries
for Dev
https://docs.particle.io/guide/tools-and-features/dev/#using-community-libraries

If you maintained the SdFat directory and it’s files, then try 2 things (as in both):
A) create a file in your source code directory named “particle.include” With the following contents:

#particle.include 
# from current dir
*.h
*.ino 
*.cpp
*.c

# and from any subdirectories
 **/*.h
 **/*.ino
 **/*.cpp
 **/*.c
  • I believe you can be specific with sub-directories by changing the “**/” to "SdFat/"
    ALSO B) Drop the directory name (Ya I know, sounds silly but the compiler wants everything to look flat, the particle.include file tells it to grab sub-directories and act like they are not so to speak)

So your include line should look like this now:
#include “SdFat.h”

1 Like

I forgot the other way to fix it though less desirable.
You can take the files from SdFat and move them up to the compile directory but this is pretty cluttered especially with SdFat.
and then make the change to the “#include” file to remove the “SdFat/” part.
At least this fix doesn’t make your teeth itch because it at least has an internal logic that makes sense.
The IDE becomes almost unusable with this though because it wants to load each file as a tab.

I found the thread I was looking for with the original info on this, I was looking for particle.include but this was old enough to be spark.include:
Much better explanation here.

Unfortunately those didn't help me much. I've read them about a dozen times before posting. They are basic help and don't mention exactly what I should include or how. Perhaps it can be expanded by a tutorial with explicit examples in the future?

I did this one by flattening the directory, see the attached image. It looks like it fixed the "library directory not found" error, but now I have errors regarding the .cpp parts of the file. I tried adding an #include with those, but it seems it still doesn't recognize them. Am I supposed to #include those as well, I thought it was just the **.h necessary. I haven't tried the addition of the first recommendation, I'll do that next.

Include portion of code with directory structure:

Errors:

These errors might be due to having not selecting a device device (see status line of screenshot - hence the request for a full window screenshot)

Also check if all files have their #include "application.h" or #include "Particle.h" (direct or indirectly)

1 Like

@svartbjorn ScruffR is absolutely right about being sure you have a device selected fix that first.
If you still have this problem, I’m making a few guesses here. I did several of the SdFat examples before incorporating them into my code.
The SdFat library really wants all of those files in the SdFat directory, the exaples subdirectory is really a collection of files that you can take one at a time, change the .cpp to .ino and either put it in the same directory as the SdFat files, or use the particle.include file and have thae.ino alone in the compile directory (or with your other files as needed) and have the SdFat directory as a subdirectory . (Remove or exclude the examples directory to avoid it being glommed onto and trying to compile all the examples with yours.

This would avoid errors with missing functions.
The other thing that can drive you crazy is if there is this line in one of the examples:
#pragma SPARK_NO_PREPROCESSOR // This will direct Arduino preprocessor to not create prototypes for functions.
// setting this means you must manually make function prototypes according to C++ rules
// This can avoid some incompatibilities with some libraries

I think the SdFat libraries require thisline. What happens when this is added is that a little nicety that Adruino does with a preprocessor gets disabled, and you must follow stricter C++ rules for the compiler. Specifically this requires all functions to be declared with a prototype before they are actually defined.

This means any function in your .ino would need to be declared after your variables and before the functions.
Examples below:
void paintScreen();
void bmpDraw(char *, uint8_t , uint16_t );
Note that the bmpDraw prototype has no actual variable names, just a list of the types it will require. Just grab all of your functions first lines, remove the variable names and stick them at the beginning of the file after the variables and before the functions.

If the functions it is complaining about don’t exist in your ino, then it is likely looking for them because they were called in your example but they are actually in the SdFat directory.

Hope this helps.

I slight correction here:
Functions have to be declared or implemented before their first use.
So you could either do this


int someFunction(); // this is a fn prototype also called forward declare

void setup()
{
  int x = someFunction(); // this is the first call to the function
}

void someFunction()
{ // this is the implementation
  return 1;
}

or this


void someFunction()
{ // this is the implementation already before first use - no prototype required
  return 1;
}

void setup()
{
  int x = someFunction(); // this is the first call to the function
}

And there is no need to remove the var names from the argument list.

Absolutely right, old habits, i always do it this way so its a law only in my head.

This worked for solving a good deal of the issues. After that I only had a bug that required me to create the stm32_it.h file. For some reason I couldn't find it in the SDFat example.

As a side note I also noticed that I sent a screenshot of a previous example I was using that was for a sfs library. I guess I had picked it up in a previous SD discussion. I corrected that mistake and now I have a program writing to my MicroSD :grin:

What's unusually is that I wrote some functions but I didn't initiate like this. I created it after the setup and loop routine, but the compiler didn't make me declare it at the beginning of the code.

Is it just in general best programing practice to declare it that way?

This is an example of what I did:

//Includes, global variables, and other things. No declaration of thisFunction().
void setup()
{
 //some programming things.
}
void loop()
{
 thisFunction();
}

void thisFunction
{
//some programming things.
}

This quote about prototyping was related to this part of @svartbjorn's post ...

... clarifying a subsequent statement of his.

If you have #pragma SPARK_NO_PREPROCESSOR in your .ino, you will need to prototype (or implement beforehand).
Otherwise the preprocessor does this for you.

@ScruffR @svartbjorn, Thank you both for your help! After reading what you two have mentioned and giving the code further review I was able to get the library to work.

As a closing note, I was having some separate troubles with the SdFat libraries .read() class. It would return an integer, however I was having difficulty converting this to ascii encoded char and float data types. I figured it out using the C++ static_cast, then convert to string by .toCharArray(), and lastly atof(). Interesting stuff, but I don’t necessarily what to derail this thread. Is there a section i could share code bits or things I’ve come across?

Thanks again!

1 Like

You can always open a new thread in the General section to “document” your findings for others to benefit and/or contribute.