I think i found a strategy for making the square wave.
By setting the LOW side gate output with reverse polarity, then setting those two complimentary outputs to the same duty-cycle should create a square-wave.
// Configure TIM1 channels 1-6 for PWM output
TIM_OC_InitTypeDef sConfigOC1 = {0};
sConfigOC1.OCMode = TIM_OCMODE_PWM1;
sConfigOC1.Pulse = 0;
sConfigOC1.OCPolarity = TIM_OCPOLARITY_HIGH;
sConfigOC1.OCFastMode = TIM_OCFAST_DISABLE;
TIM_OC_InitTypeDef sConfigOC2 = {0};
sConfigOC2.OCMode = TIM_OCMODE_PWM2;
sConfigOC2.Pulse = 0;
sConfigOC2.OCPolarity = TIM_OCPOLARITY_LOW;
sConfigOC2.OCFastMode = TIM_OCFAST_DISABLE;
In this configuration, the polarity for PWM1 is set to high, meaning that the output will be active when the duty cycle is high (100%) and inactive when the duty cycle is low (0%). The polarity for PWM2 is set to low, meaning that the output will be active when the duty cycle is low (0%) and inactive when the duty cycle is high (100%).
So these will not cross conduct if set to the same duty-cycle?
No, these will not cross conduct if set to the same duty cycle.
And setting both to 30% will create a squarewave ?
Yes, setting both to 30% will create a square wave.
I guess next step is to verify if it work on two of the broken out pins. Ill try to set my Portenta up as a analyzer. Maybe someone already did that ? It does have super fast high resolution ADCs. Hmmā¦ that would require a USB High Speed link. Maybe to fast for processing ?
I do have PA15(TIM8_CH1) and PB3(TIM8_CH1N) broken out. Basically I will have to measure the output on the 16bit ADC of the Portenta H7, and see how fast it will plot a time_frame.
Hmmmā¦
This is unfortunate, but it doesnāt know which you prefer in this case - this would have to be reflected in the scoring function.
As a quick fix you could re-order the elements in the PinMap to move the lines involving TIM8 up, I think when equal the first entries will win.
more complex solution would be to reflect it in the scoring function. but this is a lot more complex than it seems since while you seem to want TIM8, the next user might prefer TIM2, for whatever reasonā¦
@runger
Im thinking the setpwm for the 8PWM driver should do the same as the 4PWM only using the setPhase. Like its done for phases with the 6PWM driver.
It should definitely print the value and a warning in debug modeā¦the real danger is if people start changing polarization like I did. I was lucky that the power supply is a standard router psu which canāt burn through the FETs, it did get hot that one timeā¦
Hey, on a ānormalā setup for a new board I would always recommend checking the PWM without the gates powered before driving the FETs and a motor. But on the STSPIN32G4 you canāt as the PWM happens internally on the chip. So here Iād recommend using a current-limiting PSU and high ohm motor for safety during first tests.
To clarify the error youāve found, what youāre saying is the macro __LL_TIM_CALC_DEADTIME() which we use to convert the ns to the dead-time value sometimes works out as >255? This would from my point of view be an error of the macro, but looking at it (its super-complex, ugh) it does seem to me the result is cast to uint8_t in all casesā¦
Were you using the macro? Could you share the code you were running to set the dead-time?
[Edit]
no, wait, youāre saying the macro returns 0 if the dead-time is larger than the maximum? Thatās even worse. I will add a check for that.
