SdFat library not working with Boron

Hello,

I can not use the SdFat library with my Boron, even the existing SdFat examples don’t work. Can anyone give it a try? It refuses to compile for me on the web IDE. If I switch the device from the boron to the electron then everything is working.

Cheers and happy Thanksgiving

@superseb, because of the difference in underlying hardware and the new mesh PLATFORM_IDs, many libraries will need to be updated for mesh devices. Some, due to hardware-specific reasons, may not be portable.

ah shoot. I wanted to use the Boron both as an SD datalogger and to send data to the cloud. Do you have any suggestion of a compatible SD card library? Otherwise I guess I can use my adalogger to save data and it will then send data through serial to the boron that will send it onine.

I have the same need and I no doubt there are many others with the same need. It’s a tremendous piece of work.

Several months ago the author of SDFat (RWG) advised as follows:

“For the past year I have been doing a major rewrite of SdFat. I have added support for exFAT and restructured the library.

I am trying to make most of the code independent of the the Arduino IDE/API. I hope to simplify porting the library to new environments.

I have ordered two each of Argon, Boron LTE, and Xenon.

I will soon release a beta of SdFat V2 for Arduino and then use the mesh processors for testing the portability of SdFat V2.”

I hope to have two each of the mesh processors soon. I understand my order should ship in the next few days.

I will try to make the current Github version of SdFat work on mesh processors.

1 Like

Apologies for the wrong initials on my previous reply - was getting late at night :grinning:

Thanks for your efforts - I for one really appreciate them and I am sure I am not alone.

Is the any update on this by chance? I am affected and considering trying to find the error in the library in regards to mesh devices and try to adjust it to work.

@Alterxend, there is no error per se. The author wrote it to use PLATFORM_ID for Particle devices. However, the new Mesh devices are not included in the PLATFORM_ID tests so the compile errors out.

Oh, apologies I understand now, thank you.

1 Like

I just received my mesh processors.

I tried to compile this version of SdFat. It has a conflict with symbols defined in the lwip library.

lwip defines O_RDONLY, O_RDWR, AND O_WRONLY.

using #undef appears to make SdFat work and the mesh net still works.

These symbols should also be defined in fcntl.h on particle.

I need to find a better solution than #undef.

1 Like

I am able to run this test program with an SD connected to the SPI pins of an Argon. I use the default SPI_SS pin for SD chip select.

test.ino:

#include "SdFat.h"
SdFat sd;
File file;
#define error(msg) {Serial.println(msg); while(1)yield();}
void setup() {
  Serial.begin(9600);
  while (!Serial) {
    yield();
  }
  Serial.println("Type any character");
  while (!Serial.available()) {
    yield();   
  }
  if (!sd.begin())error("begin");
  if (!file.open("test.txt", O_CREAT|O_RDWR))error("open");
  if (!file.println("Hello World!"))error("println");
  if (!file.close())error("close");
  Serial.println("Done!");
}
void loop() {
}

I started with this version of SdFat.

I made this CLI project with the above file in src and SdFat in lib

C:\Users\bill\Documents\Particle\projects\test>ls *
argon_firmware_1544036607341.bin

lib:
SdFat

src:
test.ino

I added the following to the top of C:\Users\bill\Documents\Particle\projects\test\lib\SdFat\src\FatLib\FatApiConstants.h

#undef O_RDONLY
#undef O_RDWR
#undef O_WRONLY

This produces the expected file, test.txt, containing the line “Hello World!”.

1 Like

Hi whg,

It looks like the RDONLY, RDWR, and WRONLY tags are fighting with something along the lines of the WiFi or similar comms library in the mesh firmware. I ended up doing a search for each instance of those tags in the SdFat folder, and just prepended them with SDFAT_, worked fine after that. Might be less trouble than undef’ing them, I’m not sure if that could cause trouble with the other comms library…

1 Like

There is a general problem with these symbols in the mesh software.

They are defined in the lwip library and in the standard fcntl.h include file.

The particle version of lwip has these definitions:

#ifndef O_RDONLY
#define O_RDONLY    2
#endif
#ifndef O_WRONLY
#define O_WRONLY    4
#endif
#ifndef O_RDWR
#define O_RDWR      (O_RDONLY|O_WRONLY)
#endif

fcntl.h for the ARM compiler uses the standard POSIX/Linux values.

/*
 * Flag values for open(2) and fcntl(2)
 * The kernel adds 1 to the open modes to turn it into some
 * combination of FREAD and FWRITE.
 */
#define	O_RDONLY	0		/* +1 == FREAD */
#define	O_WRONLY	1		/* +1 == FWRITE */
#define	O_RDWR		2		/* +1 == FREAD|FWRITE */

Unfortunately fcntl.h is not included in lwip so the inconsistent value are defined.

I am modifying SdFat to use the values in fcntl.h I will #undef the symbols if they have the lwip values.

Too many apps use the symbols in other versions of SdFat so I don’t want to change their names.

I will also change the values for these open flags (O_APPEND, O_CREAT, O_TRUNC, O_EXCL, O_SYNC) defined in fcntl.h to avoid future problems.

I am also using these values in the new version of SdFat which supports exFAT.

3 Likes