I'm trying to check the total size and the used bytes of the Flash-FileSystem on an ESP8266.
I'm using Arduino IDE (2.0.1) with "esp8266 by ESP8266 Community" (3.0.2)
I found in different tutorials the commands
#import <FS.h>
SPIFFS.usedBytes();
SPIFFS.totalBytes();
Also in the arduino-esp32-documentation I found this functions, but the compiler says:
In file included from C:\Users\...\esp8266_temp_humid_log_with_http.ino:38:
C:\Users\...\http_serving.h: In function 'void showFilesize()':
C:\Users\...\http_serving.h:42:24: error: 'class fs::FS' has no member named 'totalBytes'
42 | int tBytes = SPIFFS.totalBytes();
| ^~~~~~~~~~
C:\Users\...\http_serving.h:45:25: error: 'class fs::FS' has no member named 'usedBytes'
45 | int uBytes = SPIFFS.usedBytes();
| ^~~~~~~~~
exit status 1
Compilation error: 'class fs::FS' has no member named 'totalBytes'
I know, SPIFFS is depricated. I also tried LittleFS with the same result. Unfortunally I cant find the library on my folders to take a look into it.
I don't get it, why this function is not available.
May anyone have an idea to solve the problem?
Thanks a lot.
the comment from Juraj helps me to solve the problem:
FSInfo fs_info;
SPIFFS.info(fs_info);
long usedBytes = fs_info.usedBytes;
long totalBytes = fs_info.totalBytes;
Thanks for the help.
Related
I'm using MPLAB X (3.26) with a PIC32 on windows (XC32 v1.40 compiler). I'm trying to use splint to do static code analysis on someones code as part of a review. I've got most of the compiler defines and search paths sorted, but are a bit stumped when it comes to avoiding the parse errors in the PIC32 std include files.
The command I am using to run splint is
splint ^
-D"__32MX370F512L__" ^
-D"__PIC32_FEATURE_SET__"=370 ^
-D"__LANGUAGE_C__" ^
+I"C:/Program Files (x86)/Microchip/xc32/v1.40/pic32mx/include/" ^
main.c
The output then gives
< Location unknown >: Field name reused:
Code cannot be parsed. For help on parse errors, see splint -help
parseerrors. (Use -syntax to inhibit warning)
< Location unknown >: Previous use of
< Location unknown >: Previous use of
.... approx 100 times then...
C:\Program Files (x86)\Microchip\xc32\v1.40\pic32mx\include\\stddef.h(4,18):
Datatype ptrdiff_t declared with inconsistent type: long int
A function, variable or constant is redefined with a different type. (Use
-incondefs to inhibit warning)
load file standard.lcd: Specification of ptrdiff_t: arbitrary integral type
C:\Program Files (x86)\Microchip\xc32\v1.40\pic32mx\include\\stddef.h(5,27):
Datatype size_t declared with inconsistent type: unsigned long int
load file standard.lcd: Specification of size_t:
arbitrary unsigned integral type
C:\Program Files (x86)\Microchip\xc32\v1.40\pic32mx\include\\stddef.h(6,13):
Datatype wchar_t declared with inconsistent type: int
load file standard.lcd: Specification of wchar_t: arbitrary integral type
C:\Program Files (x86)\Microchip\xc32\v1.40\pic32mx\include\\stdarg.h(75,36):
No type before declaration name (implicit int type): __builtin_va_list :
int
A variable declaration has no explicit type. The type is implicitly int.
(Use -imptype to inhibit warning)
C:\Program Files (x86)\Microchip\xc32\v1.40\pic32mx\include\\stdarg.h(75,36):
Parse Error: Suspect missing struct or union keyword: __builtin_va_list :
int. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
The last one causes things to stop. I've tried things like -skip-iso-headers with no luck. It seems it is seeing issues with its standard.lcd file and the xc32 std files
Can anyone tell me
What the < Location unknown >: Field name reused: means or possibly is referring to?
A way to resolve the parse error due to the std header files?
So far only way to solve the header file issue is to define the types, e.g.
-D"__builtin_va_list"=int ^
I think your code (or some code that you #include) is using anonymous bitfields or/and structs. Anonymous structs and anonymous unions are provided by a GNU extension for versions of C earlier than C11. Since Splint doesn't know about C11 (I only found mentions of C99 in the manual, and google agrees) and only partial support for the GNU extensions (search for gnu-extensions), it has a hard time parsing them.
I had a similar problem with some code written for a PIC18f46k22, though I was using sdcc instead of XC8.
The issue was with pic18f46k22.h, which had anonymous structs (bitfields, specifically) inside a typedef union.
This code...
typedef union
{
struct
{
unsigned name0 : 1;
unsigned name1 : 1;
unsigned name2 : 1;
unsigned name3 : 1;
unsigned name4 : 1;
unsigned : 1;
unsigned : 1;
unsigned : 1;
};
struct
{
unsigned name : 6;
unsigned : 2;
};
} __NAMEbits_t;
...would produce these errors...
< Location unknown >: Field name reused:
Code cannot be parsed. For help on parse errors, see splint -help
parseerrors. (Use -syntax to inhibit warning)
< Location unknown >: Previous use of
...but this code wouldn't.
struct indv
{
unsigned name0 : 1;
unsigned name1 : 1;
unsigned name2 : 1;
unsigned name3 : 1;
unsigned name4 : 1;
unsigned : 1;
unsigned : 1;
unsigned : 1;
};
struct all
{
unsigned name : 6;
unsigned : 2;
};
typedef union
{
struct indv individualbits;
struct all allbits;
} __NAMEbits_t;
I am working with a different processor, compiler, and static analysis tool (PRQA / Helix QAC), but I think we are facing the same problem regarding the parse issue of the standard header files. It took me some time to figure out what is going on.
For one thing, I can say that your workaround is good enough and apparently you should not worry about it too much. I used a slightly different workaround described here:
Pycparser not working on preprocessed code
-D __builtin_va_list = struct __builtin_va_list {}
I guess another way would be to use stub standard headers instead of the real ones. My tool manual claims, for example, that there should be such header files supplied with the tool, although I haven't found/obtained them yet.
Here a snippet of generated .c code from .Lex.
And the Coredump is coming at the very first Iteration
while (1) /* loops until end-of-file is reached */{
yy_cp = yy_c_buf_p;
/* Support of yytext. */
*yy_cp = yy_hold_char; // receiving coredump here
/* yy_bp points to the position in yy_ch_buf of the start of
* the current run.*/
yy_bp = yy_cp;
yy_current_state = yy_start;}
Here you can find code
I have answer of my own question. Here are some explanation of Solution
I have two .Lex (Type1_Lex.l & Type2_Lex.l)and two .Yacc (Type1_Yacc.y & Type2_Yacc.y) code
I am compiling all and relevant .c (Type1_Lex.c, Type2_Lex.c, Type1_Yacc.c & Type2_Yacc.v) and .h files are getting generated
And further compilation of .c with generates Type1_Lex.o, Type2_Lex.o, Type1_Yacc.o Type2_Yacc.o
Further I am putting all these object files in a single .a
The Problems are Here
...
ld: Warning: size of symbol `yy_create_buffer' changed from 318 in libuperbe.a(TYPE1_Lex.o) to 208 in libxxx.a (TYPE2_Lex.o)
ld: Warning: size of symbol `yy_load_buffer_state' changed from 262 in libuperbe.a(TYPE1_Lex.o) to 146 in libxxx.a(TYPE2_Lex.o)
ld: Warning: size of symbol `yy_init_buffer' changed from 278 in libuperbe.a(TYPE1_Lex.o) to 164 in libxxx.a(TYPE2_Lex.o)
Some symbols are same in both generated .c (TYPE1_Lex.c & TYPE2_Lex.c)
When both object file bind in a single .a the similar
(yy_create_buffer,yy_init_buffer,yy_load_buffer_state) symbols got
overridden.
At the runtime when the methods yy_create_buffer(),yy_init_buffer(), yy_load_buffer_state() should be called defined in TYPE2_Lex.c but in actual those methods are called from the file TYPE1_Lex.c and the leads to the memory corruption some how.
For moving ahead I decided to use sed with following patterns :
Sed TYPE2_Lex.c with :
s/yy_create_buffer()/TYPE1_create_buffer/g
s/yy_init_buffer()/TYPE1_init_buffer/g
s/yy_load_buffer_state()/TYPE1_load_buffer_state/g
Sed TYPE2_Lex.c with
s/yy_create_buffer()/TYPE2_create_buffer/g
s/yy_init_buffer()/TYPE2_init_buffer/g
s/yy_load_buffer_state()/TYPE2_load_buffer_state/g
So that the Loader can easily differentiate the symbol. And at the run time confusion between the methods name become null.
After all these Step I am able to move ahead :)
Thanks all for your help :)
The stammen/angleproject here: https://github.com/stammen contains some samples to allow testing of the OpenGL/ES 'bridge' to directx. I've tried compiling (both VS2012 and VS2013 sln files with VS2013 Ultimate) and find that I get the following error:
Asteroids.cpp ln 113: error C2039: 'window' : is not a member of 'Microsoft::WRL::ComPtr'
The line in question is:
m_esContext.hWnd.window = CoreWindow::GetForCurrentThread();
I've tried replacing the line with:
auto w = CoreWindow::GetForCurrentThread();
Microsoft::WRL::ComPtr<ICoreWindowInterop> interop;
reinterpret_cast<IUnknown *>(w)->QueryInterface(interop.GetAddressOf());
HWND hWnd = NULL;
interop->get_WindowHandle(&hWnd);
m_esContext.hWnd = hWnd;
...which gives me the following error in client.h at compilation:
cannot convert from 'HWND__ *' to 'IUnknown *'
Any ideas anyone? Stammen, if you're out there... help... please! :)
I am new to static checking and I am assigned a task to do static checking of C code. I am given the liberty to select any one tool keeping in mind that the organisation already uses lint so a lint based tool should be preferred.
I selected splint because it is a free software. (PC lint and Lint being commercial)
Now I tried compiling a simple C file which had #include <unistd.h>
Splint shows error:
/usr/include/unistd.h:221:26: Parse Error:
Suspect missing struct or union keyword: __ssize_t :
int. (For help on parse errors, see splint -help parseerrors.)
Cannot continue.
How can I get this working?
I read in some places that splint doesn't support C99 standard whereas some says it supports. Can anyone tell me whether I should reconsider my choice as I will be using C99 format. What are the other free alternatives which are very similar to lint/splint?
When I implement the XAudio2Sound3D sample from the June 2010 SDK.I pretty much copied it all in my own framework and this one variable(sound3DInstance) shows up as an unresolved external: X3DAudioCalculate(sound3DInstance, &listener, &emitter, calcFlags, &dspSettings); and X3DAudioInitialize(details.OutputFormat.dwChannelMask, SPEEDOFSOUND, sound3DInstance);
Where the variable types are:
X3DAUDIO_HANDLE sound3DInstance;
X3DAUDIO_LISTENER listener;
X3DAUDIO_EMITTER emitter;
X3DAUDIO_DSP_SETTINGS dspSettings;
DWORD calcFlags = X3DAUDIO_CALCULATE_MATRIX | X3DAUDIO_CALCULATE_DOPPLER | X3DAUDIO_CALCULATE_LPF_DIRECT | X3DAUDIO_CALCULATE_LPF_REVERB | X3DAUDIO_CALCULATE_REVERB;
const float SPEEDOFSOUND = X3DAUDIO_SPEED_OF_SOUND;
XAUDIO2_DEVICE_DETAILS details;
Now the only common variable in both functions that show the error is sound3DInstance,so that has to be the problem.In the SDK Sample all the variables are put in a struct called *AUDIO_STATE* and in the initialization of the program,they call:
*ZeroMemory( &g_audioState, sizeof( AUDIO_STATE ) );*
In my code the variables are members of my Sound class and I just ZeroMemory them one by one,so shouldn't the effect be the same?
You're not linking your program against the XAudio library (Xaudio2.lib). Check the linker settings for your project.