The observations, experiences, and challenges I've faced so far on my PlatformIO journey

Hey all,

I’m fairly new to the party and wanted to make a post about how it’s going so far. I have found PlatformIO to be extremely useful and a great alternative to the somewhat limited official Arduino IDE and tools.
However, I’ve been finding myself troubleshooting PatformIO more often than actually working on learning C++ or building a project.

The purpose of this post is to list the things I’ve observed in the hopes that it promotes healthy discussion that results in a better platform in the end. I also need help separating what is expected behavior, what is actually a bug, what is simply an oversight and/or lack of documentation etc, and what is ignorance on my part.

Toolchains appear to be incomplete across host architectures and platforms.

  • There is no suitable version of “toolchain-gccarmnoneeabi” for architecture ‘linux_aarch64’ for both “ststm32” and “atmelsam” in PlatformIO 4.3.4, making compiling for those platforms on ‘linux_aarch64’ not possible.
PlatformManager: Installing ststm32
ststm32 @ 6.1.0 is already installed
PackageManager: Installing toolchain-gccarmnoneeabi @ >=1.60301.0,<1.80000.0
Error: Could not find a version that satisfies the requirement '>=1.60301.0,<1.80000.0' for your system 'linux_aarch64'
----------------------------------------------------------------------------------------------------------
PlatformManager: Installing atmelsam
atmelsam @ 4.4.0 is already installed
PackageManager: Installing toolchain-gccarmnoneeabi @ ~1.70201.0
Error: Could not find a version that satisfies the requirement '~1.70201.0' for your system 'linux_aarch64'
  • The “armv7l” architecture does not have this issue and there is an acceptable version of “toolchain-gccarmnoneeabi” available.

The Remote Agent on “armv7l” replaces “contrib-pysite” with version “2.37.0” even if “pio update” has updated to it to version “2.37.191020”.

  • Running “pio update” re-downloads “2.37.191020” and breaks the Remote Agent. Running “pio remote agent start” results in it’s attempt to check all it’s dependencies. This results in either version “2.37.0” of “contrib-pysite” being reinstalled or a stack trace. It’s really a roll of the dice.
  • On “aarch64”, Remote Agent appears to start fine without trying to replace “contrib-pysite” and seems to be happy with version “2.37.191020” for reasons unknown.
    This behavior was observed on multiple “armv7l” boxes even after a complete PlatformIO reinstall and all with Python 3.7. (It is interesting to note that Python 2.7 is present on the “aarch64” system, but adding Python 2.7 to one of the “armv7l” systems didn’t change the behavior.)

Specifying any of the STM32F1x boards in “platform.ini” that call for the Maple Core, downloads “tool-stm32duino” version “1.0.1” (on Arm Linux and OSX).

  • This provides and outdated and unreliable “maple_upload” script. (Basically 750ms is not long enough for slower ARM boxes. The wait value needs to be 1500ms to 3000ms to work reliably) Here is the line from the script that needs to be changed:
"${DIR}/upload-reset" ${dummy_port_fullpath} 3000

Some Library dependencies should probably not be be dependencies default.

  • This is a fun one.
  • Adafruit has a library called “RTClib”. It, itself, works great. However for whatever reason, Adafruit has marked “TinyWireM” as a dependency of “RTClib”, despite “TinyWireM” appearing to only be for ATtiny based boards.
  • It’s presence causes compile failures with AVR and STM32.
  • The default behavior of LDF is to pull in “TinyWireM” whenever “RTClib” is installed or upgraded due to “#include <TinyWireM.h>” being present in “RTClib.cpp”.
  • While I understand that one possible solution is to use either lib_ignore=TinyWireM or lib_ldf_mode = chain+ in the platformio.ini as suggested by one of the links before, this is not a “fix”, this is a “workaround”. This issue has caused confusion multiple times and may be frustrating to new users who are expecting “popular” Libraries to function “out of the box”.
  • My understanding is that the “library.json” is for library developers to configure the library. Is it possible to have a mechanism that only pulls in “TinyWireM” when an ATtiny board is selected?
    Here are some of the links, (including mine that shows compile failures)
    Compiling problem on platformio on arduino compiling done adafruit / TinyWireM
    Library "TinyWireM" which is a dependency of Adafruit "RTClib" causes compile failure, unless "lib_ignore = TinyWireM" is added to "platformio.ini" · Issue #3543 · platformio/platformio-core · GitHub

I’ve found the “Remote Agent” to be very neat. Is there any development on something similar that is LAN only for us security minded (paranoid?) folks? (A “local agent” as it were?)

  • I’ve seen a few forum posts where folks don’t have reliable internet connection or are in a isolated environment that could benefit from from the “compile here, upload over there” type work flow. I understand that this can scripted, (aka “pio run” → rsync compiled files to remote box → use “avrdude” etc on remote box to upload) but not everyone has the means to do that efficiently.
  • It’s possible that an “upload only” target that could find the compiled files (without trying to recompile, if it can’t) that could be kicked off via ssh, would be something that help a lot. (and I’m interested and testing such a thing should that be something that would help development.

So in conclusion, I hope this doesn’t come off as harsh or overly critical. I’ve very often not voiced my experience with products in fear of sounding that way. My hope is that others can take this info to make the product better and/or direct me on what steps to take, wherever it be testing config changes or filing one of these as an “issue” on Github.

Thanks for reading…

EDIT: Fixed spelling; added more details, fixed formatting. etc

2 Likes

Great summary! I hope someone picks up the torch.
This in particular looks like a big issue:

There is no suitable version of “toolchain-gccarmnoneeabi” for architecture ‘linux_aarch64’ for both “ststm32” and “atmelsam” in PlatformIO 4.3.4, making compiling for those platforms on ‘linux_aarch64’ not possible.

1 Like