Question about platform.local.txt

Hello everyone! I want to apologize if this has been already discussed but the only 2 topics I found were these: IDE 1.6.3 platform.local.txt and Platform.txt custom include folders. Unfortunately I couldn't find the answer of my problem.

So here is a brief description of my issue. I was using Arduino 1.8.5 and recently I have experienced a problem with a custom board Olimexino-32U4 (which is based on the Arduino Leonardo board) included within my custom package. The effect was that after uploading a certain sketch, another upload wasn't possible because the bootloader got broken. I assume it is somehow related to the memory usage (although I have used only 37% program memory and 74% dynamic). So I reupload my bootloader and tried to upload the sketch by selecting Arduino Leonardo board this time. It worked flawlessly! No problems with repetative uploads. So I start digging in order to figure out what exactly is the problem. I tried to copy my board definition into the original Arduino package - it worked, then copied Arduino Leonardo variant and board.txt part of the file into my package and it failed.

So I realized the problem wasn't in the variant definition but instead it was the platform.txt file. When I compared my file with the current Arduino one there were plenty of differences because I haven't updated it since I first created the package (that was ~3 years ago). So I decided to just replace it and my board worked perfectly within my package. So far so good! But then the next problem came up. When I tested another boards within this package it turns out I can't compile for one of them (Olimexino-85) for which I used as an example another package (the one of Digistump).

After few more hours of testing I figure out that the thing that fixes my issue with Leonardo based board was the -flto (link-time optimizer) option which is added for "compiler.cpp.flags". But it seems it also requires the value of "compiler.ar.cmd" to be "avr-gcc-ar" instead of "avr-ar" (as it used to be until now). And this is problematic for the Olimexino-85 board. With this change applied to my platform.txt when I try to complie emtpy sketch I got this error:

C:\Users\Stanimir Petev\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\4.8.1-arduino5/bin/avr-gcc-ar: Cannot find plugin 'liblto_plugin-0.dll'

It turns out I have 2 boards within the same package that require different options and flags. So here is my question - is it possible to combine them inside a single package. And is the platform.local.txt the key to achieve that? If so - how can I relate the board to the main (platform.txt) and another one to the local (platform.local.txt). From the second topic I linked at the start I saw that platform.local.txt should be located in the same directory. But I still don't understand how to "attach" board to the file options that are specific for them.

Thanks in advance!
Stan, Olimex

Properties defined in platform.local.txt will override the properties in platform.txt. For example, if you have this in platform.txt:

compiler.ar.cmd=avr-gcc-ar

and this in platform.local.txt:

compiler.ar.cmd=avr-ar

The definition of {compiler.ar.cmd} will be avr-ar. The idea behind platform.local.txt is that it allows the user to easily customize a platform.txt they don't own without actually touching the file (and needing to redo the changes after every update. I don't think it will be of any use for your needs.

I think the real problem here is attempting to use LTO with the old avr-gcc version. If you install your custom hardware package via Boards Manager, you can specify the avr-gcc version dependency in the JSON file:

It's likely that the DigiStump package's JSON file specifies avr-gcc 4.8.1-arduino5 simply because that was the current version of avr-gcc at the time they wrote the file. I don't see any good reason to require that version. avr-gcc 4.9.2-atmel3.5.3-arduino2 was very good. 5.4.0-atmel3.6.1-arduino2 has been causing some rare problems for Windows users:

If the hardware package is manually installed, you are likely just going to use whichever avr-gcc version is already in use for Arduino AVR Boards. The solution that was found to enable that usage while allowing the user to benefit from LTO in the popular MCUdude and ATTinyCore repositories was to add a custom Tools menu in boards.txt which allows LTO to be enabled or disabled. Leaving it disabled by default makes the package as beginner friendly as possible (beginners have no idea what LTO is or which Arduino AVR Boards version they have installed), while allowing more advanced users to easily turn LTO on to save memory. You can see how this was implemented here:

menu.LTO=Compiler LTO
# Compiler link time optimization
328.menu.LTO.Os=Disabled (default)
328.menu.LTO.Os.compiler.c.extra_flags=
328.menu.LTO.Os.compiler.c.elf.extra_flags=
328.menu.LTO.Os.compiler.cpp.extra_flags=
328.menu.LTO.Os.ltoarcmd=avr-ar

328.menu.LTO.Os_flto=Enabled
328.menu.LTO.Os_flto.compiler.c.extra_flags=-Wextra -flto -g
328.menu.LTO.Os_flto.compiler.c.elf.extra_flags=-w -flto -g 
328.menu.LTO.Os_flto.compiler.cpp.extra_flags=-Wextra -flto -g
328.menu.LTO.Os_flto.ltoarcmd=avr-gcc-ar
compiler.ar.cmd={ltoarcmd}

The alternative would be to specify that the package requires Arduino AVR Boards 1.6.12 or newer.

Lol, man! I didn't expect reply so soon! Your answer was faster than my refresh button and more accurate than Legolas' shots while slide down the stairs onto orc's shield in Battle of Helm's deep! :slight_smile:

Thank you very much for your advice. As you suggested the issue wasn't the flags inside platform.txt (and potentially platform.local.txt) as I thought but instead the compiler. I was so focused digging into the package itself (boards and platform) that I forgot to check the json file. I changed the version of the compiler and uploader with the latest and now it works perfect. No issues with the reuploading the sketch on the 32U4 and no problems with compiling and uploading on the ATTiny85.

Thanks a lot for the detailed answer!

Stan, Olimex

Lol, man! I didn't expect reply so soon! Your answer was faster than my refresh button and more accurate than Legolas' shots while slide down the stairs onto orc's shield in Battle of Helm's deep! :slight_smile:

That's how we roll on the Arduino Forum! In fact, there are often multiple people competing to reply with the answer within minutes. I often find that someone has already given the solution before I even get my reply typed out. In this case, the subject matter is a bit more obscure, thus the slower response.

Thanks a lot for the detailed answer!

You're welcome. I'm glad to hear it's working now. Enjoy!
Per