AVR-DU series support: status check, contribution offer, and commercial board plans

[ws-asahi]

Hi Spence,

First, thank you for the incredible work on DxCore - and on the Azduino boards
alongside it. I've been using DxCore as the foundation for a project of my own,
and before going further I'd like to check in on the state of AVR-DU support
and get your guidance on a few things.

About me / the project

I'm Yusuke Shimizu, running Workshop Asahi (朝日工房), a small electronics
workshop in Japan.

I'm working on an Arduino Leonardo successor based on AVR64DU32. The plan is:

• 32-pin VQFN board with Leonardo-compatible Arduino pin layout
• USB CDC (Serial) + HID (Mouse/Keyboard) via a clean-room USB stack
• 1200bps touch-reset CDC bootloader (Leonardo-style)
• Intended for small-volume manufacturing - both direct sales and
  B2B delivery to client companies, in the same spirit as your own
  Azduino boards on Tindie
• Timeline: ~12 months part-time

LGPL 2.1 compliance for the DxCore-derived parts is fully understood and
accepted (sources on GitHub, license notice with product documentation,
linker-replaceable libraries via Arduino IDE - the standard pattern your
Azduino boards, SparkFun, Adafruit and similar businesses already follow).

I have an AVR64DU32 Curiosity Nano (EV59F82A) on hand for development.

What I found while bringing up DxCore 1.6.2 on the Curiosity Nano

While trying to compile and upload a simple Blink sketch, I ran into several
issues that needed patching before I could get the LED to actually blink. I'd
like to flag these in case you'd welcome PRs (or perhaps you're already aware):

1. avrdu boards.txt has several missing/inconsistent template variables.
   Specifically: bootloader.OSCCFG, bootloader.avrdudefuse5,
   program.avrdudefuse5, bootloader.wdttimeoutbits (there's also a
   wdttimeotbits typo nearby), and bootloader.mviobits are not defined.
   SYSCFG0 references {resetpinbits} (plural) but the menu only defines
   resetpinbit (singular). The menu.eesave.* entries are missing entirely.
   Without all of these, avrdude fails with "invalid data {bootloader.X} in
   immediate mode" errors and programming aborts.

2. FLMAP default option causes AVR64DU32 to hang after upload.
   The default flmap=lockdefault adds -DLOCK_FLMAP -DFLMAPSECTION1, which,
   combined with the linker placing FLMAP_SECTION1 at 0x8000, puts user code
   in a region the CPU doesn't execute from after reset on 64K parts.
   Programming succeeds (avrdude verifies everything) but the code never runs.
   Switching to flmap=unlocked resolves it.

3. variants/32pin-duseries/pins_arduino.h has LED_BUILTIN = PIN_PA7,
   but on AVR64DU32 Curiosity Nano (EV59F82A) the on-board LED0 is on PF2,
   not PA7. PA7 on this kit is brought out only as the SPI SS line. This is
   per the official user guide (DS50003671A, Section 4.2 Table 4-2). The LED
   is also wired GND-sink (LOW lights it), which differs from the usual Arduino
   assumption. I realize the 32pin-duseries variant might be intended as
   generic rather than Curiosity-Nano-specific, so this is more of an FYI
   than a clear bug.

After fixing items 1 and 2, Blink works correctly when driving PF2. F_CPU=24
MHz produces a visually correct ~1 Hz blink with delay(500), confirming the
non-USB core is in good shape once the board definitions are sorted out.

I have detailed notes on each issue (exact patch text, before/after avrdude
logs, datasheet references for the AVR-DU SYSCFG0 bit layout which differs
from DA-series, etc.) that I'm happy to share or turn into PRs.

Questions

Before going further, I'd value your guidance on:

1. Are the items above already on your radar?
   I see DU32.md describes DU-series as pending release, so I want to make
   sure I'm not duplicating work-in-progress.

2. Would you welcome PRs for items 1 and 2?
   If so, do you prefer one combined PR, or split (e.g., one for boards.txt
   completeness, one for FLMAP default)? Item 3 might warrant a separate
   discussion about whether to add a dedicated cnano-du32 variant or just
   change the generic one.

