��Is there any documentation of the design of PharoThings, especially because there are no class comments or other explanation.
No documentation of design, sorry. Or maybe Alex wrote something but it was probably examples.
It's definitely should be fixed but I have no time for this now.
��
For example: I would like to know why the connector class exists. Why can't boards simply have pins?
Connectors represent��physical connectors on the board. My first Raspberry was model��B revision��2. It��has two connectors P1 and P5. In different docs such "local group of pins" are named differently. I chose the "connector" name for this.
Connectors are needed to show the pinout scheme of the board like in docs.
��
After all, it seems irrelevant to the working how they are physically exposed. And when I also see a Header class I get confused.
You probably��mean GPIOHeaderReference and subclasses. There are various ways to reference GPIO pins using physical location:��
- by absolute��number of header considering the order from the left to right and from the top to down
- by row/column position on the connector (there are two columns and multiple rows depending on the connector configuration).
So subclasses of��GPIOHeaderReference represent these types of references. They are about physical location of GPIO pin headers.����
In the code they allow to get pins from the board:
(There are PotBoardTests with these examples)
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 situation that can very well occur in practice)
Do you have an example? I did not see how it is related to the board model.
��
That's it for the time being
Rob