Support for different PWM pins configurations out of the box

[katyo]

I think this is quite usable thing here.

[katyo]

This PR doesn't includes doc updates yet.

[TheZoq2]

Looks pretty similar to my attempt in #120, except yours is shorter and easier to read 👍.

Is there a reason you decided to use a trait for the remap stuff instead of just passing the bytes to the macro directly? I think that would be more readable.

[katyo]

Hmm, maybe. It seems it looks like most obvious solution.

[katyo]

My solution is not optimal because I introduced special type for mapping (remap).
Actually, I think we can (and should) avoid it.

Becaue it hard to solve using macro rules so I defined types for mappings to complettely avoid this problem.
I haven't know the easy ways here. Maybe it's time call for help build.rs? :)

[TheZoq2]

I think you can get rid of the extra Remap trait by doing this:

    ( $( $TIMX:ident: $REMAP:expr ( $( ( $($PINX:ident),+ ), ( $($ENCHX:ident),+ ), ( $($DISCHX:ident),* ); )+ ); )+ ) => {
        $( $(
            impl Pins<$TIMX> for $($PINX<Alternate<PushPull>>,)+
            {
                const REMAP: u8 = $REMAP;
                $(const $ENCHX: bool = true;)+
                    $(const $DISCHX: bool = false;)*
                type Channels = ($(Pwm<$TIMX, $ENCHX>),+);
            }
        )+ )+

With that change, and the docs update, this will be good to merge in my eyes

[katyo]

This doesn't work because as I say before it produces same implementations of Pins trait for similar mappings with different pin sets.
I added remap ID to tuple to avoid it.

[TheZoq2]

Ah, makes sense. So users would have to specify the remap trait?

Could you do something similar to what I did in my PR where there is a special pins_impl which only impls the pins that change during a partial remap?

[katyo]

Of course, I tried to write something similar to it, but in a result it is tricky or not so clear macros.

Maybe enumerating all available configurations in macro invocation is a trade-of solution in this case.

[TheZoq2]

Maybe enumerating all available configurations in macro invocation is a trade-of solution in this case.

I think that's fine. This macro won't be seen by users, and I don't think we'll be modifying it much

[TheZoq2]

Since #147 which does the same thing is now merged, i'll close this in favour of that