Not an Issue but a question

[mrWheel]

@Spence,

Just found out that your great DxCore is available for PlatformIO!! Fantastic!

Is there a change you will make the megaTinyCore also available (in the near future) for PlatformIO??

Highest Regards!

[SpenceKonde]

DxCore is now available with platformIO? Cool, which version are they giving you guys?

I thought megaTinyCore had been available for plaformIO for ages.

[mrWheel]

Hi Spence,

I totally misread this..!

I was triggered by your "platformio.ini" template in the DxCore repo and just assumed that it uses the DxCore code but in stead it uses the "atmelmegaavr" platform.

And now I found out that f.i. the "ATtiny3216" uses the same "atmelmegaavr" core and is also supported by platformIO!

What I don't understand is what part of the "atmelmegaavr" core is from your hand and what is not ... (and whether I can use your great and extensive documentation)!

(If it is your's) could you place a template "platformio.ini" file in your "megaTinyCore" repo?

For me the good mews is I can program my favourite MPU's with platformIO!

Thanks

[SpenceKonde]

"megaavr" is the idiotic name that arduino picked to refer to all modern AVRs. It's a stupid stupid name, but it has to be used because they set the precedent.

Even though the manufacturer calls anything with atmega in the name "megaAVR", So there are many parts that are megavr by Arduino's definition (this is what I call modern AVRs) that aren't megaavr by Microchip's definition, and the vast majority of "megaavr" devices by the manufacturers definition are classic AVRs not modern ones (except the manufacturer hasn't introduced official terms to refer to the types of parts, though classic/modern is gaining traction.), and hence do not use the megaavr architecture.

What platformio does is w/regards to cores is, the gods of platform IO will periodically update the version of my cores (and other cores) that they include. They cannot be petitioned with prayer or sacrifice - they do this only when and how they see fit. I can sometimes get them to make the safe choice by warning them "Go with the last 2.4.x version until we're a few versions into 2,5,x" or something like that.

(The final patch version of a given minor version is generally more stable than the initial release of a new minor version, though the core will generally have become more stable than the previous final release before the final release of the current minor version)

It is possible (though as I don;'t use platform IO I don't know how) to update the version of the core to the latest one.

I don't know what a platform.ini file is, but if you'll tell me what it should be I'm happy to add it.

[SpenceKonde]

The architectures are simple containers for cores for parts of a given architecture, which can generally use the same libraries because the architecture is very similar. atmelmegaavr or whatever isn;'t a core - DxCore, megaTinyCore, and MegaCoreX are cores (that is, they define their own core implementation of the Arduino API functions), atmelatmegaavr is an architecture. Architecture matters for finding platform.txts and board.txts and libraries that are compatible, but that's it - it's just a name, and used only for those purposes. The platformio atmelmegaavr package appears to be (likely a copy each of) of mTC, DxC, and MCX)

But yeah I', happy to put in more platform.ini I just don;'t know jack shit about what should be in it!

[mrWheel]

Thanks for explaining!

Although I am confused by you stating “you don’t know what a platformio.ini file is” … For a AVR128DB32 project I’m working on I use this example from your repo:

https://github.com/SpenceKonde/DxCore/blob/master/PlatformIO.md

You should definitely investigate time in Visual Code and platformIO. It is, in my opinion, a better IDE than the Arduino IDE. The latter is easy to use for novice users but the preprocessing in combining all code files in to one and than generate prototypes for every function makes you lazy.. but who am I.

I would certainly make a platformio.ini file for you but the whole idea of asking this is that I don’t know how … It should have all the [env] and option types that are applicable and thats where I lack knowledge! A short test reveals that the template in your repo “works” for the UPDI upload env by just changing the board to “ATtiny3216” and upload_protocol “jtag2updi“

[SpenceKonde]

And neither do I :-) someone else made that file for me.

[ieb]

This is what I do. Hope it helps someone and leaves @SpenceKonde free to do more important things ( ;) )

I've been using for about 2 years with no problems taking the most recent fixes. I don't use VSCode as it uses far too much compute and runs incredibly slowly on my ancient hardware. I do use either SublimeText or vi as my IDE.

I don't use the distribution from PlatformIO, but I do use pio to build. I clone this repo, checkout the tag (eg 2.6.8) I want or stay at HEAD.

eg

    cd ~/src
    git clone https://github.com/SpenceKonde/megaTinyCore.git
    git checkout 2.6.8

    mkdir ~/.platformio/packages/framework-arduino-megaavr-megatinycore@2.6.8
    cd ~/.platformio/packages/framework-arduino-megaavr-megatinycore@2.6.8
    ln -s ~/src/megaTinyCore/megaavr/* .
    cat << EOF > package.json
    {
      "name": "framework-arduino-megaavr-megatinycore",
      "version": "2.6.8",
      "description": "Arduino Wiring-based Framework for Microchip tinyAVR 0-series and 1-series chips (megaTinyCore)",
      "keywords": [
        "framework",
        "arduino",
        "microchip",
        "tinyAVR"
      ],
      "repository": {
        "type": "git",
        "url": "https://github.com/SpenceKonde/megaTinyCore"
      }
    }
    EOF

In the platformio.ini file I add the following to select the platform packages.

     platform_packages = 
         platformio/framework-arduino-megaavr-megatinycore@2.6.8

And any uploader flags needed, eg https://github.com/ieb/CanGNSS/blob/main/platformio.ini

[SpenceKonde]

Did you hear a whooshing noise? that was the sound of that going over my head. I literally only know about platform IO: It uses the avr-gcc toolchain when compiling for avr. There is a platform.ini file or files somewhere, and that file is important. The compiler error output is the same as from the Arduino IDE, so at least I can tell people what flag their configuration isn't passing that it should be....

But yeah - I am flat out , so I don't feel like I can spare time learning to use a tool I don't intend to use in order to figure out what to say around snippets and tidbits and what to title the pages and so on so that they make sense to PIO people. (Hell, I don't know if I even can understand tools unless I want to use them for something There's been a pattern in my life that when I am dead set on a task, even if I have only crude tools and little background, I can figure out a way to do that with the tools I have. But if I try to learn to use tools in absense of something that I am directly working towards..... I don't usually retain much).

And in any event, while I know it's popular, and I'm sure there's a reason, as a core author - I despise PIO because it doesn't emulate the menu functionality of the IDE - but without the menu functionality , you need to somewhere have a file full of preprocessor directives to #error the compilation whenever they're failing to pass things that the menus would ensure that they passed, or passing options that are impossible to have coexisting - that sort of thing. I don't have that, and as a result, as I understand (like I said. I don't know much of anything about PIO), you can get all manner of invalid combinations of options with undefined behavior.... often without a warning. That "black flag" file, if this isn't clear yet, is very complicated to make, because it needs to consider option in every menu - and in some cases, it's a fuse setting that's being changed, and that's even worse because it can't compile based on the actual fuses, because it doesn't know them at compile time when it has a way to report errors but rather at runtime. So not only can these things that the tools submenus can easily ensure are valid and compatible before even starting to compile, without the submenu's mutual exclusivity, you would need a non-zero overhead runtime test, but there isn't any way to give en error message without making assumptions about what is connected what. So this approach is totally non-viable - it carries an overhead and is unable to do the thing it would be created to do. All I can do is try to recognize when that is happening and quickly answer and close issues about strange compile problems in PIO if they're caused by passing inappropriate combinations of options.