How to determine correct value for pwm_set_counter(...)

[git2212]

Hello,
I am looking to advance/retard a PWM signal on a given pin by using the pwm_set_counter(...) relative to a steady signal on another pin. These two pins are not on the same "slice" so independent setup and control should be possible.
My basic challenge is to map a given delay/advance time T to the correct values to send via the pwm_set_counter.

As the RP2040 uses an 8.4 fractional counter...and so forth, i hoped to be able to do this without being concerned about the PWM frequency just by factoring in the divisor for the slice which I can get from pwm_hw->slice[slice_num].div. I can advance/delay the PWM signal, but my math for determining the correct 'counter' value for a given T is embarrassingly wrong. The basic algo is here...

  uint32_t slice_clockDivide_hw = pwm_hw->slice[slice_num].div;
  uint32_t slice_hw_div_whole = ((slice_clockDivide_hw >> 4) & 0xFFFF);
  uint32_t slice_hw_div_fraction = (slice_clockDivide_hw & B1111);
  float nanos_per_ticks = ???
  uint16_t adj=(((float)T)/(nanos_per_ticks));

I am trying to pivot around the system clock and factor in the divisor... I get 200 for the whole portion of the fractional divisor and 128 for the fraction part, they appear to be legit values... So the missing math is where it's at... I am suspecting now that this can't be done without considering the PWM signal frequency and possibly the duty cycle as well as the meaning of the divisor to the counter does not appear to be constant. Getting this working in phase corrected mode would be ideal.

Any suggestions would be appreciated
Thanks.

[earlephilhower]

You might have better luck at the Raspberry Pi forums since this is a low-level HW question.

[git2212]

Yep, that's where I started (and other forums), since PWM phase shift is not often discussed I figured I'd post here where the cool kids hang out lol.
so to be fair, I did find a solution that works for me and I am posting the relevant excerpt of the code below for anyone else who might be interested... most of the code is sanity checking for development mode only but left it in there anyway... and I hope my extensive comments won't offend anyone but I am well past the age where I hope to remember what I've done yesterday let alone why lol ... all I can say is we aught to have a cosmic law (as immutable as gravity) about keeping the marketing people away from technical documentation :), the PI specs and other relevant documentation is unnecessarily fluffed up with irrelevant details (e.g. delta-sygam blah, blah) of no practical relevance.

    //
    // this section gets confusing a bit because the RP2040 uses a fractional clock divider in combination with a counter to 
    // manage PWM signals, delta-sygma yadayada, see section 3.6.8. PWM in https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf, 
    // so we would expect the need for a complicated algo.
    // 

    // simply put, we need to determine how many "counts" we need to advance/retard the PWM signal and feed that to the PWM subsystem, 
    // it turns out that all we have to worry about is  
    //
    //  1. the TOP value 
    //  
    // The TOP value is used by the PWM HW to determine when a full period T of a PWM signal is reached, so effectively the 
    // counter oscillates between 0 to TOP
    // the elegance and simplicity of this approach has a tendency to go out the window if you try to use it with phase-correct or 
    // inverted PWM mode and other frivilous features of limited practical value
 
     #if defined(DEBUG_INVERTER_CTRL) && DEBUG_INVERTER_CTRL>0
        // this should not happen but sanity check anyway during development ;) 
        volatile uint32_t phaseCorrectOn = pwm_hw->slice[slice_num].csr & PWM_CH0_CSR_PH_CORRECT_BITS;
        if(phaseCorrectOn!=0){
            // speaking of phase corrected output and shortcuts taken by the chip designers to the misery
            // of us all to deal with later... this mode halves the output frequency and other oddities :0
            // who wants to deal with that s*** when it's more trouble than worth?
            // turn off both outputs as a safety measure and abort
            digitalWrite(_pin_out[0],LOW);
            digitalWrite(_pin_out[1],LOW);
            __my_assert("Phase shift not tested in this phase-correct mode!",__FUNCTION__,__FILE__,__LINE__);
        }

        volatile uint32_t phaseInvertOn=0;
        if((pin%2)!=0){
            // no macros defined by the PI libraries so we use hard coded values as per data sheet
            phaseInvertOn = pwm_hw->slice[slice_num].csr & 0B0100;
        }else{
            // no macros defined by the PI libraries so we use hard coded values as per data sheet
            phaseInvertOn = pwm_hw->slice[slice_num].csr & 0B1000;
        }
        if(phaseInvertOn!=0){
            // turn off both outputs as a safety measure and abort
            digitalWrite(_pin_out[0],LOW);
            digitalWrite(_pin_out[1],LOW);
            __my_assert("Inverted phase mode is not implemented!",__FUNCTION__,__FILE__,__LINE__);
        }

        volatile uint32_t fractionalDiv=pwm_hw->slice[slice_num].div & PWM_CH0_DIV_INT_LSB;
        if(fractionalDiv!=0){
            // not supported yet
            digitalWrite(_pin_out[0],LOW);
            digitalWrite(_pin_out[1],LOW);
            __my_assert("Fractional DIV mode not supported!",__FUNCTION__,__FILE__,__LINE__);
        }
    #endif

    volatile uint32_t slice_top_hw = pwm_hw->slice[slice_num].top;
    volatile float pwm_freq=(pin==_pin_out[0]?_frequency[0]:_frequency[1]);
    volatile float nanos_pwm_period=1e9/pwm_freq;

    // normalize our phase shift nanos to the PWM signal period
    while(nanos>=nanos_pwm_period){
        nanos-=nanos_pwm_period;
    } 
    if(nanos==0){
        // nothing to do
        return true;
    }

    // the real magic here... convert nanos to an adjustment value
    volatile float nanos_per_count=nanos_pwm_period/slice_top_hw;
    volatile float adj=nanos/nanos_per_count;
    
    // due to the way the PWM hw works we need the one complement value
    adj=slice_top_hw-adj+1; // +1 to ensure we are rounding up
    
    // stop the PWM while we advance/retard the counter, then restart it
    // we'll stop/start on all pins to ensure they will not be out of sync
    noInterrupts();     // critical section so no interference please
    pwm_set_enabled(slice_num_1,false);
    pwm_set_enabled(slice_num_2,false);
    // we could set all pins low as the PI spec sheet suggests, short answer don't it throws everyting out ow whack
    #if defined(DEBUG_INVERTER_CTRL) && DEBUG_INVERTER_CTRL>0
        volatile uint16_t c_now = pwm_get_counter(slice_num); 
    #endif
    pwm_set_counter(slice_num,adj);
    pwm_set_counter(slice_num==slice_num_1?slice_num_2:slice_num_1,0);
    pwm_set_enabled(slice_num_1,true);
    pwm_set_enabled(slice_num_2,true);
    interrupts();       // back to normal

[git2212]

The results for those more visually inclined