Add function to enable multiple PWM slices at the same time

[jlpettersson]

This is needed to be able to have e.g. 3 PWM slices that are in phase, but may use different duty cycles.

Example usage: pwm_slices.enable_simultaneous(0b0000_0111);

Demo

Phases between slices before this fix, using

    pwm0.enable();
    pwm1.enable();

Phases between slices after this fix, using

pwm_slices.enable_simultaneous(0b0000_0111);

[ithinuel]

Thank you for your contribution.

I would've expected to find this as a type-level slice group operation.
This would save one to have to figure the right bit pattern.

Also, don't we need a way do synchronously disable them as well?

[jannic]

I would've expected to find this as a type-level slice group operation. This would save one to have to figure the right bit pattern.

I agree that the API could be more user friendly. However, as I have no idea how much effort such a better API would be, I wouldn't reject this simple API.

Also, don't we need a way do synchronously disable them as well?

Not necessarily. The reason for synchronously enabling the signals is not to avoid a few cycles of delay between them becoming active, but to make sure the pulses are in phase. That's not an issue when turning the signals off.

[jannic]

It is possible to implement a function without a bit pattern parameter like this:

    pub fn enable_simultaneously(&mut self, slices: &[&dyn SliceBitmask]) {
        // Enable all slices at the same time
        let bits: u32 = slices.iter().fold(0u32, |a, b| a | b.bitmask());
        unsafe {
            let reg = self._pwm.en.as_ptr();
            write_bitmask_set(reg, bits);
        }
    }

with

impl<I, M> Sealed for Slice<I, M>
where
    I: SliceId,
    M: SliceMode + ValidSliceMode<I>,
 {}
 
pub trait SliceBitmask
where Self: Sealed
{
    fn bitmask(&self) -> u32;
}

impl<I, M> SliceBitmask for Slice<I, M>
where
    I: SliceId,
    M: SliceMode + ValidSliceMode<I>,
{
    fn bitmask(&self) -> u32 {
        self.bitmask()
    }
}

However I think that it's still not a nice API, because you need references to both Slices and to the individual Slice instances which are also part of Slices. This easily leads to borrow checker issues like "error[E0502]: cannot borrow pwm_slices as mutable because it is also borrowed as immutable".

[thejpster]

I can't tell the difference between the two photos, but the diff looks OK to me.

[jlpettersson]

@thejpster ah, I should have explained the pictures better.

The purple square wave is not centered (exactly in phase) within the cyan square wave. In the first picture, the purple is a little bit to the right, but in the second image, it is perfectly in the center of the cyan square wave. (because in the second picture, this feature was used to start the square waves in an atomic operation.

Perhaps this part of the first image explains it best, that the purple square wave are not in phase.

[jannic]

I placed this in milestone 0.10.0 for now, just to make it obvious that 0.9.0 doesn't need to wait for this PR. It's not a breaking change and can be applied at any time.