Remove (or move) VddPins from level0 test cases

[ramalho]

Forcing implementors to create VddPins and GndPins for all boards is a bad idea, but our test_list_pins currently forces it.

This is related to the issue of the definition of the board.pins, .all_pins, .digital_pins, .analog_pins attributes.

[danilobellini]

Seeing the test, I've seen a self.vdd_pin_number. Why such an attribute? The board might have more than one supply pin, e.g. a 3.3V supply and a 5V supply, which one that attribute would point to in this case?

[Vido]

Checking if a pin is a VddPin was done a very early stage on Pingo's testing code. It does not make much sense now.

[ramalho]

The fact is, representing the Vdd and GND pins is marginally useful in some
boards and completely useless in others.

It is marginally useful in the case of the Raspberry Pi and BeagleBone
Black because those boards have power pins mixed with the data pins in the
same connectors without any apparent logic, so listing them as part of
board.all_pins is useful to generate a visual map of the connectors.

But the Arduino and all boards that imitate it (pcDuino, UDOO, Galileo...)
have the power pins segregated and clearly labelled on the board itself, so
representing those pins in Pingo serves no purpose at all.

On Wednesday, May 7, 2014, Lucas Vido [email protected] wrote:

Checking if a pin is a VddPin was done a very early on Pingo's testing
code. It does not make much sense now.

—
Reply to this email directly or view it on GitHubhttps://github.com/garoa/pingo/issues/20#issuecomment-42386949
.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[danilobellini]

What doesn't make much sense is to have one single "vdd pin number" attribute (and the same for any other pin "type", including non-supply pins). For anything else, I strongly disagree.

Vcc/Gnd pins reflection helps us to know how many of such pins there are, besides knowing their voltage. One can use Pingo to compare different boards, to know about a board before buying it, etc.. But unfortunately that's still not possible now without reading the Pingo source (or reading some datasheet or other external information), since creating a Board instance isn't possible without some specific resource, but that's still a potential use case for Pingo.

VccPin and GndPin are useful at least for that "inspection" and "design" purpose. That's not "marginally useful in some boards" but useful for all boards, and really really useful in boards like RPi for which there's no label in the pins. It's like the physical-logical distinction, the Vcc/Gnd pins are as useful as the need for using physical numbering for pins. If one can find the pin by its logical numbering (looking for a image that maps that to the physical pin), the physical numbering also loses its sense.

In a later stage of development I think Pingo shouldn't assume that the user already have the board while programming: a new RaspberryPi() board instance should be possible even without GPIO and outside a Raspberry Pi, perhaps with a message "Not running on a Raspberry Pi" or "RPi.GPIO module not found", while keeping the interfaces useful for inspection (i.e., without raising ImportError or something alike).

Perhaps we should call these as SupplyPin and GroundPin, but VccPin and GndPin sounds good for me. FET-based ICs uses Vdd since it's supplying power for the "drain" in N-channel transistors, and BJT-based ICs uses Vcc since it's supplying power for the "collector" in NPN transistors, but for P-channel and PNP transistors probably these names doesn't make too much sense for a digital circuitry, and the same can be said for contemporary hybrid ICs. Anyhow, I think Vcc is a more used/common name than Vdd [or perhaps I spent too much time with BJT-based ICs, such as 7400 series TTL].

The board reflection (seeing what the board can do without reading a datasheet or looking to the board) is one of the main reasons I found Pingo useful, as I was mainly thinking on boards like RPi and BeagleBone Black. Even Arduino, how many people knows that A4 and A5 in Uno are used for I2C without looking for information at the arduino.cc web site? That's a kind of information I think Pingo should show. All board information should be together with Pingo, with a docstring that have the link for the web site or datasheet (as the source for that information) for a single and easy lookup (and comparison), as the user doesn't need to know how many Vcc/Gnd pins there are, nor their displacement on the board, unless he have an external mapping image or datasheet. Anyhow, that information is part of the idea of a single unified API for many boards.

[Not so sure about this single paragraph] In the future, knowing about Vcc/Gnd pins can also help for opensourcing hardware connections, keeping the hardware connection information together in the code (in a VHDL-like fashion). For some really simple circuitry, we can use that as a mock for tests, and perhaps some basic verification such as connecting LEDs might raise a "DamageError" that warns the user that a resistor is missing. Of course, that hardware description shouldn't be enforced, and such behavior makes sense as a subpackage.

[ramalho]

Please do not "strongly disagree". Just state your arguments rationally.
Declaring "strong disagreement" is a written form of shouting. It adds
nothing but heat to the discussion.

Danilo, as the strongest proponent of the power pin representations, I ask
you to create a branch for the arduino or pcduino package implementing the
kind of API you would like to see in Pingo to list all pins, just the
digital pins, just, the power pins etc.

Instead of debating in English (or Portuguese) I'd like to see code solving
practical problems such as how to describe, in pingo, the fact that the
Arduino has 3 GND pins in two different connectors.

Thank you for your contributions.

On Wed, May 7, 2014 at 11:20 AM, Danilo de Jesus da Silva Bellini <
[email protected]> wrote:

What doesn't make much sense is to have one single "vdd pin number"
attribute (and the same for any other pin "type", including non-supply
pins). For anything else, I strongly disagree.

Vcc/Gnd pins reflection helps us to know how many of such pins there are,
besides knowing their voltage. One can use Pingo to compare different
boards, to know about a board before buying it, etc.. But unfortunately
that's still not possible now without reading the Pingo source (or reading
some datasheet or other external information), since creating a Board
instance isn't possible without some specific resource, but that's still a
potential use case for Pingo.

