Can't configure Itsybitsy m4 default SPI with sercom::v2 (new undoc ioset perhaps?)

[Josfemova]

The documentation correctly points out that:

An SPI peripheral can use up to four Pins as Sercom pads. However, only certain Pin combinations are acceptable. All Pins must be mapped to the same Sercom, and for SAMx5x chips, they must also belong to the same IoSet. This HAL makes it impossible to use invalid Pin combinations, and the Pads struct is responsible for enforcing these constraints.

The datasheet points this out too:

6.2.8 IOSET Configurations

• The SAM D5x/E5x has multiple peripheral instances, mapped to different IO locations. Each peripheral IO location is called IOSET and for a given peripheral, signals from different IOSET cannot be mixed.
• For a given peripheral with two pads PAD0 and PAD1:
  - Valid: PAD0 and PAD1 in the same IOSETn.
  - Invalid: PAD0 in IOSETx and PAD1 in IOSETy.

Yet...for the default SPI, Sercom1 is supposed to be configured using PA00, PA01 and PB23...The problem being that PA00 and PA01 are part of IOSET4 but PB23 lives in IOSET3.

Sounds like adding an equivalent to atsamd_hal::sercom::v2::pad::UndocIoSet1 could be a solution.

Type-level variant of IoSet representing an undocumented SERCOM IOSET
After implementing IoSet type checking, it became clear that some existing boards were using a combinations of pins that did not match any IOSET in the datasheet. From that, we infer that there must be at least one undocumented IOSET, and we added this new IoSet to account for it.
As of writing this documentation, only one undocumented IOSET has been discovered: PA16, PA17, PB22 & PB23 configured for Sercom1. Both the pygamer & feather_m4 uses this combination.
See the type-level enum documentation for more details on type-level variants.

[bradleyharden]

Every time this happens I want to tell Microchip: