Add PlatformIO.md

[brunob45]

Many thanks to @MCUdude for the template.

Adapted from https://github.com/MCUdude/MegaCoreX/blob/master/PlatformIO.md, this may help with #319.

The bootloader sections will need platformio/platform-atmelmegaavr#48 to be pulled before being effective.

[SpenceKonde]

Does anyone else understand this well enough to give a green light here?

[matou78]

the doc looks good, but need to see if/when the avrdude is updated to v7 in platformio to change the "### upload_protocol" section
The only protocol i was able to use is the upload_protocol = serialupdi coming with avrdue 7.0

[SpenceKonde]

Well, even when the avrdude is updated to 7.0, the core will still use the tool SerialUPDI, not avrdude with the SerialUPDI protocol. I am aware that some changes will be necessary for EA and definitely for other future chips. Using AVRdude would make me dependent on getting them to accept my change and generate binaries. No thanks!

I don't know how this bears on platform IO. however.

But this is my core objection to avrdude - it is for everyone who is not an expert on the dark art of cross compilation, "read only open source". That is, I can find an issue, know what needs to be changed, but be unable to generate corrected files to distribute. Because AVRdude is written in C, and arduino supports 7 different platforms. I am lucky if I can get a toolchain to build something on it's native platform to work, as there are always bizzare dependency problems that need to be sorted out. And it is work I have always detested. That means if a new part comes out, and there needed to be additions to the serial UPDI protocol (which will need to be done for EA, and again for DU (if that ever happens) as far as I can tell from the limited information available), I can fix them in C or python, the protocol itself is not obtuse. But with SerialUPDI then I'm done, I commit the fixed python file, release the core, and it works.

If I rely on AVRdude - well - they may be responsive now, but for the entire time I have been in this hobby until this year, it has been impossible to get a change into avrdude and get the binaries compiled so you can distribute it, Every time I've relied on a tool controlled by someone else, I have been burned. That's why I generate my own compiler toolchain packages - I got sick of having to suck dick to get arduino to rebuild it and make binaries available. The fact that I was in hock to El Tangas when working with jtag2updi is what made it such a traumatic experience for me that I had to stop working with modern AVRs for a couple of months to get over it. I am not going to step in the dog shit a third time and put myself in a position where I am dependent on an externally maintained tool to provide basic functionality.

AVRdude7 may be eventually used, but SerialUPDI program will be used for the upload tool. Avrdude in serialupdi protocol will happen over my dead body. I'm not making that mistake a third time - not for Arduino at least. I don't know enough about platformIO to know whether this can be changed there without impacting other IDEs..

And why is only serialupdi protocol working? Shouldn't jtag2updi and a jtag2updi programmer work???

[matou78]

i understand you , platformio is a little a special case, there is so many different frameworks inside it's mind blowing .
when i started with platformio + AVRXXD chips , i wasn't able to upload shit to them until the merge happened x)
never really tried with the jtag2updi protocol as i knew fuckall at the beginning, and reading your docs here i believed the only way was the updi protocol so i went into it

In arduinoIDE everything was working but for my larger programs i needed something like platformIO as it saves me a lot of time when making the programs ( workspaces,easy multi files,copies of libraries per project with different versions, ect)

So i put in some time and the first time i was able to do anything it was by updating the avrdude inside of the master forled related to arduino framework .

When i have time, hope soon, i will test the modifications proposed by brunob45 in real conditions . If this works, it will be beautiful

[MCUdude]

@SpenceKonde Cross compiling Avrdude is trivial now that they're using Cmake. And the Arduino developers have also created a modified build script to statically link as many external libraries as possible, in order to provide Avrdude binaries with little to no external dependencies.

I do agree that the Avrdude project was a pain to work with when it was hosted on nongnu where nobody really cared. I reported a bug there back in 2015 that I later figured out that was a very simple fix, but I never even got a reply. I ended up fixing this issue when it was moved to Github. Now issues are responded to and sometimes resolved within hours, and there are several skilled developers that now know the code base well. I'm confident that things have changed permanently, and this is not just a "flash in the pan". Six (or more?) developers have write access to the repo, which means that we no longer rely on one person's spare time to get your PR merged. The ancient code base has become dramatically better, and tons of bugs have been removed since Avrdude 6.3.

Avrdude 7.1 (or 8.0, not sure) will be released by the end of this year, and I hope that we can make sure this version works with all Dx and Ex series, both using UPDI and Optiboot. It would be in everyone's interest to have an up-to-date Avrdude version that works with all the latest chips and protocols, even if you don't want to rely on it. @SpenceKonde there seems to be an issue with Optiboot Dx on the AVR-DD series. Have you looked into this yet?

[SpenceKonde]

You see, I don't even know what cmake is. I don't like or find interesting wrangling toolchains,.

Likely won't be possible to know about Ex-series until the parts ship. Who knows when that will be.

I'm trying to get halfduplex serial working so I can release the next megaTinyCore version.

Then I can work on DxCore and get DxCore working to compile for all Dx devices, and get the fixes from megaTinyCore ported, and then verify functionality on DD-series. Until that point, I don't know how anyone could come to the conclusion that optiboot dx does or does not work on the DD-series. You say "there seems to be an issue" but I have heard of no such issue. I know of the issue with avrdude changing the behavior of -c arduino in a way that breaks any Dx-part on devices with 64k+ flash. That is a regression in AVRdude as I understand it, and I was under the impression that it was being worked on from that end. However I have heard nothing about any issue on the DDs specifically nor what methodology was used to determine this in the absence of an arduino core supporting them.

[MCUdude]

Until that point, I don't know how anyone could come to the conclusion that optiboot dx does or does not work on the DD-series. You say "there seems to be an issue" but I have heard of no such issue.

I can provide more details if you're planning to look at this soon. I tested Optiboot on an AVR64DD32, and even though Avrdude can communicate with the target, it can't read and write to flash or EEPROM. Note that I used the optiboot_dx64_ser0_alt_8sec.hex file, and the fuse bits provided for the DD series in boards.txt. The reason for testing was to hopefully figure out if changes to Avrdude are needed in order to support the DD series or not. Even though there's no working Arduino build system for them yet, one can easily test the bootloader functionality by uploading synthetically generated hex files with offsets starting from 0x200. Test files have been generated with srec_cat.

I know of the issue with avrdude changing the behavior of -c arduino in a way that breaks any Dx-part on devices with 64k+ flash. That is a regression in AVRdude as I understand it, and I was under the impression that it was being worked on from that end.

Yes, there was a regression in the upstream development version of Avrdude. Avrdude 7.0 is not affected and works just as well as Avrdude 6.3 for AVR-Dx parts. The reason for the regression was that they wanted to resolve an issue with optiboot + really old AVRs (ATmega8535 and similar), but ended up breaking Optiboot X/Dx support since optiboot behaves a little differently for these parts compared to classic AVRs. The issue has been resolved, and no harm was done. The development version was broken for a few weeks, but that's what to expect from a development branch. What's important is that the issue was reported, and the bug was tracked down and fixed.

[SpenceKonde]

Huh, I'd have expected that to work if fuses were right and the hex file was valid, and the avrdude conf was right.
I didn't think they changed nvmctrl.

Edit: Well, not EEPROM, we never supported that through optiboot on Dx. Not enough flash to fit in 512b.

[SpenceKonde]

Merged