VccPin and GndPin are useful at least for that "inspection" and "design"
purpose. That's not "marginally useful in some boards" but useful for all
boards, and really really useful in boards like RPi for which there's no
label in the pins. It's like the physical-logical distinction, the Vcc/Gnd
pins are as useful as the need for using physical numbering for pins. If
one can find the pin by its logical numbering (looking for a image that
maps that to the physical pin), the physical numbering also loses its sense.

In a later stage of development I think Pingo shouldn't assume that the
user already have the board while programming: a new RaspberryPi() board
instance should be possible even without GPIO and outside a Raspberry Pi,
perhaps with a message "Not running on a Raspberry Pi" or "RPi.GPIO module
not found", while keeping the interfaces useful for inspection (i.e.,
without raising ImportError or something alike).

Perhaps we should call these as SupplyPin and GroundPin, but VccPin and
GndPin sounds good for me. FET-based ICs uses Vdd since it's supplying
power for the "drain" in N-channel transistors, and BJT-based ICs uses Vcc
since it's supplying power for the "collector" in NPN transistors, but for
P-channel and PNP transistors probably these names doesn't make too much
sense for a digital circuitry, and the same can be said for contemporary
hybrid ICs. Anyhow, I think Vcc is a more used/common name than Vdd [or
perhaps I spent too much time with BJT-based ICs, such as 7400 series TTL].

The board reflection (seeing what the board can do without reading a
datasheet or looking to the board) is one of the main reasons I found Pingo
useful, as I was mainly thinking on boards like RPi and BeagleBone Black.
Even Arduino, how many people knows that A4 and A5 in Uno are used for I2C
without looking for information at the arduino.cc web site? That's a kind
of information I think Pingo should show. All board information should be
together with Pingo, with a docstring that have the link for the web site
or datasheet (as the source for that information) for a single and easy
lookup (and comparison), as the user doesn't need to know how many Vcc/Gnd
pins there are, nor their displacement on the board, unless he have an
external mapping image or datasheet. Anyhow, that information is part of
the idea of a single unified API for many boards.

[Not so sure about this single paragraph] In the future, knowing about
Vcc/Gnd pins can also help for opensourcing hardware connections, keeping
the hardware connection information together in the code (in a VHDL-like
fashion). For some really simple circuitry, we can use that as a mock for
tests, and perhaps some basic verification such as connecting LEDs might
raise a "DamageError" that warns the user that a resistor is missing. Of
course, that hardware description shouldn't be enforced, and such behavior
makes sense as a subpackage.

—
Reply to this email directly or view it on GitHubhttps://github.com/garoa/pingo/issues/20#issuecomment-42432589
.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[danilobellini]

Why I can't disagree? I'm being rational by disagreeing, who wouldn't? Yes, I'm disagreeing, I think that's a mistake, but you can disagree with me, as well. That's not irrational at all, and declaring such shouldn't, as well.

[ramalho]

I will not have discussions about discussions in issue comments. Let's focus on solutions, not problems, please. I'd like to see code. A few doctests with no need for a real implementation would refocus this discussion to the technical and usability issues it is really about. Can you do that, Danilo?

[danilobellini]

Arduino uses logical names (like A2, A3, 5V, IOREF, GND ...) for pins. Some time ago I argued for strings as a pin identification/indexing instead of integers, something like board.pins["A3"] for the fourth analog pin (as they starts with A0). The [already done] solution with an analog_pins property is great, but I think something alike is still needed for BeagleBone and boards for which the pins aren't "logically" classified and sorted on the board, unless we emphasize only a logical pin identification and get rid from the physical pin numbering (except perhaps for a Pin physical property as useful as the Vcc/Gnd pin). The real question is: should we care about physical pins at all? If so, I'd say it should be the same for both supply and non-supply pins.

Even for Arduino, I think we have something that ressembles the "physical pin" idea: PWM is available for the digital pins 3, 5, 6, 9, 10 and 11, that's not sequential nor "physical", but a logical pin relationship: the PWM pins are that digital pins, not that "physical" pins in the traditional sense, although they're labeled physically. I'd say that because IC and boards physical numbering usually doesn't start from zero and usually doesn't finish with names like GND, AREF, SDA, SCL, which aren't a "physical" location but a logical label. Also, few happens to know the circuitry to find which of these Arduino pins are tied together internally (I've already said something about SDA/SCL, the I2C pins). Physically, Arduino would have an uncommon description based on "top-left starting from 1" and "top-right starting from 1" (which is upside-down for digital pins) with a letter (L and R?) for side identification, or using acronyms from names like "before analogs" and "after digitals" (following the digital/analog numbering that is labeled before), or perhaps both (multiple indexing isn't bad, it might be helpful), when I'm trying to use a board I don't really care if the pin name/index is "purely physical" or not, but some physical reference is needed for finding it. Pingo should include all pins (the 3 GND ones) and should also tell which ones are the repeated ones (i.e., a single Pin instance might have more than one physical location, and more than one logical description simultaneously). Arduino would need a physical description to include the 3 GND pins, and I think such description shouldn't be nested (board -> connector -> pin). The connector being used can be a Pin attribute/property as well (I don't know if that's needed, so that might be left as a possible future feature).

I liked the idea of testing before, as it emphasizes the API, not the model. But the problem we're trying to solve is still the one of referencing/querying the pins (which probably should be discussed in another issue).