-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for SAMC2x ? #659
Comments
@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 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 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. |
There are two main variations within the SAMC2x family: C20 vs C21, and the The C21 adds to the C20:
The
Compared to the D21, the C2x:
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 The PAC system is also more similar to the D5x, with one central module rather than one per APB. The 32 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. |
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. |
@jboynes, thanks for the comprehensive list. Nothing seems too difficult. I think the biggest pain is probably the clock system differences. I currently use 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 @sajattack and @jbeaurivage, any thoughts on adding C2x support? |
For the
They have the same restrictions on which pins support I2C as the D21. For the
I2C is supported on pins PA08, PA09, PA16, PA17, PB12, PB13, PB16, PB17 |
Added PR #662 for this. Currently contains commits for SVDs and generated PACs. |
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. |
@bradleyharden It looks like many of the differences between 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. |
@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 Check out the most recent HAL Cargo.toml for more details. |
@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 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. |
@bradleyharden Thanks for the work on clocks to make this easier. Is there any sub-task I can help with here? |
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.
The text was updated successfully, but these errors were encountered: