Need improved documentation for Platform IO users

[SpenceKonde]

We are getting tons of questions about this that turn out to be because of
pio and the fact that I can't control what flags PIO passes to the compiler. Surely far more people are impacted.

I think that a single document could be shared between megaTinyCore and DxCore - but needs to be well organized and have a long shelf life, because I don't know enough about PIO to update it.

I think this project would be best handled by first working through it in a Google Doc or something like that instead of a PR with a finished document, so multiple people who have relevant knowledge can contribute.

[MCUdude]

If you have time, the absolute best option would be if you kept the PlatformIO implementation up to date. When you add new flags to your boards.txt, this has to be implemented in the PlatformIO build system as well. It's not difficult, but it has to be done.

... and the fact that I can't control what flags PIO passes to the compiler. Surely far more people are impacted.

Yes, you can! Flags that should always be passed to the compiler are added to the board manifest JSON files (AVR128DA28.json).

Other, user selectable flags that would normally be selected by the settings in the tools menu are added to the projects platformio.ini file using build_flags to add flags, and build_unflags to clear flags that have been set by default. For some reason, each flag has to be on its own line and indented. Here's an example from a commercial project where I've set and cleared a bunch of flags when using MightyCore:

build_flags =
  -std=gnu++11
  -Wall
  -Wextra
  -DSERIAL_TX_BUFFER_SIZE=128
  -DSERIAL_RX_BUFFER_SIZE=128
  -DFIRMWARE_REVISION=\"R5\"
  -lprintf_flt
  -DDEBUG_ENABLE

build_unflags =
  -flto
  -fpermissive
  -std=gnu++17

[SpenceKonde]

Maybe *you* can, but I can't. Because I don't know jack fuckall about pio other than that people keep asking me questions about how to use it and I keep saying I don't know the answers. boards.txt is going to be generated programmatically moving forward. PIO json could be generated at the same time, were I to know more about the format and how to simulate the tools submenus. I realized while doing ATTC 2.0.0 that hand maintaining boards.txt is a fools errand and is doomed to failure (the first step of the process wound up turning up half a dozen bugs at least that had not been noticed, and the new boards.txt is several , and that it must be generated via a script. megaTinyCore will be the first of my cores that gets released with the script generated boards.txt for that core is 6500 lines and a third of a megabyte in size. You cannot maintain something like that by hand.

…

