Same for PinModes; why define SDA and CLK (and others) where you will never access these pins directly in that function.
The main purpose of the board model is to document the concrete board type and its connected��peripherals. The idea is to see in the inspector exactly what you see in docs but with possibility to get much more information because it is a live view on the board state.��
Currently most of PotGPIOFunction's��are only used to show the pinout in inspector. But who knows what we can get from them in��future.
��
I am interested in this PinMode stuff because you also run into that when you want to handle the Firmata capability-report-request. How do we handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a situa'tion that can very well occur in practice)
Do you have an example? I did not see how it is related to the board model.
Firmata has a�� "capability request"�� where it tells you for every pin what its present mode is, and what other modes it supports. In Firmata a mode is just a number (from 0 = digital input to 11, which includes PWM. Servo, OneWire, I2C, Stepper, ...). I can make these available to the caller, including putting them in FirmataConstants. But I wondered if I could use the Pharothings framework of PotGPIOFunction and PotIOPinMode to bring it in line with PharoThings. Of course I can read the sources, but maybe a short explanation from your side can save me a lot of time. Does PharoThings have the concept of capabilities, that is, a list of possible/allowed��pinmodes for each pin of a board?
Possibly you��will��need to��extend the design to address your needs.��Current model only covers what there��were in our hands:
Board classes define a configuration of pins where they specify a function for every pin. There is only function��for given pin (where PotBasicIOFunction is a default value).��
Functions have not much��responsibility now. They are mostly here for documentation purpose: having the board instance it should be clear what pins are able to do.
I can imagine that we should allow pins to have multiple functions.
IO mode of the pin (PotIOPinMode) is low level thing to implement input/output operations with pins. From the other side they represent how we can interact��with pin��and��It looks like a function. Maybe they can be merged. But that is what we have now.
��
About��"capability request". It would be cool to not specify pin scheme manually.
You can just request pinout/functions in YourBoard>>connect method.