Add support for SAMC2x ?

[jboynes]

The SAM C20 and C21 are 5V tolerant parts very similar (actually "drop-in" for some variants) to the SAM D20 and D21. Would it be appropriate to provide a PR to include them in this repo? Testing would be done using a BSP for the SAMC21_XPRO dev board.

[bradleyharden]

@jboynes, I think we are open to supporting more chips, but with some reservations. In particular, supporting SAMD11 chips was a pain when dealing with the sercom module, because it breaks an assumption that can be made for D21 and D51 chips.

On a quick look at the datasheet, it looks like the C21 clock system is a mix between the D21 clocks and the D51 clocks. We recently merged #450, and I've been working on porting it to D21 and D11. I haven't hit any major problems yet, so maybe it would work. I would have to see.

What would be really nice and would help make this actually happen, would be for you to go through and document that major differences between C21 and other chips. Specifically, I think the major issues would be pinouts and packages for the gpio module, SERCOM to pin mappings for the sercom::pads module, clocking system for the clock module, and then any other major differences.

My main concern is that we continue to take on additional chips, but it incrementally makes the code harder and harder to maintain. However, I think it's fair to also balance that against the alternative, which is separate repos that are all copy/paste variants and don't receive any common updates. It's a tough problem.

[jboynes]

There are two main variations within the SAMC2x family: C20 vs C21, and the N variant vs. others

The C21 adds to the C20:

• CAN-FD using an M_CAN block
• 16 bit SD-ADC
• 10 bit DAC
• Temperature sensor

The N variant adds a fourth bus, APBD, with additional peripherals as well as additional functions on some other peripherals:

• PORT D pins
• 2 additional SERCOM
• 3 additional TC timer-counters
• TC with max/min capture
• Hardware debouncing for EIC

Compared to the D21, the C2x:

• Does not have USB support
• Does not have I2S (sound) support
• Does not have TCC3
• Cortex-M0 supports privileged mode with MPU
• Is 5V tolerant, which adds calibration registers
• May support 64MHz operation for CPU and buses
• Adds DIVAS unit for hardware-assisted divide

The clock system is closer to the D5x, with separate MCLK, OSCCTRL and OSC32KCTRL blocks vs. the D21's SYSCTRL. In general they support 48MHz operation but some parts are now available orderable at 64MHz.

The PAC system is also more similar to the D5x, with one central module rather than one per APB.

The 32 E, 48 G and 64-pin J TQFP and VQFN packages are "drop-in" compatible with the D21. The 100-pin TQFP of the N variant has no D21 equivalent, and the WLCSP packages are incompatible.

SERCOM USART adds LIN and RS485 support, with additional pad modes. SPI and I2C look to be the same.

Access to RWWEE memory via NVMCTRL is different; the C2x has a separate page buffer. Maybe. I find this part of the datasheet confusing.

[jboynes]

Throwing another wrench in here, Microchip also have the PIC32CM-MC and -JH parts which are "next generation successors" to the SAM C2x. Yes, they are Cortex-M0 based and not MIPS.

It definitely seems odd adding those to a project named "atsamd" so perhaps they should go somewhere separate along with the C21. That said, one of Microchip's selling points for them is that they use many of the same peripherals as the SAM series so it would be helpful to share a HAL for them across families like you said to reduce copy/paste and maintenance.

[bradleyharden]

@jboynes, thanks for the comprehensive list. Nothing seems too difficult. I think the biggest pain is probably the clock system differences. I currently use thumbv6 and thumbv7 features to distinguish between the SYSCTRL/PM clocks and the OSCCTRL/OSC32KCTRL/MCLK clocks. Adding these chips would break that.

Could you also check the SERCOM pinouts? Specifically, are there any pins that map to two different SERCOM pads on the same SERCOM? That never happens for D21 and D51 chips, but it does happen for D11, which caused me much heartburn.

We already support E5x chips, so adding C2x chips wouldn't be that big of a deal. But it does suggest we should consider renaming the HAL to atsam-hal.

@sajattack and @jbeaurivage, any thoughts on adding C2x support?

[jboynes]

For the EGJ parts, there are no pins that map two different pads on the same SERCOM. And where a pin maps two SERCOMs it always maps the same pad.

I/O Pin	SERCOM (C)	SERCOM-ALT (D)
PA08	SERCOM0/PAD[0]	SERCOM2/PAD[0]

They have the same restrictions on which pins support I²C as the D21.

---

For the N parts, pins PB07 and PB08 remap pads on SERCOM7

Pin	I/O Pin	SERCOM (C)	SERCOM-ALT (D)
14	PB07	SERCOM7/PAD[3]	SERCOM7/PAD[2]
15	PB08	SERCOM7/PAD[2]	SERCOM7/PAD[3]

I²C is supported on pins PA08, PA09, PA16, PA17, PB12, PB13, PB16, PB17

[jboynes]

Added PR #662 for this. Currently contains commits for SVDs and generated PACs.

[sajattack]

@jboynes, thanks for the comprehensive list. Nothing seems too difficult. I think the biggest pain is probably the clock system differences. I currently use thumbv6 and thumbv7 features to distinguish between the SYSCTRL/PM clocks and the OSCCTRL/OSC32KCTRL/MCLK clocks. Adding these chips would break that.

Could you also check the SERCOM pinouts? Specifically, are there any pins that map to two different SERCOM pads on the same SERCOM? That never happens for D21 and D51 chips, but it does happen for D11, which caused me much heartburn.

We already support E5x chips, so adding C2x chips wouldn't be that big of a deal. But it does suggest we should consider renaming the HAL to atsam-hal.

@sajattack and @jbeaurivage, any thoughts on adding C2x support?

Renaming the HAL is a bit of a pain due to the way crates.io works. It's quite a breaking change and hard to notify users that what they're getting is no longer receiving updates. We've already done it once https://crates.io/crates/atsamd21-hal

I don't mind adding new chips if it makes sense, but on the naming point, there are other hals such as atsam7x-hal that might also have some confusion if we became atsam-hal.

[jboynes]

@jboynes, thanks for the comprehensive list. Nothing seems too difficult. I think the biggest pain is probably the clock system differences. I currently use thumbv6 and thumbv7 features to distinguish between the SYSCTRL/PM clocks and the OSCCTRL/OSC32KCTRL/MCLK clocks. Adding these chips would break that.

@bradleyharden It looks like many of the differences between thumbv6 and thumbv7 are due to the different clocks. It seems like the SAMC and SAML @tahnok both use the same structure. On the other hand, the SAMG is a thumb7 (M4F) part that uses the older SYSCTRL block.

There other mix-and-match peripheral blocks e.g. USB, CCL, DAC, SDADC, CAN that may or may not be present in any of these ranges.

What do you think about modeling each block as it's own module within the HAL. The chip family (C/D/E/L or maybe even C20/C21/D21/E51/E54 etc.) feature would determine which modules were included, with fine grain features within the module for the smaller differences between each device.

[bradleyharden]

@jboynes, yes, that's exactly the approach I took in #656, which was just merged. I had assumed I could get away without adding any clock-specific features, relying on thumbv6 and thumbv7 features instead, but it shouldn't be that difficult to incorporate extra features to specify SYSCTRL vs OSCCTRL and MCLK.

Check out the most recent HAL Cargo.toml for more details.

[bradleyharden]

@jboynes, I made some progress on the port of #450 to D11 and D21 chips this weekend. As part of that work, I looked through the C20/C21, L21 and L22 datasheets, and I noted some of the broader differences in the clock systems. I added a slew of micro-features to Cargo.toml to handle all the different cases. I also started to update the clock submodules to use the new features.

For the moment, I'm going to stay focused on D11, D21 and D5x/E5x, but I don't think it will be too difficult to add support for other chips in the future.

[jboynes]

@bradleyharden Thanks for the work on clocks to make this easier. Is there any sub-task I can help with here?