Support for AVR DU

[echoromeo]

Hi, I have added support for the new AVR DU Family, ported from the current XMEGA support, and added the AVR64DU32 Curiosity Nano board. I think the only thing I have not touched (yet) is bootloader.
I added it as ARCH_AVRDX in case more Dx USB devices pop up.

As I could not see any obvious DFP support in the build system I ended up including paths to the include file and device-specs file to the build flags in the makefile(s). Using the default Microchip Studio path in windows it would look like this:

CC_FLAGS += -B"C:/PROGRA~2/Atmel/Studio/7.0/packs/atmel/AVR-Dx_DFP/2.4.286/gcc/dev/avr64du32" -I"C:/PROGRA~2/Atmel/Studio/7.0/packs/atmel/AVR-Dx_DFP/2.4.286/include"
LD_FLAGS += -B"C:/PROGRA~2/Atmel/Studio/7.0/packs/atmel/AVR-Dx_DFP/2.4.286/gcc/dev/avr64du32"

Please have a look and let me know if this is something you would want to merge :)

[bradanlane]

We are interested in testing this PR against the Microchip "generated" stack (which is pretty heavy).

[echoromeo]

@bradanlane please go ahead and test it out and let me know if you have any questions or bugs/problems

[bradanlane]

@echoromeo ...

@bradanlane please go ahead and test it out and let me know if you have any questions or bugs/problems

I am sure the build process is not overly complex for anyone who has build it in the past. Unfortunately we spend about an hour trying to get through all of the generated errors (likely all due to configuration of the build environment).

Is there an example of setting up the USBtoSerial project for the AVR DU Curiosity Nano? (we have one of these for testing) ... specifically what changes are made to various .mk files to get the MCU, ARCH, BOARD, etc correct?

Here are some example issues which may help you understand where our configuration is incorrect:

• in the USBtoSerial Makefile, we set the above values to avr64du32, AVRDX, and AVR64DU32_CNANO respectively
• the make renders a large number of errors including:
  • undeclared such as TXEN1, UCSR1B, and UDR1
  • argument mismatch for Serial_SendByte
  • conflicting type for CALLBACK_USB_GetDescriptor

Addendum: I am using the features/avr-dx branch

[bradanlane]

@echoromeo ... much progress

I switched from attempting Projects/USBtoSerial to using Demos/Device/ClassDriver/VirtualSerial.

After adding the required CC_FLAGS+= and LD_FLAGS+= (described at the start of this PR) I received only one error.
The error RAMPZ used in ClockManagement.c. There is no definition of this value ... at least not when using avr_gcc version 7.3.0 and the AVR-Dx_DFP version 2.7.321

Solution: eliminating AVRDXCLK_CCP_Write and using CPU_CCP = CCP_IOREG_gc; // unlock protected register solves the issue and the Demo code works.

[bradanlane]

I have incorporated the code from this PR into a test project and it is working well at both 12mHz and 24mHz.

Thank you @echoromeo !

[WestfW]

It bothers me a bit to have so much volume of the changes be of the form

	#elif (ARCH == ARCH_AVRDX)
        // same defines/etc as in ARCH == ARCH_XMEGA

instead of doing

	#elif ((ARCH == ARCH_XMEGA) || (ARCH == ARCH_AVRDX))

Or somehow factoring out the DU as a subset of XMEGA (Haven't checked yet how possible that is...)
OTOH, I'm not familiar enough to the LUFA code or its implicit "style manual" to know whether that sort of thing is forbidden. :-(

[echoromeo]

The error RAMPZ used in ClockManagement.c. There is no definition of this value ... at least not when using avr_gcc version 7.3.0 and the AVR-Dx_DFP version 2.7.321

Solution: eliminating AVRDXCLK_CCP_Write and using CPU_CCP = CCP_IOREG_gc; // unlock protected register solves the issue and the Demo code works.

Ah, I suspect the RAMPZ was removed with a later DFP than the one I used. Will have a look and update the assembly in AVRDXCLK_CCP_Write.

It bothers me a bit to have so much volume of the changes be of the form

	#elif (ARCH == ARCH_AVRDX)
        // same defines/etc as in ARCH == ARCH_XMEGA

instead of doing

	#elif ((ARCH == ARCH_XMEGA) || (ARCH == ARCH_AVRDX))

Or somehow factoring out the DU as a subset of XMEGA (Haven't checked yet how possible that is...) OTOH, I'm not familiar enough to the LUFA code or its implicit "style manual" to know whether that sort of thing is forbidden. :-(

I believe you are reffering to the LUFAConfig.h files in all the LowLevel and ClassDriver folders. I agree that there is a lot of overlap. However, if you look at the original files you see there are a lot of the same defines/etc between

	#if (ARCH == ARCH_AVR8)

and

	#elif (ARCH == ARCH_XMEGA)

as well so I just tried to follow the same style. There are settings in there that probably can be moved out of the entire #if.

In the common files further down I have done as you suggested.