Add support for AVR-USB-MCU-families ATmegaXYu2/4/6 and AT90USBXYZ6/7 eg. Arduino Uno USB-MCU / Micro

[Virtual-Java]

Extended Optiboot functionality to support ten AVR-USB-MCUs:

The Makefile.usbmcus written by me supports the following parameters:

• UART-Port (defaults to UART1 since these USB-MCUs offer one hardware uart only)
• BAUD_RATE (defaults to optiboots 115200 Baud; can be overridden in terminal)
• AVR_FREQ (defaults to optiboots 16 MHz)
• BIGBOOT (support for 1kByte [ATmegaXYu2/4/6] || 2kByte Bootsection [ATmegaXYZ6/7])
• ISP-TOOL (optionally burn the bootloader with recommended settings)

To distinguish the files after compiling the parameters are represented in the filename!!!

Additionaly I adopted the automakefile created by MCUdude https://github.com/MCUdude to compile all USB-MCUs with selected parameters.

Note: All testing was done with gcc version 5.4. Optiboot for usb-mcus was compiled for and uploaded to Arduino Micro (ATmega32u4) by me only. Other versions haven't been tested so far, but should work too, since the microcontrollers are very similar.

Furthermore I resolved the issues regarding to atmega32u4 support mentioned in #132.
THANKS to dmjlambert https://github.com/dmjlambert for contributing his working atmega32u4 variant
Although it was based on an old version of optiboot from 2015, it was very helpful in creating and extending optiboot to support all 8-bit AVR-USB-MCUs.

correct #326 (never create a pull request from your own master branch) ;)

[WestfW]

Looks pretty nice. Very clean and "contained."
Would you add spacing in Makefile.isp comment:
LOCKFUSE ?=3f# = APP protect mode 1, BL protect mode 1

Also, the PR shows a bunch of .hex files moved to a hexfiles directory, but I don't see any changes to the makefiles that would have moved them there, nor the creating of the hexfiles directory, I suspect this was due to an overzealous "commit"; since current "policy" is that the Optiboot "parent" trunk deprecate the inclusion of .hex files (except for a few legacy files), could you fix this?

[Virtual-Java]

Thank you for this compliment.
Although I am not very good in deleting files from index afterwards, but I did my best.

By the way it is possible to enter a space before "3f" but not afterwards, which would result avrdude to fail reading the fuses
(output "-U lock:w:3f :m")

LOCKFUSE ?=3f# = APP protect mode 1, BL protect mode 1

Furtermore I tried to add a .gitignore file to prevent developers from getting the same issue like me. But unfortunately the pattern does not seam to match. Cleaning git's cache (git rm -r --cached) and re-adding the files afterwards (git add .) didn't solve the issue for me.
Maybe you can help me or solve this issue for me at this point. I have spent a lot of time to analyse the cause which I actually wanted to spend in implementing synchronous-usart (XCK), hardware-flow-control (CTS/RTR) and multioptibootloader (select target mcu by address).
Probably this feathers will not be really popular, but I need them to improve reliability in a multi processor communication system.

[WestfW]

it is possible to enter a space before "3f" but not afterwards
Ah. That must be why trailing comments are so uncommon in makefiles. Sigh.
I'll try to take a look at the .gitignore option.
There's an optiboot fork with addressed rs485 here: https://github.com/mikalai-kavalchuk/optiboot/tree/RS485_support (unfortunately, there seems to be little standardization WRT what people want to do with rs485.)

[WestfW]

I'm not sure how to undo the hexfiles changes either. Would it bother you if I committed your patches manually instead of via the PR?

[Virtual-Java]

Sorry for being so stupid for writing a pull request before cleaning my history.
I thought rebasing a repository would be very complicated, but it isn't.

Since I liked to have my commits very clean to ensure them to be included directly, I revised my work.
Thus I leaned how to resolve merge conflicts, to edit and to remove files from previous commits.
However now I've cleaned all history so that no additional hexfiles are included anymore.

The reference to the optiboot fork with RS485 was a great tip, I'll have a close look at it. Until now I think it looks very nice, but there is a lot of code overhead.
Additionally it is not possible to use address selection independent of RS485. Maybe it is worth to modify relevant parts to allow addressing with RS232 too. By hard-coding the target address it may be possible to save some memory to fit into 512 bytes bootsection. Eventually I will spend some time in updating that fork.

Finally thank you very much for helping me to improve my git commits.

[Virtual-Java]

Thanks for merging.
Why did you moved back the legacy hexfiles to the directory where the compiled output is stored?
I moved these legacy hexfiles to a separate directory to prevent them from being overwritten at each compile
(for the targets "atmega328, atmega644p or atmega1280").
By running make clean they are cleared as well.

In my modified version the legacy hexfiles are kept as fallback.
That's the reason for moving the files, but if that's not what you prefer, it's OK.
Unfortunately I ignored that it could lead to compatibility issues with the Arduino IDE or other software.

[WestfW]

Hmm. The calculations of the .text address for the large USB microcontrollers seems a bit suspect.
Why bother creating a 2k "BIGBOOT" at all?
a "make at90usb1286" command will default to a recursive make with BIGBOOT set to 1, as do all the default builds in the makeall.usbmcus.sh, resulting in 2k bootloaders (~770 bytes actual length.), so the normal way to get a 1k bootloader would be with "make at90usb1286 BIGBOOT=0", but the makefile makes the .text start addresses dependent on ifndef, so it still sets the start addresses for a 2k bootloader.

I'd rather not have a 2k bootloader at all, until it's actually needed (is there a reason for this?)
But if there IS a 2k bootloader, I'd prefer not to have BIGBOOT overloaded with that function. (HUGEBOOT? BIGBOOT2K? perhaps...)

(Detected while working on setting .text start from the io.h FLASHEND definitions... No need to provide a patch; just an explanation...)