I have been trying for several days now to include Neopixel and DHT libraries on both Particle Build and Particle Dev both can’t find the header files.
The InternetButton library for example works fine on particle Build without any fiddling just following the add library method, why are the other libraries different?
Particle Dev I have gotten the furthest on by using “…/Adafruit_DHT.h” it can’t find it without the …/ in front, which i can’t find anyone else mentioning on the Forum?
It doesn’t work with “Adafruit_DHT/” in front and i can’t seem to steer the compiler to it with “lib/Adafruit_DHT/src/”. it just always looks in the project src folder. Am I doing something wrong?
Now it has found Adafruit_DHT.h (as i moved it into the project src folder) it wants application.h which then wants all the additional headers within that which is getting silly.
Searching the Libraries i can’t add a “Spark” “Arduino” or “application” library, which are all the basic functional libraries which from the forum the Particle Build IDE seems to include automatically?
How are you adding the libraries in Dev? They should show up under the project.properties folder, not directly under src. After adding the libraries from the library icon, I included them like this, and it compiled just fine,
#include <neopixel.h>
#include <Adafruit_DHT.h>
In the project.properties folder, they looked like this, so this is where I got the names I should use for the include directive.
If you don’t intend to alter the libraries it’s advisable to just link the libraries rather than copy them to your project (providing it’s supported for your platform).
But if you copy them to your project the library files should end up in the lib subdirectory as
./lib/<libName>/src/
And you should remove the examples folders from copied libraries.
But what I think the actual cause of your trouble is that you are targeting a Digistump Oak which may not yet support Libraries 2.0
Hence I think the currently only working way for you is to copy the library to your project and have the includes accordingly (I’ll post back once I’ve tried how).
The target platform and system version are always crucial informations that should be explicitly stated in the opening post - maybe even in the topic title.
I have been playing a bit with Particle Dev and as it seems that’s not a Libs 2.0 issue, since not even the simples project without any extra libraries can be built.
//#include "application.h" // not known
//#include "Particle.h" // not known
void setup() {
pinMode(D7, OUTPUT); // D7 not known
}
void loop() {
}
@ScruffR I tested your example and it seems to work in Particle Dev.
@Arc unfortunately there’s no way to rollback to Libs v1. There seem to be couple of issues here:
Neopixel library depends on “application.h” which isn’t present in Oak firmware so this seems that neopixel library isn’t compatible with Oak
Oak doesn’t support Libs v2 but by using relative paths (#include <../lib/NAME/src/NAME.h>) you can get around that
Current version Particle Dev flattens the project structure. We’re going to release fixed version soon but until then you can install particle-complete package in Atom which already contains the fix
Yup, but this had to be a problem before libs V2. I think Oak exposes itself as Arduino so if a library is both Arduino and Particle compatible then it should work fine. The solution for this would be bringing Particle support to upstream libraries and using them instead of custom forks.
Standalone Particle Dev with the fix for this hasn’t been released yet. For now you can install regular Atom and particle-dev-complete package which will give you the latest version.
