old iom4809 header file is used ?

Hi,

Foreign language area. :wink:

I have a question about the folder structure of the IDE.

I am working on a sample code with TCB and event system for the Nano Every.
For this I need the bit definition EVSYS_GENERATOR_TCB0_CAPT_gc.

Now there is a problem, the IDE has 3 times the headerfile iom4809.h
When compiling, the old header file is stupidly used.

C:\Arduino IDE Portable\megaAVR0\arduino-1.8.13\hardware\tools\avr\avr\include\avr (current)

C:\Arduino IDE Portable\megaAVR0\arduino-1.8.13\portable\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino5\avr\include\avr (old)

C:\Arduino IDE Portable\megaAVR0\arduino-1.8.13\portable\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7\avr\include\avr (current)

Now I wanted to ask if anyone knows a reason for the last two folders with arduino5 and arduino7?
Is my IDE messed up or does Arduino.cc need to release an update?

Old definitions are

EVSYS_GENERATOR_TCB0_CMP0_gc = (0xA0<<0),  /* Timer/Counter B0 compare 0 */
EVSYS_GENERATOR_TCB1_CMP0_gc = (0xA2<<0),  /* Timer/Counter B1 compare 0 */
EVSYS_GENERATOR_TCB2_CMP0_gc = (0xA4<<0),  /* Timer/Counter B2 compare 0 */
EVSYS_GENERATOR_TCB3_CMP0_gc = (0xA6<<0),  /* Timer/Counter B3 compare 0 */

Current definitions are (corrected by Microchip)

EVSYS_GENERATOR_TCB0_CAPT_gc = (0xA0<<0),  /* Timer/Counter B0 capture */
EVSYS_GENERATOR_TCB1_CAPT_gc = (0xA2<<0),  /* Timer/Counter B1 capture */
EVSYS_GENERATOR_TCB2_CAPT_gc = (0xA4<<0),  /* Timer/Counter B2 capture */
EVSYS_GENERATOR_TCB3_CAPT_gc = (0xA6<<0),  /* Timer/Counter B3 capture */

Edit:
my first inquiry Kennt sich jemand mit der IDE Ordnerstruktur aus? - Deutsch - Arduino Forum

Hi,

I found out where the folders arduino5 and arduino7 come from.

arduino5 is from the original IDE. Has the outdated iom4809.h with it.
arduino7 comes from the added MCUdude package MegaCoreX and has the current iom4809.h with it. Strictly speaking, this is also out of date.

That means Arduino.cc should update the headerfile. Or is that never updated again? If not, everyone has to program workarounds for themselves, which is stupid. Does it make sense to make a request?

Doc_Arduino:
arduino5 is from the original IDE.

This is incorrect. That toolchain was installed as a toolchain dependency of a boards platform you installed via Boards Manager. The toolchain that comes bundled with the Arduino IDE is at C:\Arduino IDE Portable\megaAVR0\arduino-1.8.13\hardware\tools\avr, and as you discovered already its version is 7.3.0-atmel3.6.1-arduino7

Doc_Arduino:
That means Arduino.cc should update the headerfile. Or is that never updated again? If not, everyone has to program workarounds for themselves, which is stupid. Does it make sense to make a request?

Each boards platform can define its versioned toolchain dependencies, as documented here. The Arduino platform system allows for having multiple versions of each tool installed and each platform can use the exact version the author intended. This is a very important capability to support any combination of the hundreds of boards platforms being installed on the same system.

Doc_Arduino:
Or is that never updated again?

Of course the toolchain versions used by Arduino's platforms are updated periodically. You can see the progression here:
https://downloads.arduino.cc/packages/package_index.json
However, updating to new toolchain versions must be done carefully and methodically because obscure bugs or backwards incompatibilities may have been introduced. There are 8 different host architectures that must be built for, signed for, and then thoroughly tested. An experienced developer may badly need the new capabilities of a new release and welcome any challenges that might come with it. But for the average Arduino user, stability and reliability are most important. If you're on your first blink, the last thing you need is to run into a compiler bug. So a tried and true older toolchain version is often given preference over the latest shiny release.


Anyway, I think what you are really asking in a roundabout manner is how you can get MegaCoreX to use avr-gcc 7.3.0-atmel3.6.1-arduino7. As I mentioned above, each board platform can define versioned toolchain dependencies. This can be done in two places:

If a platform does not define a tool version then the Arduino build system just grabs whichever tool of that name that happens to be found first.

MegaCoreX defines the tool versions in the package index:
https://mcudude.github.io/MegaCoreX/package_MCUdude_MegaCoreX_index.json

"toolsDependencies": [
  {
    "packager": "arduino",
    "name": "avr-gcc",
    "version": "7.3.0-atmel3.6.1-arduino7"
  },
  {
    "packager": "arduino",
    "name": "avrdude",
    "version": "6.3.0-arduino18"
  },
  {
    "packager": "arduino",
    "name": "arduinoOTA",
    "version": "1.3.0"
  }
]

You can see that it specifies avr-gcc 7.3.0-atmel3.6.1-arduino7. But this package index is installed via the Arduino Boards Manager. So if you circumvent that by manually installing MegaCoreX, as I suspect you have done, then the only mechanism for specifying the tool versions is the platform configuration. However, MegaCoreX's platform configuration does not specify a tool version:

compiler.path={runtime.tools.avr-gcc.path}/bin/

So all you need to do to get the behavior you desire is to install MegaCoreX via Boards Manager:

Hi,

I know the MCUdude package MegaCoreX longer and closer. I am interested in the standard IDE with installed megaAVR Boards Package. I assume in the Nano Every Forum that you have the megaAVR Boards Package installed. :slight_smile: That's what I mean with original IDE. Not from foreign sources.

If you install the megaAVR Boards package the arduino5 folder is created.
C:\Arduino IDE Portable\megaAVR0\arduino-1.8.13\portable\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino5\

I'm also talking about the headerfile and not the complete toolchain. :wink:

Because of the dependencies and long tests I created a headerfile for forward compatibility

I don't know if beginners are interested at all. Just in case.

Anyone who uses the IDE header file but needs the current defines via the controller manual, can use this to build their own header file for forward compatibility. According to my opinion, these are the most important ones you will need.

/*
  Doc_Arduino - german Arduino Forum
  Programmed and tested with: Arduino IDE 1.8.13
  07.03.2021
  Provides current bit definitions which are missing in the old header file.
  Forward compatible.
*/

#pragma once

#if defined(ARDUINO_AVR_NANO_EVERY) && defined(__AVR_ATmega4809__)
    // Event System //
    // Zeile 816
    #ifndef EVSYS_GENERATOR_TCB0_CAPT_gc
      constexpr uint8_t EVSYS_GENERATOR_TCB0_CAPT_gc {0xA0};
    #endif
    #ifndef EVSYS_GENERATOR_TCB1_CAPT_gc
      constexpr uint8_t EVSYS_GENERATOR_TCB1_CAPT_gc {0xA2};  
    #endif
    #ifndef EVSYS_GENERATOR_TCB2_CAPT_gc
      constexpr uint8_t EVSYS_GENERATOR_TCB2_CAPT_gc {0xA4};  
    #endif
    #ifndef EVSYS_GENERATOR_TCB3_CAPT_gc
      constexpr uint8_t EVSYS_GENERATOR_TCB3_CAPT_gc {0xA6};  
    #endif

    #ifndef EVSYS_GENERATOR_ADC0_RESRDY_gc
      constexpr uint8_t EVSYS_GENERATOR_ADC0_RESRDY_gc {0x24};  // ADC 0 Result Ready Event
    #endif

    // PORTMUX - Port Multiplexer //
    // Zeile 3905
    // new A...F not 0...5
    #ifndef PORTMUX_EVOUTA_bm
      constexpr uint8_t PORTMUX_EVOUTA_bm {0x01};   // Event Output A bit mask.
    #endif
    #ifndef PORTMUX_EVOUTA_bp
      constexpr uint8_t PORTMUX_EVOUTA_bp {0};      // Event Output A bit position.
    #endif
    #ifndef PORTMUX_EVOUTB_bm
      constexpr uint8_t PORTMUX_EVOUTB_bm {0x02};   // Event Output B bit mask. 
    #endif
    #ifndef PORTMUX_EVOUTB_bp
      constexpr uint8_t PORTMUX_EVOUTB_bp {1};      // Event Output B bit position.
    #endif
    #ifndef PORTMUX_EVOUTC_bm
      constexpr uint8_t PORTMUX_EVOUTC_bm {0x04};   // Event Output C bit mask. 
    #endif
    #ifndef PORTMUX_EVOUTC_bp
      constexpr uint8_t PORTMUX_EVOUTC_bp {2};      // Event Output C bit position. 
    #endif
    #ifndef PORTMUX_EVOUTD_bm
      constexpr uint8_t PORTMUX_EVOUTD_bm {0x08};   // Event Output D bit mask. 
    #endif
    #ifndef PORTMUX_EVOUTD_bp
      constexpr uint8_t PORTMUX_EVOUTD_bp {3};      // Event Output D bit position. 
    #endif
    #ifndef PORTMUX_EVOUTE_bm
      constexpr uint8_t PORTMUX_EVOUTE_bm {0x10};   // Event Output E bit mask. 
    #endif
    #ifndef PORTMUX_EVOUTE_bp
      constexpr uint8_t PORTMUX_EVOUTE_bp {4};      // Event Output E bit position. 
    #endif
    #ifndef PORTMUX_EVOUTF_bm
      constexpr uint8_t PORTMUX_EVOUTF_bm {0x20};   // Event Output F bit mask. 
    #endif
    #ifndef PORTMUX_EVOUTF_bp
      constexpr uint8_t PORTMUX_EVOUTF_bp {5};      // Event Output F bit position. 
    #endif
#else
    #error "This library only support Arduino Nano Every Board with ATmega4809."
#endif

Technically, the atmega4809 definitions are part of a microchip/atmel “device support pack” that should be updateable separately from “the toolchain” itself. The arduino tools sort of mash them together in a way that is convenient, but not really “approved.”

Hi,

yes, you can actually exchange the headefiles. But I don't know if in the depths of the IDE old names of the bit definitions are used. I work only with current bit definitions. For this I wanted to create a compromise with forward compatibility that otherwise doesn't bother anyone. Is only meant for people who have only the megaAVR boards package installed. Who installs the MegaCoreX package is already advanced anyway. :wink:

My concern is that I don't have to ask anyone to install any other packages for my examples. I can recommend this, but it should not be mandatory.

I myself know how to handle additional packages and new toolchains.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.