You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was discussed at the time when we implemented circuitpython_setboard but iirc we thought that it could lead to confusion and be more complex to support.
Having it be a comprehensive list means that it could list many pins and other properties that are not valid or relevant to the device the user has plugged in. Seeing things like board.I2C() and board.SPI() listed for raspberry Pi Pico and Pico2 could be very confusing for somehow who does not realize those device do not actually have a default I2C or SPI bus pins. Some boards with built-in hardware also have descriptively named pins like board.DISPLAY_SOMETHING or board.SPEAKER etc... I can see those being confusing for someone who doesn't understand the way the board stubs work and is new to electronics trying to hook up a display or speaker to a device that has only general IO pins, not ones with specific descriptive names.
Maybe as an alternative there could be some specific command to enable the "all pins" stubs. So if you want that behavior and opt in to it by running the command then you can have it. Perhaps circuitpython_setboard all or similar. I don't recall that option being discussed
Currently the user needs to run
circuitpython_setboard
in order to get usable stubs for theboard
module.Have you considered making the default
board/__init__.py
contain the constants for all different boards, something like https://github.com/thonny/thonny/blob/master/thonny/plugins/circuitpython/typeshed/stdlib/board/__init__.pyi ?IMO this would be more useful default.
The text was updated successfully, but these errors were encountered: