I've been using the local Arduino IDE for years and figured I'd try to Cloud compiler.
I have a sketch for the MKR1000 that uses several libraries including two small nonstandard ones and I've been able to move the sketch to the Cloud editor, load my custom libraries (easy) and get a good compile for the MKR1000.
Part of this exercise is that I'm thinking of porting to either the Arduino Nano RP2040 Connect or the Arduino Nano ESP32. I know I may need to change some pins around, but that's not my issue at this pint.
I changed the target processor to Arduino Nano ESP32 and get the following error when compiling:
/home/builder/Arduino/libraries/esp32_control_1_2_8/src/ESP32Monitor.cpp:2:10: fatal error: AsyncElegantOTA.h: No such file or directory
#include <AsyncElegantOTA.h>
^~~~~~~~~~~~~~~~~~~
I do not have this #include in my code, and I didn't select anything for OTA updates (nor do I see an option).
If I try to compile for the Arduino Nano RP2040 Connect and get the following error:
In file included from /home/builder/Arduino/libraries/elegantota_3_1_5/src/ElegantOTA.cpp:1:0:
/home/builder/Arduino/libraries/elegantota_3_1_5/src/ElegantOTA.h:23:10: fatal error: stdlib_noniso.h: No such file or directory
#include "stdlib_noniso.h"
^~~~~~~~~~~~~~~~~
I didn't include this nor do I know where it came from.
I kind of expected some changes might be needed to my code, but these errors don't appear to have anything to do with my code.
Hi @IraSch. I'm going to ask you to provide the full verbose output from a compilation.
This procedure is not intended to solve the problem. The purpose is to gather more information.
Please do this:
Open your sketch in Arduino Cloud Editor.
Click the "Settings" icon at the bottom left corner of the page:
The "Settings" panel will open.
Select the "Verbose output" radio button under the "Console verbosity" section of the "Settings" panel.
Click the ✓ button in the Cloud Editor toolbar.
Wait for the compilation to fail.
If the black "Console" panel at the bottom of the Cloud Editor page is minimized, click the ˄ icon at the right side of the "Console" toolbar to expand it.
Click the icon in the top right corner of the black "Console" panel at the bottom of the Cloud Editor page that looks like two pieces of paper ("Copy Console Output"):
Open a forum reply here by clicking the "Reply" button.
Click the <CODE/> icon on the post composer toolbar.
This will add the forum's code block markup (```) to your reply to make sure the error messages are correctly formatted.
Press the Ctrl+V keyboard shortcut (Command+V for macOS users).
This will paste the compilation output into the code block.
Move the cursor outside of the code block markup before you add any additional text to your reply.
Click the "Reply" button to post the output.
In case the output is longer than the forum software will allow to be added to a post, you can instead save it to a .txt file and then attach that file to a reply here.
Open a forum reply here by clicking the "Reply" button.
Click the "Upload" icon () on the post composer toolbar:
The "Open" dialog will open.
Select the .txt file you saved from the "Open" dialog.
Click the "Open" button.
The dialog will close.
Click the "Reply" button to publish the post.
Alternatively, instead of using the "Upload" icon on the post composer toolbar as described in steps (5) - (7) above, you can simply drag and drop the .txt file onto the post composer field to attach it.
Attached are the verbose compiler results for both the Nano ESP32 and Nano RP2040 Connect.
Side note: I am just trying to get clean compiles, so I used Select Device Type - there is no Nano connected in either case. I also haven't created a Thing or configured either device. Hopefully I can see what it will take to get a clean compile before going that far.
Also, if I switch back to Arduino MKR1000 I now get an error that I didn't get prior to selecting either of the other two devices:
In file included from /home/builder/Arduino/libraries/elegantota_3_1_5/src/ElegantOTA.cpp:1:0:
/home/builder/Arduino/libraries/elegantota_3_1_5/src/ElegantOTA.h:23:10: fatal error: stdlib_noniso.h: No such file or directory
#include "stdlib_noniso.h"
^~~~~~~~~~~~~~~~~
Apparently #include <elop.h> was added. Deleting that allowed the MKR1000 compile to go cleanly again.
OK, I think I see the cause of the unexpected "AsyncElegantOTA.h: No such file or directory" error here:
Multiple libraries were found for "TimeLib.h"
Used: /home/builder/opt/libraries/esp32_control_1_2_8
Not used: /home/builder/opt/libraries/dfrobot_oled12864_1_0_0
Not used: /home/builder/opt/libraries/time_1_6_1
Every one of the thousands of libraries in the Arduino Library Manager are pre-installed in Arduino Cloud.
This is very convenient because it means you don't need to worry about installing or updating the libraries. However, it can sometimes cause issues. The problem is that, for any common filename used in an #include directive in your sketch program, there may be multiple libraries that contain a file of that name. When this occurs, Arduino Cloud attempts to automatically pick the best library to use when compiling your sketch. It is pretty smart about this, but unfortunately doesn't always make the right choice.
This is a case where Arduino Cloud picked a different library than the one your sketch was meant to use.
I'll provide instructions you can follow to configure the library that should be used when compiling your sketch in Arduino Cloud:
Click the following link to open the list of your Arduino Cloud sketches in the web browser: https://app.arduino.cc/sketches
Select the sketch for which you want to configure the library to be used.
The sketch will open in Arduino Cloud Editor.
Click the icon that looks like shelved books ("Libraries") in the bar on the left side of the Cloud Editor page.
The "Libraries" panel will open.
Type time in the "Search libraries" field near the top of the panel.
Scroll down through the list of libraries until you find the entry for the "Time" library.
You will see a dropdown menu in the library's entry. Click on it.
The menu will open.
Select the version of the library you want the sketch to use from the menu. You must select a menu item other than the "Latest (...)" item at the top of the menu.
The menu will close.
Click the "INCLUDE" button in the "Time" library entry. ⓘ Clicking this button configures the sketch to use the "Time" library, at the specific version selected from the menu.
A "Library already included" notification will appear. This is expected and doesn't indicate any problem.
Now try compiling the sketch again. This time the expected library should be used.
Note that the library configuration achieved via the above procedure was specific to the sketch you had open in Arduino Cloud Editor. If you want to make the same configuration for another sketch, open it in Cloud Editor and repeat the procedure.
The above procedure configured the sketch to always use the version you selected from the menu. Important enhancements or bug fixes might be made to the library in future releases of the library, so it is a good idea to periodically check for the availability of newer versions. You can repeat the procedure above to configure the sketch to use a different version of the library.
Please let me know if you have any questions or problems while following those instructions.
I was able to get the Nano RP2040 Connect version to compile cleanly (had to change to a different TFT display library but that's unrelated).
Still working on the Nano ESP32 version.
One thing that still confuses me [just one? - hard to believe...] When there is a compile error, I get warnings about multiple matching libraries as you referenced. However, as part of my selecting each library, the selection offered different versions and I took the default latest version each time I clicked INCLUDE. So why would I still get a warning? Or should I explicitly select a version each time even if I use the Latest?
This isn't a warning. It is only a helpful informational message. You will always see these messages in the verbose compilation output when multiple libraries are installed that contain a header file matching an #include directive in the sketch program.
When you see that the expected library was used, you can safely disregard the message. It is only when you notice that a different library than intended was used (as happened for you with the TimeLib.h header) that you need to take action.
When you encounter the problem of the sketch build system having chosen the wrong library, this is a convenient way to force it to use the correct library.
But in the case where the correct library is already being chosen by the sketch build system, the choice of whether or not to use the feature is entirely up to you.
The actual purpose of the feature is version pinning the library dependencies of the sketch.
By default, Arduino Cloud will always use the latest version of a library dependency when you compile your sketch. This is convenient because it means you will always be using the latest and greatest version of each library, with all bug fixes and enhancements from the library developers. However, it can also lead to unexpected breakage of your project. Imagine this scenario: You have your project working 100% perfectly, then you make an innocuous change to the sketch code and try to upload it to your board. All of a sudden, the compilation fails with a strange error, or the sketch uploads but the runtime behavior of the project is wrong. But you know the change you made to the code could not be the cause, and even after you revert your change the problem persists. After much tearing out of your hair, you finally discover that the author of one of the sketch's library dependencies recently released a version 2.0.0 of the library, whereas the previous version 1.2.3 was used at the time you uploaded the sketch the last time the project was working. The new version of the library either has a bug or else it has an intentional breaking change (in order to progress with the development, library authors sometimes decide to change the library API in ways that cause code that worked with the previous API to stop working), and it was Arduino Cloud's automatic update of the library that broke your project! Keep in mind that Arduino library authors can release a new version at any time, so Arduino Cloud might use a different version of a given library dependency from one minute to another.
This is why developers often prefer to do what is called "version pinning" with the dependencies of their project (this practice applies to any software project; not Arduino projects alone). "Pinning" a version means configuring the dependency management system of a project to use a specific version of a dependency. Version pinning the project dependencies provides a stable dependencies environment free from unexpected changes. The downside to pinning your dependency versions is that it means you might end up using an older version of a library that is missing important enhancements or bug fixes that are present in a newer version of the library. So you incur the burden of periodically manually updating each of the dependencies. But you have control over if and when you perform those updates. You can carefully evaluate the new version of the library at the time you update.
This will be solved by following the instructions I provided in post #4. I can tell from looking at the verbose output you provided that you did not correctly follow the instructions. Please try following those instructions again, being very careful to follow them exactly.
At step (8), it is essential that you do not select the "Latest (1.6.1)" item from the menu. You must instead select the "1.6.1" item:
I did follow your instructions and selected version 1.4.0, but I do see where I went wrong.
The library manager only has a Time library, but when selected, it generates an Include for TimeLib.h not Time.h. I manually changed the Include to Time.h and I now get past the OTA problem. Note that there is no library entry for TimeLib, so I can't manually select a version on that.
I'm now able to get a somewhat clean compile, and it generates code. But I do get the following as part of the compiler output. Since it does appear to generate code, I'm not sure if this is an error or warning. I may try to find a different FT6336U library for the Nano ESP32 and see if that helps.
In file included from /mnt/create-efs/webide/96/ab/96abf2e47368fe4b461dc70b0f4ddb93:IraSch/libraries_v2/RAK14014-FT6336U/src/RAK14014_FT6336U.h:13,
from /mnt/create-efs/webide/96/ab/96abf2e47368fe4b461dc70b0f4ddb93:IraSch/libraries_v2/RAK14014-FT6336U/src/RAK14014_FT6336U.cpp:9:
/home/builder/.arduino15/packages/arduino/hardware/esp32/2.0.13/libraries/Wire/src/Wire.h: In member function 'uint8_t FT6336U::readByte(uint8_t)':
/home/builder/.arduino15/packages/arduino/hardware/esp32/2.0.13/libraries/Wire/src/Wire.h:127:13: note: candidate 1: 'uint8_t TwoWire::requestFrom(int, int)'
uint8_t requestFrom(int address, int size);
^~~~~~~~~~~
/home/builder/.arduino15/packages/arduino/hardware/esp32/2.0.13/libraries/Wire/src/Wire.h:125:13: note: candidate 2: 'uint8_t TwoWire::requestFrom(uint8_t, uint8_t)'
uint8_t requestFrom(uint8_t address, uint8_t size);
^~~~~~~~~~~
I see there is a bug in Arduino Cloud Editor. It should have added an #include directive for Time.h when you have version 1.4.0 selected from the menu instead of adding an #include directive for TimeLib.h.
Version 1.4.0 of the library did not have a header file named TimeLib.h:
The file was added in version 1.5.0:
Cloud Editor must have used the data from the latest version of the library when determining which #include directive to add, instead of getting the data for the specific version you selected from the menu.
I have reported this bug to the Arduino Cloud developers.
Was there a specific reason you chose to use version 1.4.0 of the Time library? That version is very old.
Yeah, that is very confusing. It is a warning, but the first part of the text is missing. The full warning would look like this (I compiled the library using Arduino IDE so that I could get it):
c:\Users\per\Documents\Arduino\libraries\RAK14014-FT6336U\src\RAK14014_FT6336U.cpp: In member function 'uint8_t FT6336U::readByte(uint8_t)':
c:\Users\per\Documents\Arduino\libraries\RAK14014-FT6336U\src\RAK14014_FT6336U.cpp:307:58: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
rdDataCount = _i2cPort->requestFrom(_deviceAddress, 1);
^
In file included from c:\Users\per\Documents\Arduino\libraries\RAK14014-FT6336U\src\RAK14014_FT6336U.h:13,
from c:\Users\per\Documents\Arduino\libraries\RAK14014-FT6336U\src\RAK14014_FT6336U.cpp:9:
C:\Users\per\AppData\Local\Arduino15\packages\arduino\hardware\esp32\2.0.13\libraries\Wire\src/Wire.h:127:13: note: candidate 1: 'uint8_t TwoWire::requestFrom(int, int)'
uint8_t requestFrom(int address, int size);
^~~~~~~~~~~
C:\Users\per\AppData\Local\Arduino15\packages\arduino\hardware\esp32\2.0.13\libraries\Wire\src/Wire.h:125:13: note: candidate 2: 'uint8_t TwoWire::requestFrom(uint8_t, uint8_t)'
uint8_t requestFrom(uint8_t address, uint8_t size);
^~~~~~~~~~~
I think the warning is innocuous. So you can safely ignore it. As you noticed, the sketch did compile successfully.
Cloud Editor actually suppresses all compiler warnings so the fact that even a fragment of a warning is shown in the output is a bug. I'm not sure how this bit of the warning managed to slip through.
This procedure is not intended to solve the problem. The purpose is to gather more information.
) on the post composer toolbar:
