Problem: No AVR support and path issues on windows

[argltuc]

Solution:

• Add minimal generic MCU support for AVR ATtiny and ATxmega
• fix compiler path detection on windows
• add EEPROM file creation for AVR MCU

Tested against:

• Windows 10 20H2
• CMake 3.20
• Ninja / Ninja Multi-Config
• Microchip xc8 v2.31 at default windows install path

Attention:
This PR is a duplicate of Elemecca#5 and will have a lot of differences to xc8-cc branch of this repo. I hope we get this two branches merged and create up a new base.

[argltuc]

Just for notice:
in Modules\Compiler we use different file names for the "same" thing: XC8-CC-C.cmake vs. XC8CC-C.cmake
The latter is the original name from upstream repo https://github.com/Elemecca/cmake-microchip

[enbyted]

I'll have a look at how this can be resolved later this week, potentially on weekend. Upstream has taken a different approach to handling the new XC8 frontned.

At least that's why my memory tells me, from the discussion in Elemecca#3

[enbyted]

I had a think about this, I don't think I necesserily like that you're using MICROCHIP_XC8_CLI to select avr-gcc instead as that compiler has no relation to xc8.

In this fork I don't have MICROCHIP_XC8_CLI, instead I have an override variable MICROCHIP_XC8_FORCE_NON_CC.

I'll play around with some ideas on how to integrate that. Currently I'm thinking about defaulting to avr-gcc for AVR and having an override like MICROCHIP_AVR_FORCE_XC8. How would you feel about that?

BTW, Why add this here instead of using something dedicated to avr-gcc? AVR and PIC are hardly compatible, do you have an application where you're compiling most of the code for both AVR and PIC? Even if, I don't really see why you'd not use a separate toolchain file.

[argltuc]

Well, when I extend Elmeccas stuff, i realizied some side effects of XC8 with C99 sources, which where not compiled since they where not C89 compatible. So I add avr-gcc to have the possibility to switch between XC8 and avr-gcc, which is somehow part of the XC8 package.
After checking your discussion in Elemecca#3 it seems, that my problem is related to v1 vs. v2 differences.

From my point of view, it seems we try to merge two diffrent approaches to one, what i think is not the best idea.

How do you think about this way:
I will check your current xc8-cc branch if it will work with my projects or what we should add to support AVR MCUs again. Then we can talk about to add avr-gcc support as part of the XC8 package or if we should seperate it.

Any suggestions?

Some notes to your question regarding PICs: I just use AVR MCUs and in the near feature some SAM MCUs projects will start. So I don't use PIC.