Update board itself instead?

[tannewt]

Hi! Could we update the board definitions in CircuitPython to ensure a consistent naming instead? That way everyone can benefit from consistency without needing a separate library.

[Gadgetoid]

Is it possible to enact this kind of update? Presumably it would break backwards compatibility with libraries or code expecting a certain pin to exist under a certain name?

This seems like it would be a favourable approach though- since @Septolum has done the legwork to understand the problem I guess we'd have a pretty good starting point.

[tannewt]

Pins can have multiple names in board so we’d just add the news ones. The biggest hurdle would be if we are short on space. Thanks!

…

On Tue, Oct 1, 2019, at 5:29 AM, Philip Howard wrote: Is it possible to enact this kind of update? Presumably it would break backwards compatibility with libraries or code expecting a certain pin to exist under a certain name? This seems like it would be a favourable approach though- since @Septolum <https://github.com/Septolum> has done the legwork to understand the problem I guess we'd have a pretty good starting point. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=AAAM3KOMPDLRQATTQ3GCL2LQMM7CPA5CNFSM4I4AXR72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEABCY4I#issuecomment-537013361>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAM3KKK4ROV7AXS32GQVSLQMM7CPANCNFSM4I4AXR7Q>.

[Septolum]

How do you suggest this be implemented?
As a modification to each board's pins.c file, or as a separate part of board, or something else?

[tannewt]

As a modification to each board's pins.c file. We should document it somewhere too.

[Septolum]

While this sounds great, my only concern is that you would lose the verbose error messages when a user tries to use a pin that doesn't exist or is unusable on that board.

[tannewt]

We've been doing with pin names in the board module for three years and I haven't seen anyone have that confusion. For missing pins, an AttributeError is raised. Doing it a different way here means that all of the existing tutorials won't apply.

Are there specific pins that don't already have a consistent A# or D# name?

[dglaude]

My Enviro+ Featherwing is coming, and it seems to be only using pimoroni_physical_feather_pins.
There is one issue relative to Airlift Featherwing and pin D11 beeing already in use:
pimoroni/EnviroPlus-FeatherWing#4

Searching the Enviro+ library to see where D11 is use is not easy... because it is hidden behind pimoroni_physical_feather_pins.

[ladyada]

@tannewt while we're waiting for a possible change to feather pinning - perhaps it would be best to at least get this library cookied & into the community bundle?

[Gadgetoid]

I have a few fixes I need to unpick from https://github.com/pimoroni/Pimoroni_CircuitPython_LTR559 for the CircuitPython CookieCutter repository and add to a PR, if that's what you mean. It's understandably very Adafruit centric (who knew! haha).

Actually- figuring out how to get things into the community bundle is on my TODO list, especially for that aforementioned LTR559 library.

@tannewt has been extremely helpful and supportive thus far, though, so it should be plain sailing. Actually dragging my rusty old brain into the CircuitPython ecosystem has been quite difficult but Im very keen to get the basics right since it would be nice to bring our Breakout Garden modules along for this ride.

Thank you for weighing in on this too @ladyada - I notice you crop up from time to time as our worlds collide and it's appreciated. While I'm not out of my technical depth here, I think I'm straying outside the realm of what a single brain can juggle!

(P.S. CLUE is just... wow... just... I half expect to find a kitchen sink silked on there somewhere)

[ladyada]

sounds like a plan! while CircuitPython is a little different, the benefits are cross-platform libraries that work on any single board linux computer, microcontroller or desktop & we feel that those benefits outweigh the learning curve

[Gadgetoid]

It's a little off topic, but I must add that I'm keen to continue maintaining non-Blinka dependent libraries first and foremost because they more closely align with the vast amount of educational material, blog articles and such that surround the Raspberry Pi ecosystem- and they give me free reign to do things I simply cannot do on CircuitPython (USE ALLLLL THE RAAAAAAAAAAAAM). And, also, because I've invested a lot of time training my brain to breeze through them and perfecting the tooling to make them happen.

However! I certainly recognise the benefit of libraries that can be handily moved from one platform to another. It'll probably be my undoing maintaining two sets but there's a lot of overlap between the devices we support so I don't suspect it'll be as onerous as I might think.

[Gadgetoid]

Have begun the cookie process here - https://github.com/pimoroni/physical_feather_pins/tree/cookiecutter

[dglaude]

I only need Physical Feather Pins for the screen/plotter library of Enviro+ and some other use like gas sensor.
Waiting for better solution or the final move from Envori+ away from this library, I have just added FeatherS2 #4 and previously I added STM32 too.
While I am not totally sure I like this library, it might make sense for FeatherWing maker to not have to worry about the name of pins in each in every Feather but just use the position. It might not be needed for already well known pin like SDA, SCL, TX, RX, ... but for the other I can see the benefit.
But for this to make sense, it must be present on more board and Pimoroni only support very few for their Enviro+ board. So it is a bit chicken and egg problem... I guess if this idea good, the push should come from Adafruit.

[ptbw]

@Gadgetoid
I added an rp2040.py for the Feather RP2040 using the board (ie board.A0) designations to get the Enviro+ lib to work with it. Happy to do a PR if you want it.

[dglaude]

Please do provide a PR.
I could even give it a try as I have the needed hardware, and this will make Phil work easier.

However, the goal is to move away from using this library at all, and if something is needed, put it in CircuitPython directly.
There was heavy work to rewrite the Enviro+ to use native CircuitPython Library from Adafruit bundle, or Pimoroni Library accepted in the community bundle. I believe everything needed is available to not use this, it just lack documentation on the right way to do it, adaptation of the example, ... there might even be a PR that just need to be accepted.

So that you can do board.xxx and have the expected pin, whatever the board.
The most standard Feather is M4 and most board match that for Axx, Dxx, TX, RX, SDA, SCL, MOSI, MISO, ...
The notable exception the Feather S2 that use some of the same Dxx but at different location than the M4 does.

[ptbw]

Done, I have no way to test the PMS5003 sensor but the rest of the Enviro+ seems to work fine, with the supplied example.

[Gadgetoid]

However, the goal is to move away from using this library at all, and if something is needed, put it in CircuitPython directly.

Absolutely. I'm already at about 10,000% capacity so any nonsense like this I can get shot of is an enormous win. Trouble is I'm at 10,000% capacity so finding the time to play my part in this is... tricky!

Thank you all for helping move this forward!