Gpio: use less unsafe code

[aurelj]

No description provided.

[therealprof]

Please let's not do this. The macro code is already close to unreadable as it is, I'd rather have less than more of it... We already have the pin number in macro call, is there no way to use that information to generate the required places in the macro?

[aurelj]

Hum... The heart of the macro code itself is quite a bit more readable after the change I think. Compare:

&(*$GPIOX::ptr()).moder.modify(|r, w| { w.bits((r.bits() & !(0b11 << offset)) | (0b01 << offset)) });

vs.

gpio.moder.modify(|_, w| { w.$moderi().output() );

And overall those patches are removing 7 lines of code, so it is actually less of it...

Now, if you are talking about the calls of gpio!(), yes this is a bit ugly with quite some redundancy. I've tried to get ride of it, and making those calls much cleaner and simpler using an intermediate macro that would expand all the fields identifier for just the pin number. Unfortunately I've not found any viable stable rust way of doing it. The paste crate looks promising but unfortunately it doesn't seem to work along with a #![no_std] crate. Anyway, that's something that can be improved in the future.

But overall, I think that's a small price to pay for less unsafe code, less lines of code, and more readable code.

What do you think ? Any idea to improve on this ?

[therealprof]

@aurelj I'm not sure yet, make it would make sense to have two types of pins with their own impls in the background, a low kind (using afrl) and a high kind (using afrh) (potentially derived from a generic version for less code duplication).

In general I'd like to see minimised macro use since they inflate compile times and are incredibly painful to read and debug, cf. #37

[aurelj]

@therealprof Indeed, the idea in #37 is quite interesting. I guess it won't be that easy to do the same for gpio as there are separate gpioa::RegisterBlock, gpiob::RegisterBlock and another gpio RegisterBlock that is different on each stm32f4 device.

But anyway, I will give it a try at some point, so for now, you can consider this PR on hold.

[TeXitoi]

Any update on this? or we can close it?

[aurelj]

I think the idea behind this patch is still worthwhile, but it is not a good idea to pursue before trying to reduce macro usage as much as possible.
So yeah, better closing it.