I am porting my main application over to Workbench. In doing the first local compile I am hitting some problems not seen with cloud compile on Web IDE that related to the SDFat library. I would appreciate any advice/help about how to understand and fix these 4 errors. The first 3 appear to be something to do with “Arduino.h” header which is included.
/Users/xxx/Documents/xxx/VSC_Projects/z-t-base/lib/SdFat/src/FatLib/FatLibConfig.h:139:0,
./inc/Arduino.h:22:2: error: #error isnan is not defined please ensure this header is included before any STL headers
#error isnan is not defined please ensure this header is included before any STL headers
/inc/Arduino.h:203:1: error: expected ';' before 'using'
using std::isinf
^
./inc/Arduino.h:240:1: error: expected ';' before 'typedef'
typedef USARTSerial HardwareSerial;
/Users/xxx/Documents/xyz/VSC_Projects/z-t-base/lib/SdFat/src/SdCard/SdInfo.h:112:34: error: 'F_CPU' was not declared in this scope
#define SPI_HALF_SPEED SD_SCK_HZ(F_CPU/4)
I have set the SDFat library version to be 0.0.7 whereas it appears to have installed 1.0.16 which is the latest and has these problems.
I have that in the list of includes but after the SDFat library include.
That won’t solve the issue with the F_CPU?
I thought you could specify a library version in the project.properties for the project but what seems to happen when I install the library is that it takes the latest version and then auto corrects the project.properties.
Putting #include “math.h” in didn’t solve the errors
/inc/Arduino.h:22:2: error: #error isnan is not defined please ensure this header is included before any STL headers #error isnan is not defined please ensure this header is included before any STL headers
^
./inc/Arduino.h:203:1: error: expected ‘;’ before ‘using’
using std::isinf
^
./inc/Arduino.h:240:1: error: expected ‘;’ before ‘typedef’
typedef USARTSerial HardwareSerial;
I have just been considering how to do that - it is a rather large application and there are bits I can’t share. I have compiled other applications targeted at Gen3 on 1.4.2 and using SdFat 1.0.16 and they work fine - thus I believe it is something related to Photon as the PlatformID. The SdFat library deep down has many Arduino.h includes amongst others from the standard libraries stdint, etc.
New project
Installed SdFat library (latest 1.0.16)
Opened “ReadWrite.ino” from examples folder of LIB - copied content and pasted to .ino in src folder
Target device Photon with 1.4.4
Compiled clean
> Executing task: make -f '/Users/shanevanj/.particle/toolchains/buildscripts/1.8.0/Makefile' compile-user -s <
:::: COMPILING APPLICATION
text data bss dec hex filename
12572 108 2644 15324 3bdc /Users/shanevanj/Documents/Workbench/Test/Test/SDFatTestPhoton/target/1.4.4/photon/SDFatTestPhoton.elf
*** COMPILED SUCCESSFULLY ***
Press any key to close the terminal.
So at a basic level - this shows the standard library in a small standard test works - you will need to find all the sdFat related calls in your app to narrow the search, since there are many, many functions in the sdFat library and you may be calling something that has a specific ARCH dependancy. I would comment out sdFat.h - compile and extract all the sdFat function call errors (perhaps that you can publish here) and we can work through them to find the culprit(s)?
Not even via PM with NDA? (hence the "me" in my post vs. "us")
I have never had a problem with the Photon's platform ID with SdFat.
If you want to dive into the library you may also need to consider other compiler options (e.g. the Photon also falls into the ARM branch as well as STM32F* and potentially others too) but that is a deeeep rabbit hole
Thanks - I appreciate the responses/help @shanevanj@ScruffR. I will work along the lines suggested and if it can’t find anything then I’ll PM with a link to the code in a dropbox to see if you super sleuths can unearth the issue.
I had an idea to move the #include <SdFat.h> to just after #include “Particle.h” and low and behold the first 3 issues disappear. This last issue was solved before. I will go and try this on the Workbench copy.
Yes, F_CPU is not declared and that won’t go away as long you use any macro that expects it to be declared (i.e. SPI_HALF_SPEED).
The way around this is to either use SD_SCK_HZ(), SD_SCK_MHZ() or even better SPISettings() directly.
I am sure I can figure my way around that - thanks for the pointers.
I had another funny on the Workbench compile where I have added to the Adafruit_ILI9341 library and defined DEG_TO_RAD - I get a warning that I am redefining it, turns out that this was declared before in spark_wiring_arduino_constants.h but if I remove from Adafruit_ILI9341.h I then get an error saying not defined. Is this to do with using or not using EXTERN ?
Probably not especially when this constant is #defined via the compiler directive and that is one reason why #define is considered "bad" (by some ).
You'd need to know in what order the compiler compiles the module (especially expanding #include statements and macros) and #defines are always local to the module and are non-existent at link time.
If you do get a redefinition warning for a #define you should check all instances of this definition for consistency and make sure you don't inadvertently introduce incompatibilities. Once you have made sure it's safe to redefine you can wrap your "redefinition" in a #ifndef block to only define it when it's not already defined, otherwise stick with the preexisting one.
Whenever I come across code that uses #define for constants I sustitute that with a const <fitting data type> declaration to avoid confusion.
I prefer a failing build due to a proper error (the latest at link time) due to multiple declarations over a "silent" warning which may hint a re#define of something I'm later on using with the expectation that it still has its original value, causing extra debugging effort.
Thanks for those learning points - I know @m_m likes to hear this - the Workbench compile and output is tons better in uncovering these things and in tracing the definitions. Case closed.