3. USB stack — direction preference?
   You wrote in DU32.md: "the only reasonable thing to do with this core and
   a DU microcontroller is to develop such a library." I'd like to take that
   on. To avoid Microchip USB stack's licensing constraints (their license is
   "exclusively with Microchip products" with no explicit redistribution grant
   — problematic for both upstream merging and commercial board distribution),
   I'm planning a clean-room implementation from the USB 2.0 spec and the
   AVR-DU datasheet. Scope:

   • USB Device enumeration + control transfers
   • CDC ACM (Serial replacement)
   • HID Boot Protocol (Mouse / Keyboard)
   • Composite Device (CDC + HID)
   • 1200bps touch-reset CDC bootloader (separate effort)

   I'd appreciate your input on whether you'd prefer:
   (a) the USB stack fully merged into DxCore (LGPL 2.1 with the rest of
   the core), or
   (b) it as a separate library DxCore depends on (could be MIT, more
   reusable outside DxCore - e.g., other DU projects, TinyUSB
   contribution as an AVR-DU port, etc.)

   Option (a) is simpler; option (b) might benefit the wider AVR-DU ecosystem
   but adds a dependency boundary. Happy to go either way.

4. Small incremental PRs vs. larger drop?
   I'm assuming small incremental ("boards.txt fixes first, then variants,
   then USB piece by piece") is preferred, but please let me know if you'd
   rather see things batched differently.

5. A Leonardo-compatible variant alongside the generic 32-pin one?
   My pin assignments (USART0 ALT3, TWI0 DEFAULT, SPI0 DEFAULT, TCA0 PORTF,
   TCB0 ALT1, TCB1 DEFAULT) match the recommendations in DU32.md almost
   exactly - but the Arduino pin number layout differs (Leonardo-style
   D0..D13/A0..A5 mapping for shield/library compatibility). Would you be
   open to a 32pin-du-leonardo variant existing alongside the generic
   32pin-duseries, or would you prefer all 32-pin DU boards use the same
   variant?

Happy to keep things slow and have a discussion before any code lands - I'd
rather invest the time once I know I'm pointed in a direction that works for
upstream. And of course, even if some pieces stay as my own fork due to
specific design choices, the boards.txt and FLMAP fixes seem like clear-cut
improvements that benefit any DU-series user, so those at minimum I'd like
to contribute back.

Thanks again for everything you've built. Looking forward to your thoughts!

(A note: English is not my first language, so please forgive any awkward
phrasing - I'm happy to clarify anything that isn't clear. I'm also new to
contributing to other people's GitHub repositories - I've used GitHub for my
own work but haven't submitted PRs upstream before, so I may need a bit of
guidance on the contribution workflow when the time comes.)

Best regards,
Yusuke Shimizu

[WestfW]

To avoid Microchip USB stack's licensing constraints

AFAIK, neither the "Pluggable USB" library used in existing USB-capable AVRs (ie ATmega32u4), nor the LUFA library used in the bootloader and 16u2 firmware, is dependent on any Microchip License...
It would probably be particularly beneficial to keep "pluggable USB" as the API layer, so that other existing USB sketches (ie MIDI, assorted game controllers, etc) would be portable to the new boards.

[ws-asahi]

Hi @WestfW

thank you - Pluggable USB was exactly the right call, and I wanted to report back.
You were right about the licensing; my real concern was only the Microchip USB stack (the "Microchip products only" wording),
so I wrote just the AVR-DU device layer from scratch and exposed it through the standard Pluggable USB API.
Your portability prediction was spot on: the stock Arduino Keyboard and Mouse libraries run unmodified - a CDC + HID composite is now working on an AVR64DU32 Curiosity Nano.
Work in progress is on my fork (feat/avr64du32-usb-cdc branch):https://github.com/ws-asahi/DxCore/tree/feat/avr64du32-usb-cdc
Still to do: gamepad and the receive-side paths (currently stubs).

Thanks again - existing sketches carrying over is a much better result than what I first imagined.

[ws-asahi]

I've published the implementation as draft PR #637.
The variant structure and VID/PID will follow whatever is decided in this discussion.

Going forward, I plan to continue hardware verification on the remaining peripherals (I2C, SPI, etc.)
and to test the example sketches from DxCore and other commonly used librarieson the AVR64DU32,
expanding the verified coverage of the draft PR.