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
atsamd: Add support for SAMC21 #6009
Conversation
Signed-off-by: Luke Vuksta <wulfstawulfsta@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. In general it looks good to me. I have a few minor comments below.
Separately, can you give a brief overview of what the "sdadc" is and how it is used? I don't think it is a roadblock for this PR, but a highlevel description would help give me some context.
-Kevin
#if CONFIG_HAVE_SAMD_USB | ||
if (!CONFIG_USB) { | ||
// The FDCAN peripheral only seems to run if at least one | ||
// other peripheral is also enabled. | ||
enable_pclock(USB_GCLK_ID, ID_USB); | ||
USB->DEVICE.CTRLA.reg = USB_CTRLA_ENABLE; | ||
} | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's only necessary to enable one other device - if ID_USB isn't defined, we can choose some other device. (This whole thing is some weird quirk of the samd power enable code on sam5x.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know if this is true for the samc21? This chip does not have usb, so we’d have to enable something else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KevinOConnor can you provide more details about this? I’m having issues with CAN, and am wondering where I might investigate this further for the samc21.
The sdadc is a different data structure, so an additional field in |
I'm a little confused - what pins on that Duet board are using the sdadc? -Kevin |
Edit: accidentally closed, oops. |
Okay, thanks for the info. FWIW, the duet3 use of the sdadc looks to me to be a "micro optimization" that requires "high complexity". My suggestion would be to not add any sdadc code and just use the traditional adc measuring of PB8 for TEMP_0. As background, the sigma-delta adc (sdadc) is capable of calculating the voltage difference between the two "negative" and "positive" input lines. (As opposed to a traditional ADC which measures a voltage as a ratio between VSSA and VREF.) The sdadc has 16 bit resolution, while the traditional adc has 12 bit resolution. So, it seems to me that the duet3 is just trying to get a few more bits of resolution (though because the comparison is always positive, it's at best a 15 bit resolution, and it's not clear to me that the additional bits would be of much value due to noise in the system). -Kevin |
Okay, I understand it now. I'll think about how I can hack it in when I get a few minutes to clean up this other stuff; it seems like a shame to waste the hardware if it's there. |
78f37f4
to
c305fa5
Compare
@KevinOConnor Don't merge this just yet, I should do some more testing. |
I think this is good, but I'm not around hardware to test it right now. I should be able to in a few days. |
What's the current status of this PR? -Kevin |
Untested, on vacation. I’ll test once I’m back and have a few hours. |
So I've figured out how to flash Duet Toolboards greater than revision 1.0 from a Pi 4, but am not seeing the mcu from a waveshare hat. I didn't look too carefully at the |
src/atsamd/samc21_clock.c
Outdated
uint32_t | ||
get_pclock_frequency(uint32_t pclk_id) | ||
{ | ||
return CLKGEN_MAIN; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that's a bug.
19bc5cf
to
588732d
Compare
ccce4b3
to
87865b8
Compare
Unfortunately, I don't know why that limitation exists on the atsame chips. I just know that when I was running Klipper in usb-to-can bridge mode everything worked and that it wouldn't work if regular canbus mode. Ultimately I found that if I just enabled the usb peripheral clock it was enough to get canbus working in normal standalone mode. I saw a brief blurb in the documentation about the can hw on atsame not requesting clocks (or some such) and so I just forced it to work by enabling some other clock. My recollection is that enabling any other clock worked. Separately, what is the state of this PR? If there is an issue with fdcan then I think it would help if we could separate out the fdcan changes from the rest of the PR. If atsamc is working in regular serial mode then we can get that merged. That will make the review process for the fdcan parts a lot smaller (and thus simpler). Cheers, |
Ah, thank you for the info. I'm lacking 5v hardware to hook this up to UART right now, so I'm inclined to continue until I have this working with CAN, so as to not accidentally push any bugs upstream. I've been using gdb and hardcoded calls to validate various functionality so far. I can convert this to a draft if you aren't happy with it sitting open while I investigate why I can't connect over CAN. |
bac6311
to
0df7798
Compare
It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket. Best regards, PS: I'm just an automated script, not a human being. |
What was the final results of the work on the samc21? -Kevin |
Still working on it, CAN Tx works, but I can’t seem to get Rx to. Going to hook up some more hardware and try to catch what’s happening in gdb. If you want to reopen feel free, I will get this to work eventually. I’d also really appreciate it if you could take a hard look at the fdcan.c file - you might catch something I haven’t… |
@KevinOConnor Can you comment out the USB initialization in |
@KevinOConnor I added 12MHz clocks for v1.0 of the Toolboard, dug a Jetson TX2 out of storage, and tested with those two pieces of hardware. It worked immediately, so the issue was the hardware I was testing with. You can go ahead and merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I have some review comments and questions. See below.
-Kevin
#if CONFIG_MACH_SAMC21 | ||
MCLK->AHBMASK.reg |= MCLK_AHBMASK_CANx; | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain what this does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bus clock for CAN is not enabled by default on this chip (annoyingly, see section 17.8.6 of the data sheet). This turns it on. Notice that it's not the same as the one in the clock code.
#if CONFIG_MACH_SAMC21 | ||
TCp->COUNT32.CTRLBSET.reg |= TC_CTRLBSET_CMD(TC_CTRLBCLR_CMD_READSYNC_Val); | ||
while (TCp->COUNT32.SYNCBUSY.reg & TC_SYNCBUSY_COUNT) | ||
; | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain what this does? The timer_read_time()
is a "fast path" function - overhead here will have notable impact on performance and benchmark results. Is there a way to just read the counter value without having to perform a write (or at least without having to perform a read-modify-write and a loop)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a note hidden in the data sheet under the 32 bit register summary for this register (section 35.7.3.13) that states this synchronization must happen prior to any read access.
21599cf
to
8205ef5
Compare
Signed-off-by: Luke Vuksta <wulfstawulfsta@gmail.com>
Thanks. I merged this PR. In regard to Along those lines, it would be interesting to see the benchmark results (see docs/Benchmarks.md) for this chip. Also, would probably be a good idea to update the regression build tests ( -Kevin |
Quick and dirty addition of samc21, missing the
sdadc
. Whoever reviews this, please have a close look at the clocks - I don't know if they're up to Klipper's standards.