Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

The weirdest thing I've been seen in years#1381

ruifig started this conversation inGeneral
Apr 19, 2023· 3 comments· 5 replies
Discussion options

So, I encountered this mind boggling problem with my complex IoT project, but just to make sure I'm not going crazy, I created a minimal sample using (https://github.com/maxgerhardt/platform-raspberrypi#5a533d6b36844183bb72794bc53091206165e921 ), and I'm getting the same problem:
Sharing this here since I'm really running out of ideas on how the heck this is possible.
I have over 20 years experience with C++ (I'm a software engineer) and never seen a problem like this.

Very-very likely not related to Arduino-Pico, but I'm out of ideas, and maybe someone has seen something similar.

Scenario:

Given this simple program:

#include <Arduino.h>#if 0  //#include "FreeRTOS.h"#endifvoid setup() {  Serial.begin(115200);  Serial.print("Hello world!");}void loop() {  Serial.println(millis());  delay(1000);}

It compiles to this:

RAM:   [===       ]  26.4% (used 69244 bytes from 262144 bytes)Flash: [          ]   4.4% (used 92492 bytes from 2093056 bytes)

and it works fine.

Now changing JUST the#if 0 to this:

#if 0  #include "FreeRTOS.h"#endif

It compiles to this:

RAM:   [===       ]  29.5% (used 77416 bytes from 262144 bytes)Flash: [=         ]   5.2% (used 109416 bytes from 2093056 bytes)

And the firmware doesn't work.

  • First, how the heck is something inside a#if 0 affecting my build (the firmware size clearly shows that). Note that there is no other code. I understand that MAYBE this could be pranked by doing a#define 0 1 or something like that, but that this is a minimal sample I created just now.
  • Second, the firmware stops working. I can understand that maybe this could happen if by whatever magic is actually adding "FreeRTOS.h" to my build, maybe "FreeRTOS.h" introduces something that breaks the firmware, but then for the kicks I did this:
#if 0  #error PEEKABOOO  #include "FreeRTOS.h"#endif

And it still builds, clearly showing that#error is not seen.

Anyone has encountered this before? haha

You must be logged in to vote

Replies: 3 comments 5 replies

Comment options

That's the Arduino IDE doing it's thing. It doesn't understand#if so when it scans the INO (to do library dependencies and add prototypes behind the scenes to make the INO a regular CPP file) it automatically links in the FreeRTOS code in the failing case. The rest of the core, however, isn't aware of it and things go weird.

Moral of the story is to use comments not if blocks to remove includes in the main INO. For other .c files, I don't believe the IDE scans then so you can use if blocks there, if you really want.

You must be logged in to vote
4 replies
@ruifig
Comment options

Thanks for insight about how the Arduino IDE figures out dependencies, but some more details:

  • I'm using PlatformIO, not the Arduino IDE
  • This is a main.cpp file, not a INO file, in case it makes a difference to those Arduino IDE shenanigans.
@ruifig
Comment options

Ok, my guess is that PlatformIO still ends up using the Arduino IDE somehow, or uses a similar process to help/suggest dependencies?

@earlephilhower
Comment options

I would imagine so. You can check by looking at the MAP files and seeing if there are FreeRTOS functions present. In any case, it is weird if you're not expecting it!

@ruifig
Comment options

I already checked yesterday through PlatformIO's "Inspect" menu, and the extra size is indeed coming from FreeRTOS symbols, so that's what is happening as you suggested.
This was unexpected to me because I wasn't aware the Arduino IDE (or PlatformIO as it seems) would do such a thing behind the scenes.
Plenty of experience with consoles and desktop (that's what I do), but electronics is just a hobby for me and I'm learning these tools and quirks as I go, reading a minimum of documentation. ;)
Anyway, I guess such approach makes things easier for newcomers to help with dependencies. But for someone who is expecting the code to do what it should and no more, this just gets in the way.

Now that I know this is a thing, there is indeed plenty of of discussions I can find online, such as (arduino/Arduino#1841 ) . 👍

Again, thanks for the help, Earle.

Comment options

And of course, now that I know what's going on, I can see PlatformIO has settings to change this behaviour (https://docs.platformio.org/en/latest/librarymanager/ldf.html#ldf-mode

The default ischain which doesn't evaluate preprocessor conditional syntax.

You must be logged in to vote
1 reply
@maxgerhardt
Comment options

Was about to tell you this. It blindly scans the#include line in the default mode which doesn't respect#if conditions. This routinely throws off people that are using PlatformIO and is subject to improvment in e.g.platformio/platformio-core#3113

Comment options

hey, I just ran into this issue two years later but couldn't find the discussion until I was about to post my own, so I'm going to leave more notes here so hopefully more people stumble across it. the LVGL Arduino library creates a conditional dependency on FreeRTOS that, similarly, automatically links in FreeRTOS even ifLV_USE_OS is set toLV_OS_NONE, and even if you don't includelvgl.h or write a single line of LVGL code, and the fix is the same: switchlib_ldf_mode tochain+ or another mode that is capable of identifying that the conditional dependency doesn't exist.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
General
Labels
None yet
4 participants
@ruifig@earlephilhower@vogon@maxgerhardt
[8]ページ先頭
©2009-2025 Movatter.jp