On Fri, Aug 19, 2022 at 3:57 PM Hans ***@***.***> wrote: If you have time, the absolute best option would be if *you* kept the PlatformIO implementation up to date. When you add new flags to your boards.txt, this has to be implemented in the PlatformIO build system as well. It's not difficult, but it has to be done. ... and the fact that I can't control what flags PIO passes to the compiler. Surely far more people are impacted. Yes, you can! Flags that should *always* be passed to the compiler are added to the board manifest JSON files (AVR128DA28.json <https://github.com/platformio/platform-atmelmegaavr/blob/develop/boards/AVR128DA28.json> ). Other, user selectable flags that would normally be selected by the settings in the tools menu are added to the projects platformio.ini file using build_flags to add flags, and build_unflags to clear flags that have been set by default. For some reason, each flag has to be on its own line and indented. Here's an example from a commercial project where I've set and cleared a bunch of flags when using MightyCore: build_flags = -std=gnu++11 -Wall -Wextra -DSERIAL_TX_BUFFER_SIZE=128 -DSERIAL_RX_BUFFER_SIZE=128 -DFIRMWARE_REVISION=\"R5\" -lprintf_flt -DDEBUG_ENABLE build_unflags = -flto -fpermissive -std=gnu++17 — Reply to this email directly, view it on GitHub <#319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEWYKD6FJYS4BZATDNPTVZ7RKLANCNFSM557CGOHQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

--

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support for all post-2016 tinyAVR parts! DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: ***@***.***

[brunob45]

Hi,

7 months ago, I made a script to generate the json boards files for every AVR-Dx variant, based on Atmel's ATpacks.
It was pulled into platformio/platform-atmelmegaavr#35.

If there's a new script to generate the board.txt file, I could add the part to generate the PIO json files as well.
All I would need is the default parameters of the "Tools menu" for each variant.

[mikrocoder]

Hello,

I summarize what I have done for Windows users. This is more complicated compared to an Arduino Nano Every and the MegaCoreX from MCUdude.

1. PlatformIO installed
2. installed current version Python 3.10.6. Set the hook for the path entry.

Until I found matou78's entry, I added the system environment variables for Python. I do not know if this was really necessary.
If necessary restart the computer afterwards so that this is taken over.

Then the current pymcuprog was missing. pyupdi is obsolete and is no longer maintained. pymcuprog is now supported by Microchip.

For this In a windows console (CMD) enter the following.

> pip install pymcuprog
> pip install serial

Then pip wanted to update itself. Here I had to type the complete path exactly as it appears automatically.

Then I created a project for an AVR128DB64. The board with it runs already longer with the Arduino IDE and the DxCore and is programmed by USB and bootloader.

The following entries thanks matou78 written in the platformio.ini.
platformio/platform-atmelmegaavr#41
Clocks by default first with internal 16MHz.

[platformio]
default_envs = Upload_USART

[env]
platform = atmelmegaavr
framework = arduino
board = AVR128DB64

[env:Upload_USART]
build_flags = -DUSING_OPTIBOOT
upload_protocol = arduino
upload_speed = 115200

And the following blink test worked after that. Serial and pin for itself adapt, should be clear. 😉

#include <Arduino.h>

constexpr uint8_t pinLed {PIN_PB4};
constexpr uint16_t onTime {100};
constexpr uint16_t periode {2000};

void setup (void)
{
  Serial2.swap(1);
  Serial2.begin(9600);
  Serial2.println(F("Hallo ich bin dein AVR128DB64.\n"));
  pinMode(pinLed, OUTPUT);
}

void loop (void)
{
  digitalWrite(pinLed, HIGH);
  delay(onTime);
  digitalWrite(pinLed, LOW);
  delay(periode-onTime);
}

Done. 😀
Thanks to MCUdude and matou78.

[brunob45]

Key takeaways:

• The MegaCoreX documentation is a good place to look for information.
• To upload via UPDI, check the available protocols. If none work, fallback to upload_protocol=custom and pymcuprog.
• To upload via Serial, the flag USING_OPTIBOOT has to be set.
  This flag will be enabled by default following Improve DxCore support platformio/platform-atmelmegaavr#48

[SpenceKonde]

It should be possible to make an upload_protocol=custom that will use the prog.py that we supply. It uses the same wiring as pymcuprog does to upload from a serial adapter - except it's about 15-20 times faster, or much more than that using an FTDI adapter with the default 16ms latency timer (though with that configuration, it's still grindingly slow - about 8 times longer than it should be. With pymcuprog and that setting, it's like 8ms per byte, 125b/s, With the latency timer reduced to the minimum 1ms, it should be 1.something k/s IIRC with stock pymcuprog. SerialUPDI does like 20k/s)

[Orthosilicate]

Is there a way I can pull the latest release (1.5.6) into PlatformIO? It appears they are still on 1.4.10, which doesn't support the DD series parts.

[SpenceKonde]

Pretty sure there is.

Of course do I know what it is? absolutely not! I don't know the first thing about applied use of platform IO. I have it somewhere. I have no clue how to juse it to compile anything, never tried.....

[SpenceKonde]

As for why 1.4.10, I vaguely recal encouraging them to use that one because I (correctly) forsaw that 1.5.x would be a shitshow for months. I mean, it wasn't until last week when I became aware that I had broken almost all PWM on 1.5.0, and as well as DAC output from analogWrite.

[brunob45]

Hi @Orthosilicate
I have forked the official PlatformIO package with the updated DxCore version.
You can find an example here: https://github.com/brunob45/dev-AVR-Dx

I'm using the custom platform https://github.com/brunob45/platform-atmelavrdx#dev/dxcore
and the custom framework https://github.com/brunob45/framework-arduino-megaavr-dxcore#platformio

I see that another user opened an issue with Platformio platformio/platform-atmelmegaavr#53.
Usually, they respond quickly and update the official platform.

If this is working for you too, please consider requesting PR platformio/platform-atmelmegaavr#48 be merged in the main branch

[Orthosilicate]

Thanks @brunob45 !

I was able to successfully build an image for the AVR64DD28 using your fork. (After uncommenting the platform packages)
platform_packages = framework-arduino-megaavr-dxcore @ https://github.com/brunob45/framework-arduino-megaavr-dxcore#platformio

@SpenceKonde Thank you so much for supporting these parts, I very much appreciate not having to use Microchip Studio.