Yeah I was about to ask the same question.
this one as very few pins
this one requires a carrier board
I’ve ordered this one few days ago. It should be compatible I think.
Nice! with QSPI flash! love it
That one is cool, but I didn’t order it so far (as you know I like the little boards 
)
I assume it will work. I think it might be able to do 6-PWM with 2 or more motors, which is unrealistic with any of the other boards based on the number of pins.
I have tested with the following boards:
SAMD51:
Feather M4 express
SAME51:
Feather M4 can
SAMD21:
Nano 33 IoT
MKR1000
MKR1010 WiFi
Seed Xiao
Feather M0 express
Feather M0 basic proto
Hey that sounds awesome…
That’s a good idea, I didn’t think to make this explicitly part of the driver code. So far I’ve been adding individual commands to the commander for the stuff I need.
I’d like to model the solution on his, using DMA, but I’m concentrating on other things atm. Antun is heavily at work on the core of the current sensing code for the next release, and the FOC algorithm side of things is not my expertise.
So I’m taking it slowly, waiting for that to be stable before attacking the driver side (which is just moving bytes around in complex ways, I feel comfortable with that).
@Antun_Skuric What are your plans for current sensing? Maybe I could help.
Hey malem,
I saw all your changes, thank you so much, its awesome. I’d like to merge them in, but your pull-request has conflicts in the Commander.cpp. There are too many changes to that file that happened in parallel.
Could you send the pull request again without the commander changes (for example by moving them over to a fresh copy of the dev branch)? Then I can merge your pull request.
Or would you prefer I merge your changes over? (absolutely no problem for me to do so, but then the contribution isn’t tracked by GitHub the way it would be in a pull request)
I’d love to try out your current sensing code!
Regards,
Richard
You’re trying to merge my fork with the ADC code as-is?
I’m confused. I only sent a pull request with the samd debug code, and maybe I told you about my drv8305 code. What are-you trying to merge exactly, I’ll be happy to help…
on a side note. I wish I knew about that kind of C syntax with the :3 offset
typedef union {
struct {
uint8_t OCP_MODE:2;
uint8_t OCP_LVL:1;
uint8_t OCP_RETRY:1;
uint8_t OCP_DEG:2;
uint8_t OCP_CBC:1;
uint8_t DRV_OFF:1;
};
uint8_t reg;
} Control__4;
I simply ignored it existed, my drv8305 code would be much better with it. I’ll try to improve it later on
for the ADC code, I’m still improving it. it’s not ready, frankly…
Oh and btw… the driver branch is named “Ardunio”… no biggie. I don’t think it’s too late to rename it
Hey, when you push more changes to the same branch, they automatically get added to the pull request. So I see your ADC code as part of the pull request now.
Ok, then we can certainly wait until you think it is a good time. Note that on the dev branch, and as an optional component that only affects people deliberately using it, it would not be a problem if it isn’t perfect yet.
The changes to the SAMD21 driver code, the refactoring of the Serial debug output.
I’m very happy to just merge it myself, but I really don’t want it to look like I’m “stealing” your contribution… so if you’d be prepared to separate it from the commander changes, then I could directly accept your pull request.
When working with pull requests, it is a good idea to make separate branches for everything you’d like to contribute, and start a new branch each time for different features…
Otherwise the commits you add later (e.g. after “sending off” the pull request, but before it is merged) become part of that pull request and it can become difficult to merge it in (likelihood of conflicts rises, harder to see what’s going on, etc…).
It’s also important to pull in the forked repos changes into your branch regularly to make sure your branch isn’t getting too far behind.
So in the context of what’s going on now it would mean creating a new branch of the SimpleFOC dev branch, and getting rid your commander changes, and keeping just the driver code changes in that branch.
You could make an additional branch (from simpleFOC dev) for the ADC changes if you don’t want them merged yet…
Thank you so much for all the work you’re putting into this, and sorry to be a pain about the git!
Oh that! I think @Antun_Skuric already merged it, that’s why I kept pushing. my bad. I thought you knew.
But yeah you’re right, I’ve been using my fork as a a dev branch, forgotting about my MR.
I fixed the conflicts.
Please read Dev by maxlem · Pull Request #79 · simplefoc/Arduino-FOC · GitHub
I’ll work in a cleanlier way next time.
beware LowSideCurrentSense.getPahseCurrents() return volts right now. I’m still debugging this.
After all I completely removed my LowSideCurrent class. using the new LowsideCurrent instead.
To submit to the new hardware_api I decided to to a new function _startADC3PinConversionLowSide()
I did try to hook myself in the DMA complete event to trigger the next conversion immediately but that completely destroyed my control loop timings, motor became unstable)
Now I would need to hook the conversion to som PWM timer event like it was done in @Antun_Skuric esp32_mcp.cpp
Do you have hints?
from an API perspective, I’d suggest a callback function passed to the Driver class. then mcu-specific code would call it from the right ISR
Thank you so much for all that hard work! I have merged it into the dev branch, and will test it out as best I can in the next days.
My approach was to try to use the SAMD’s event system for this. Your choices are basically events or interrupts, but I think events are faster, and need no additional MCU resources at all, i.e. would be completely parallel to your application code, which the interrupts are not (application code is halted while interrupts are executing).
I would completely ignore the TC units and only concentrate on the TCCs. People who want current control should use TCC pins.
We do phase-correct PWM (up-down counting) - so the TOP value represents exactly the middle of the PWM on-period for the high-side, and the BOTTOM value represents the middle of the PWM on-period for the low-side (which has inverted output).
Personally, I would just attach to the high side, then the code can probably remain the same for 3-PWM and 6-PWM.
So basically for low side sensing I think you always want to generate events when the counter reaches the bottom value (turns around). You do this by setting PWM mode “DSBOTTOM” and setting EVCTRL.OVFEO=1 (I think!).
Then, on the ADC side, you trigger a START conversion on this event. You can set EVCTRL.STARTEI=1 on the ADC, not quite sure what if any other settings are needed.
Finally, in the event system, you have to route the event from the TCC to the ADC. I need to find an example for that, the datasheet isn’t super-clear…
Thanks a lot for the very detailed hints. I finish something my (fast, binary) datalogger/real-time plotter and I start working on this.
I’ll try to present you with a cleaner MR this time
I began looking into it. Enabling event generation from the tcc and event reaction on the adc is straight forward. The routing seems a bit trickier. Atmel doc isn’t so bad, I’ll manage.
I found this thread for SAMD51, not sure how similar the configuration is in SAMD21:
https://community.atmel.com/forum/evsys-issue-atsamd51
Maybe it helps?
a.w.e.s.o.m.e!
exactly what I needed!
After all, the examples in this forum weren’t directly usable. There are non-trivial (well to me, at least) register definitions differences which made the example hard to port to my samd21.
After many failed trials, I went back searching for a closer example and found this
I have a working POC which allows me to control the ADC sampling rate via TCC0 pwm frequency.
uint16_t result = 0;
int i = 0;
void ADC_Handler()
{
result = ADC->RESULT.reg;
i++;
}
void loop()
{
SerialUSB.print("adc( ");
SerialUSB.print(i);
i = 0;
SerialUSB.print("): ");
SerialUSB.print(result);
SerialUSB.print(" - ");
SerialUSB.println(result / 4095.0 * 5.0);
// ADCsync();
delay(1000);
}
where i varies predictably.
Tomorrow I wrap this up.
Hey, that’s really great! I look forward to trying it out!
Hey,
After spending some time trying to cleanup SAMD21 variant.cop mess this morning, I continued on this topic.
You can find the changes here
the commit message goes like this
FEAT samd21 low side current sense, sync with pwm
use of EVSYS to trigger ADC conversion at each TCC OVF
removed DMA code as I couldn’t figure out how to combine bothProblem1: Currently I only get straight 1.71V +/- 0.01 no matter what happens
with the motor /control loop. Something is off with the timing(1)
Problem2: all OVF signal triggers the ADC, which is configured in INPUTSCAN mode and iterate over the 3 channel at each event trigger. while events come from different channels, they all sink into the same USER channel and there is now way of correctly mapping e.g. TCC0 to ADC pinA(1) This was not the case with my previous FreeRun/DMA version, when I could see voltages reacting to my hand forcing the motor out of it’s target angle (angle controlo mode)
[edit: the nominal value for the output sence on the DRV8305 is 1.67V]