PinName vs PinNumber

[nedseb]

I'm working on a fork of the target codal-stm32 to support the STM32L475. I'm trying to implements Serial class and I stuck on some apparently simple problem but from now I don't understand if the distinction between PinName and PinNumber.

In the constructor of the class Serial, the type of the parameters is PinName :
https://github.com/lancaster-university/codal-core/blob/master/inc/driver-models/Serial.h#L113

But in the abstraction of pins, the type PinNumber is used :
https://github.com/lancaster-university/codal-core/blob/master/inc/driver-models/Pin.h#L115

To add to my confusion, the abstraction for the I2C uses the Pin class which seems more natural :
https://github.com/lancaster-university/codal-core/blob/master/inc/driver-models/I2C.h#L43

Should not we refactor the serial class to gain homogeneity? I guess with MBed the problem does not arise but in my case my goal is precisely not to depend on Mbed ^^

If I prepare a PR with the refactoring introducing Pin in place of PinName, is there any chance that it will be integrated?

[jamesadevine]

@nedseb You're absolutely right about there being some confusion in the distinction between PinName and PinNumber.

PinName as you correctly point out is an mbed-ism, and should be dropped from the high level abstractions. The serial class should also be refactored to use Pin instances like the I2C interface, rather than PinName.

As an abstraction layer it should be our goal to not depend on mbed either, and i think this is just a case of not getting round to it yet. 😄

We would welcome a PR!