hippy
Posts: 5786
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 2:11 pm

jamesh wrote:
Mon Apr 02, 2018 10:42 am
Just out of interest, what is the lack of information stopping you from doing? Huge numbers of people use the GPIO's successfully with the available documentation, so I'm just trying to see what particular circumstances you have that mean you are unable to proceed.
For me the problem of not having full electrical specs comes when stepping away from the recommended or approved way of doing things.

For example I can expect the Pi's GPIO to work as expected if I connect that to a MAX3232 or similar, but I cannot determine for myself what the situation would be if I wanted to use a current limiting resistor to interface to an 'out of spec' voltage.

I know I "shouldn't do that", "that's not recommended", "not best practice", but I want to know if it can be done, what the limitations are, and likely consequences if it is done that way, just as it has been done on many other microcontrollers and other logic circuits.

I am not interested that I should not do it, is not recommended, may be bad practice. I want to be able to assess what would happen if I should try it. It should be up to me what I consider acceptable for my use case. Without a full electrical spec I cannot make an informed decision.

That informed decision is achieved with other microcontrollers by referencing their full electrical specs. Without the Pi's full electrical specs one cannot make make an informed decision. That leaves experimenting in the unknown, risking unnecessary damage, or not even attempting it.

People can say I can't do it, or I can, the electrical specs are what would allow me to decide for myself whether I can or can't, should or shouldn't, would let me to assess the risk of doing that.

From a software engineering perspective; it is perhaps like deliberately not documenting 'rm -rf /'. Will that instantly do what might be expected or are there protections to prevent the damage which could be done ? Without the documentation one can only say 'don't do it' to be entirely safe or chance it.

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 2:48 pm

> What I don't understand then is how when something so apparently fundamental is missing, so
> many people have successfully used, and how so many have manufactured boards, that use the
> GPIO without actually having any problems. Like, millions of people.

The short answer to the impression you have is that the vast majority of manufactured boards interface the RPi I/Os to chips that accept or produce 3.3V-logic levels of one or another family. With no other load, every 3.3V family can talk to every other one. So those scenarios all work without needing to look at the RPi DC Electrical specs.

But one attraction of the GPIOs for makers is that you can directly breadboard them up to a wide variety of devices other than 3.3V logic. That's the set of scenarios that I gave you examples of in previous posts. And sure, a million people connecting things by trial and error will get lots of things to do something resembling working, sometimes by luck or by following a recipe that someone else has tried, and they also have low expectations and inclination to ask for better info when things don't work.

If you were to assert that a sample of a million people would hook up RPi GPIOs to those sorts of non-3.3V-logic devices "without actually having any problems", I think you would be a long way off the mark by many orders of magnitude.

hippy
Posts: 5786
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 2:56 pm

jamesh wrote:
Mon Apr 02, 2018 2:04 pm
What I don't understand then is how when something so apparently fundamental is missing, so many people have successfully used, and how so many have manufactured boards, that use the GPIO without actually having any problems. Like, millions of people.
One analogy may be cars. Millions are sold and millions of people use them without having any knowledge of their vehicle's full specification. In fact probably without being aware of any specification or limits at all.

Take "absolute maximum RPM". Most people have no idea nor care; there's a red line on their tacho they don't go past, or only briefly. They stay within the confines of the spec so never have any problems. Millions are happy. Millions of cars get sold.

But there is a minority who want to know what the maximum RPM is, how far or for how long they can push beyond the red line. It doesn't matter why, only that for them they do want to know, need to know if they are planning to do that.

Take "absolute maximum fuel capacity". Again something few need to worry about but there are some cases where it helps to know, is needed to be known if trying to reach it but not exceed it.

The fact that something is not a problem for most people doesn't mean it isn't a problem for others.

There's another analogy in elections in "constituency numbers". Few of the electorate need to know how many are in the constituency, but it's essential information for those who do.

That millions can carry on regardless without some specific information it doesn't mean that all can.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23377
Joined: Sat Jul 30, 2011 7:41 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 4:14 pm

Insurmountable wrote:
Mon Apr 02, 2018 3:09 pm
I completed my HND in electronic engineering in 1992, we had to produce a product manual and spec sheet or it was a fail, that was a large chunk of the course marks. And you had to calculate the specs using statistics none of this just add a bit extra for good luck BS. I have over-clocked PCs and they ran for years before they finally started to play up.

Some of use haven't got years to fully test a product so specs and statistical analysis are important if you want to produce a reliable product. Just because something works fine in chilly England does not mean it will perform equally as well in the deserts of Dubai. How would you know ? By making sure you don't exceed the max ratings for components. What appears to be the max rating from bench testing a component will be a lot higher than what the actual max rating to get a lifetimes use out of it.

I went onto work in the aerospace and nuclear power industries, we would put Polonium in the Broadcom reps tea if they tried to sell us something with out scientifically calculated specs.
I'm a big fan of the Pi, but I wouldn't recommend it be used in safety critical nuclear or aerospace roles. With or without the GPIO specs.

Note though, that we do test the device as a whole for emissions, and do meet various ISO specs for vibrations and environment. The Pi Itself we would expect to last for about 30 years, probably a bit less now we are pushing the clock speed boundaries.

ALso note, the SoC used was originally intended for mobile devices, which is standard logic throughout, so some of the proposed use cases mentioned above will not have been considered when the chip was designed. Which is a roundabout way of saying I am not even sure if the specs required actually exist. I presume they do, but whether I can get hold of them is another matter. They may be hidden in the files at Brcm, or in minds of the guys who designed the GPIO block. I guess that is a side effect of using a chip in something it was not originally designed for, but of course, if we hadn't done that the Pi wouldn't exist anyway, it was the only way to get the price to where it is.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
davidcoton
Posts: 4027
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 5:32 pm

jamesh wrote:
Mon Apr 02, 2018 4:14 pm
ALso note, the SoC used was originally intended for mobile devices, which is standard logic throughout, so some of the proposed use cases mentioned above will not have been considered when the chip was designed. Which is a roundabout way of saying I am not even sure if the specs required actually exist. I presume they do, but whether I can get hold of them is another matter. They may be hidden in the files at Brcm, or in minds of the guys who designed the GPIO block. I guess that is a side effect of using a chip in something it was not originally designed for, but of course, if we hadn't done that the Pi wouldn't exist anyway, it was the only way to get the price to where it is.
That is precisely the point of electrical specs. No-one can expect the manufacturers (in this case Broadcom) to anticipate every possible use of their product. But by publishing the specs (which should be known and documented internally as part of the process of making it work in standard configurations), Broadcom enable the user to design their application to work under the required range of conditions, without having to ask Broadcom to validate every proposed design. It's the equivalent of a software module's interface spec, which enables software engineers to spot holes in functional requirements long before the software is written. How much pain would be saved if that was done properly each time?
Signature retired

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23377
Joined: Sat Jul 30, 2011 7:41 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 7:24 pm

davidcoton wrote:
Mon Apr 02, 2018 5:32 pm
jamesh wrote:
Mon Apr 02, 2018 4:14 pm
ALso note, the SoC used was originally intended for mobile devices, which is standard logic throughout, so some of the proposed use cases mentioned above will not have been considered when the chip was designed. Which is a roundabout way of saying I am not even sure if the specs required actually exist. I presume they do, but whether I can get hold of them is another matter. They may be hidden in the files at Brcm, or in minds of the guys who designed the GPIO block. I guess that is a side effect of using a chip in something it was not originally designed for, but of course, if we hadn't done that the Pi wouldn't exist anyway, it was the only way to get the price to where it is.
That is precisely the point of electrical specs. No-one can expect the manufacturers (in this case Broadcom) to anticipate every possible use of their product. But by publishing the specs (which should be known and documented internally as part of the process of making it work in standard configurations), Broadcom enable the user to design their application to work under the required range of conditions, without having to ask Broadcom to validate every proposed design. It's the equivalent of a software module's interface spec, which enables software engineers to spot holes in functional requirements long before the software is written. How much pain would be saved if that was done properly each time?
I think that the point I was trying to make (although yours is completely correct) is that because the SoC was designed to work in very particular circumstances, there may never have been a need to have those specs. Just trying to soften the landing when/if I cannot find them....
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
bensimmo
Posts: 4157
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Mon Apr 02, 2018 7:41 pm

But wouldn't the specs have been needed by the people, mobile or not, to create their mobile design in the first instance and your hardware team to use the gpio in the way they do.

I doubt they would want to stick an LDR and a resistor in a potential divider circuit and guess when the LDR will turn the gpio on/off like we currently have to or guess if they will always have that led running at it brightest yet not over run the gpio current.

As far as I know all of that is through trial and error I know fore it is but we'll withing guessing not to push it from.hearaay on forums/tutorials, I have high powered LEDs but do not know if I can use them and how bright I can run them since there is no simple lookup document telling me what I can draw from the gpio or even through the 3V3 line or when the 5V line will stop or overheat the board.
(I have two high power IR LEDs that make a PiZero get very hot. What is the 5V line specification designed for on the PiZero form example)

It a bit like using an API but not actually knowing what the limits are, is the number 0-255 or 0-512, are the number in 1 steps or 32 steps for some output and how fast can it be updated.

Look forward to seeing what you can find out when back at work.
(I assume it's a long weekend holiday for you too).
Most of it not highly important for me or I may just have missed this official specification
As trial and error get simple for a hobbiest to gets answers and frying a board is seen as part of it ;-)

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 4:22 am

jamesh wrote:
Mon Apr 02, 2018 7:24 pm
The GPIO are directly wired to the SoC on devices up to 3, on the 3 there
is a GPIO expander for some pins, but I'm not sure what that covers.
I missed this earlier. Thanks for this nugget, which increases the desirability of DC Electrical Characteristics.
jamesh wrote:
Mon Apr 02, 2018 7:24 pm
Also note, the SoC used was originally intended for mobile devices,
Yes, SoCs market is substantially driven by mobile.
jamesh wrote:
Mon Apr 02, 2018 7:24 pm
Which is standard logic throughout,
Though 3.3V is becoming unusual these days, others use 1.8V or lower for low power in mobile applications. Which is harder to work with for "general purposes".
jamesh wrote:
Mon Apr 02, 2018 7:24 pm
so some of the proposed use cases mentioned above will not have been considered when the chip was designed.
Right. That's why it's called General Purpose I/O. It's provided with characteristics that are expected to be Generally Purposable for a range of applications :-). And those are the characteristics we'd like to know. While it's true that the specs are unlikely to stray far from one or another 3.3V logic family, that leaves sufficient latitude that guesswork is involved.
jamesh wrote:
Mon Apr 02, 2018 7:24 pm
Which is a roundabout way of saying I am not even sure if the specs required actually exist.
I presume they do, [...possibly...] hidden in the [...] in minds of the guys who designed the GPIO block.
[...] because the SoC was designed to work in very particular circumstances,
there may never have been a need to have those specs
Chips like this are generally designed in a development environment from libraries of modules ("IP" -- Intellectual Property), where every aspect of each module is characterized and simulated in software. So not only are the specs of interest written down somewhere, they are either fixed characteristics or adjustable parameters of the model used to produce the chip in the first place. It might even be the case that RPi engineers supplied some of these specs as requirements to Broadcomm for the version customized for RPi, if that's indeed how it went. Much of the docs is generated automatically from the model.

As others have opined, it is virtually certain that Broadcom would have supplied RPi hardware engineer(s) with the DC Electrical Characteristics and Absolute Maximum Ratings (and much much more). Other products with ARM-based SoCs, and SoCs and MCUs in general, all have docs that spell this out in detail, as I referenced earlier with the Qualcomm SoC. That's the kind of doc that Broadcom would have supplied to RPi engineers.

User avatar
karrika
Posts: 1063
Joined: Mon Oct 19, 2015 6:21 am
Location: Finland

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 5:11 am

+1

Almost every user who is just trying to add a push button is hit with the fact that the GPIO pins have a grey area of voltages where the value oscillates. It has been well documented by paulv in this forum.

viewtopic.php?f=29&t=133740

I assume that understanding the shortcomings of GPIO pins affect the software and invites designers to use external electronics to increase long time reliability of the application.

The good thing is that after this research was made it was trivial to add countermeasures into the software. Before I had an occasional glitch triggering some effects at the theater. After adding hysteresis in the software the Pi works perfectly.

In the future I want to do the fix in external hardware. But before designing it I am also interested in proper interfacing of high speed 2 way UART (250 Kbps). Good specs for BCM 14 and BCM 15 would be valuable.

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 5:50 am

> "use the GPIO without actually having any problems. Like, millions of people."
karrika wrote:
Tue Apr 03, 2018 5:11 am
+1
Almost every user who is just trying to add a push button is hit with the fact that the GPIO pins have a grey area of voltages where the value oscillates. It has been well documented by paulv in this forum.

viewtopic.php?f=29&t=133740
And thank you karrika for providing an example of a bunch of relatively thoughtful users stumbling around in the dark due to lack of basic documentation, over that absolutely most basic input scenario -- connect a switch. Entirely duplicates the fumbling that I've personally witnessed others succumb to.

And before anyone thinks that the referenced post solves the issue by providing suitable specs: No it does not. It can't even come to a conclusion whether the inputs have hysteresis. At Jan 23, 2016 7:42 am Paulv asserts that they do, though his evidence is data that doesn't make sense. Then at Jan 24, 2016 1:59 am he shows evidence that indicates the inputs don't have hysteresis. Either that, or in one or both posts there's something else wrong with his test cases. (And FWIW, if inputs do not have hysteresis, none of the "capacitor filter" solutions are acceptable.)

Even if he had clean data and clear conclusions for his device under test, this still would not substitute for the manufacturer specs, which encompasses the range of characteristics that may be encountered across a population of devices and temperatures.

jamesh: I suspect you find my posts, two years down the road, a little impatient. This impatience is primarily with RPi organization for withholding these few fundamental numbers, preventing us from applying just a little intelligence instead of blind poking about. I will certainly be grateful if you could do the service of consulting with your hardware engineers, confirming (a second time) that these are fundamentally useful numbers, and getting them to the community.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7144
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 7:34 am

Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hippy
Posts: 5786
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 9:06 am

6by9 wrote:
Tue Apr 03, 2018 7:34 am
https://www.raspberrypi.org/documentati ... T-V1_0.pdf section 6 (page 13)
That is useful but there are still important things missing; for example the maximum source and sink current for the full GPIO port(s), what VIL and VIH are when hysteresis is not enabled, what is the maximum injection current for inputs.

The most notable absence is any electrical specification when VDD_IO=3V3 which seems to be the case for most Pi.

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 10:15 am

6by9 wrote:
Tue Apr 03, 2018 7:34 am
https://www.raspberrypi.org/documentati ... T-V1_0.pdf section 6 (page 13)
hippy wrote:
Tue Apr 03, 2018 9:06 am
6by9 wrote:
Tue Apr 03, 2018 7:34 am
https://www.raspberrypi.org/documentati ... T-V1_0.pdf section 6 (page 13)
That is useful but there are still important things missing; for example the maximum source and sink current for the full GPIO port(s), what VIL and VIH are when hysteresis is not enabled, what is the maximum injection current for inputs.

The most notable absence is any electrical specification when VDD_IO=3V3 which seems to be the case for most Pi.
Thanks to 6by9 for this important leap forward, the datasheet covers exactly the territory requested in the current discussion on page 13, showing us VIL, VIH, VOL, VOH, and also IOL and IOH for additional conditions.

Unfortunately, as hippy notes, it doesn't actually cover the RPi 3 nor 2. It covers the right SoC, but not at the right VDDIO voltage, and without telling the actual conditions that pertain to RPi 3 and 2. Issues:

VDDIO 3.3V
The most significant omission is that the DC Electrical Characteristics only cover behavior when VDDIO is set to either 2.7V (an odd value, as far as I am aware, 2.5V being more common) or 1.8V, as set by the user on the I/O connector, whereas the RPi 3 and 2 have VDDIO hard wired to 3.3V. According to the schematic:
https://www.raspberrypi.org/documentati ... ematic.pdf

So we need that exact same info for VDDIO = 3.3V.

Applicable conditions
Given that the VDDIO=3.3V case is not covered in this doc, the numbers are already moot. But in case the same doc might appear WITH the 3.3V case, I should also note that different VOL/H and IOL/H specs on this sheet are for different drive settings (notes b and c). Are these user-settable on RPi 2 and 3? If not, what are these set to by the supplied software?

Hysteresis
[Edit] The datasheet Table 5 footnote "a" says these VIH and VIL values are for when hysteresis is enabled. But we don't know whether in fact Hysteresis is enabled on the RPi2 and 3. And if not, we would need to know VIH and VIL for that case.

Injection Current
I agree with hippy, that a Max Injection Current spec would be highly useful for those interfacing to logic families above 3.3V.

Thanks 6by9 for the link you shared, and I hope that this same info applicable to RPi 2 and 3 can also be revealed.

I should also note -- apparently this doc has been available for some time, but I was unaware of it, and that it was relevant. I apologize for assuming less info was available than actually is, though of course this doc isn't directly applicable as it stands.

Addressing previous misinformation

I/O Expander handles some GPIOs? Schematic linked above shows that on the 40-pin connector, all the GPIOs ( 2 to 27) connect to the SoC. There is no Expander involved. So all GPIOs would be expected to behave the same, except that I see GPIO2 and 3 have 1.8k pull-up resistors, presumably for their role in I2C.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7144
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 11:49 am

gwideman wrote:
Tue Apr 03, 2018 10:15 am
Thanks to 6by9 for this important leap forward, the datasheet covers exactly the territory requested in the current discussion on page 13, showing us VIL, VIH, VOL, VOH, and also IOL and IOH for additional conditions.

Unfortunately, as hippy notes, it doesn't actually cover the RPi 3 nor 2. It covers the right SoC, but not at the right VDDIO voltage, and without telling the actual conditions that pertain to RPi 3 and 2. Issues:
It's the same IP block used in all Pi variants, whether as BCM2835, BCM2836, or BCM2837.
gwideman wrote:VDDIO 3.3V
The most significant omission is that the DC Electrical Characteristics only cover behavior when VDDIO is set to either 2.7V (an odd value, as far as I am aware, 2.5V being more common) or 1.8V, as set by the user on the I/O connector, whereas the RPi 3 and 2 have VDDIO hard wired to 3.3V. According to the schematic:
https://www.raspberrypi.org/documentati ... ematic.pdf

So we need that exact same info for VDDIO = 3.3V.
I can ask if that information is available. I'm slightly surprised at 2.7V, but mainly as 2.8V is more commonly floating around inside mobile phones ;)
gwideman wrote:Applicable conditions
Given that the VDDIO=3.3V case is not covered in this doc, the numbers are already moot. But in case the same doc might appear WITH the 3.3V case, I should also note that different VOL/H and IOL/H specs on this sheet are for different drive settings (notes b and c). Are these user-settable on RPi 2 and 3? If not, what are these set to by the supplied software?
Drive strength is per bank, and documented at https://www.raspberrypi.org/documentati ... uration.md. It can be set to either 8 or 16mA via dt-blob.bin.
gwideman wrote:Hysteresis
[Edit] The datasheet Table 5 footnote "a" says these VIH and VIL values are for when hysteresis is enabled. But we don't know whether in fact Hysteresis is enabled on the RPi2 and 3. And if not, we would need to know VIH and VIL for that case.
Again it's a per bank feature (same as the drive strength), always enabled by the firmware, and not exposed via Linux. It is therefore matching the conditions for the quoted VIH and VIL values.
gwideman wrote:Injection Current
I agree with hippy, that a Max Injection Current spec would be highly useful for those interfacing to logic families above 3.3V.

Thanks 6by9 for the link you shared, and I hope that this same info applicable to RPi 2 and 3 can also be revealed.

I should also note -- apparently this doc has been available for some time, but I was unaware of it, and that it was relevant. I apologize for assuming less info was available than actually is, though of course this doc isn't directly applicable as it stands.

Addressing previous misinformation

I/O Expander handles some GPIOs? Schematic linked above shows that on the 40-pin connector, all the GPIOs ( 2 to 27) connect to the SoC. There is no Expander involved. So all GPIOs would be expected to behave the same, except that I see GPIO2 and 3 have 1.8k pull-up resistors, presumably for their role in I2C.
The GPIO expander only connects internally within the board, or interfaces that are not expected to be significantly hacked around.
See https://github.com/raspberrypi/firmware ... .dts#L1188 for the 3B, and https://github.com/raspberrypi/firmware ... .dts#L1357 for the 3B+. It's the camera GPIOs, onboard LEDs, BT and Wifi enables, and ethernet reset line.
It is also present on the CM3, where it is used for HDMI hotplug and EMMC enable.
If you really need to hack around with it, then it's an FXL6408.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hippy
Posts: 5786
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 12:42 pm

6by9 wrote:
Tue Apr 03, 2018 11:49 am
Drive strength is per bank, and documented at https://www.raspberrypi.org/documentati ... uration.md. It can be set to either 8 or 16mA via dt-blob.bin.
Thanks for that clarification.

That's a setting which sets the drive strength of every pin on a port but doesn't specify what the total current allowed is for the whole port. I would doubt it's 28 pins x 16mA per port, 448mA, but maybe it is - Obviously also limited when sourcing by what the VDD_IO regulator can source.

And there seems to be an oddity, anomaly or ambiguousness in the CM electrical specs -

"IOL Output low current (c) | VDD IO = 2.7V, VO = 0.4V | 17 mA

(c) Maximum drive strength (16mA)"

That seems to be suggesting that with drive strength set to 16mA more than 16mA can be sunk.

Is drive strength just a nominal value, does it only apply when sourcing rather than sinking current, or is it something else ?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7144
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 1:35 pm

hippy wrote:
Tue Apr 03, 2018 12:42 pm
6by9 wrote:
Tue Apr 03, 2018 11:49 am
Drive strength is per bank, and documented at https://www.raspberrypi.org/documentati ... uration.md. It can be set to either 8 or 16mA via dt-blob.bin.
Thanks for that clarification.

That's a setting which sets the drive strength of every pin on a port but doesn't specify what the total current allowed is for the whole port. I would doubt it's 28 pins x 16mA per port, 448mA, but maybe it is - Obviously also limited when sourcing by what the VDD_IO regulator can source.

And there seems to be an oddity, anomaly or ambiguousness in the CM electrical specs -

"IOL Output low current (c) | VDD IO = 2.7V, VO = 0.4V | 17 mA

(c) Maximum drive strength (16mA)"

That seems to be suggesting that with drive strength set to 16mA more than 16mA can be sunk.

Is drive strength just a nominal value, does it only apply when sourcing rather than sinking current, or is it something else ?
Please read Gert's explanation - https://www.scribd.com/doc/101830961/GPIO-Pads-Control2
Summary is that each pin in isolation can drive with those strengths and be within the VOL/VOH limits (yes he's made a typo of VIL/VIH instead of VOL/VOH, and then picked up the wrong values from the datasheet), but the combined limits will be influenced by power supply, board layout, internal dissipation, and a bundle of other external factors that are not a function of the SoC. There will also be a simultaneous switching
I guess it would be possible to quote a max power dissipation of the device GPIO, but under what conditions? ARMs all off, or ARMs flat out, because the GPIO block is not the only thing producing heat (far from it), and therefore in 99.99% of cases it is a meaningless number.

Anomally/Ambiguity? The drive strength is the current that it is guaranteed to achieve VOL/VOH. If it is targetted for 16mA, then having an absolute max of 17mA does not make the 16mA invalid. Being a power of 2 also looks neater.
...
Ah, and the number you appear to be after is stated in the datasheet, table 8 (page 16) as note b.
Each GPIO can supply up to 16mA, aggregate current per bank must not exceed 50mA
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hippy
Posts: 5786
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 5:01 pm

6by9 wrote:
Tue Apr 03, 2018 1:35 pm
Please read Gert's explanation - https://www.scribd.com/doc/101830961/GPIO-Pads-Control2
Summary is that each pin in isolation can drive with those strengths and be within the VOL/VOH limits (yes he's made a typo of VIL/VIH instead of VOL/VOH, and then picked up the wrong values from the datasheet)...
Which is one of the reasons it's not very useful and people have been asking for more detailed and correct information.

His VIL/VIH input spec seems reasonable enough though it matches what is stated for VDD_IO=2V7 in the CM datasheet which one would have expected to be different for VDD_IO=3V3 though perhaps not.

What can be taken as his VOL/VOH however seems completely wrong, with no way to guess what it should be other than assuming it's the same as for VDD_IO=2V7 with the same caveat that it would be expected to be different with VDD_IO=3V3, though again perhaps not.

An updated CM datasheet Table 5 with a VDD_IO=3V3 added should satisfy most questions.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7144
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Tue Apr 03, 2018 5:14 pm

hippy wrote:
Tue Apr 03, 2018 5:01 pm
6by9 wrote:
Tue Apr 03, 2018 1:35 pm
Please read Gert's explanation - https://www.scribd.com/doc/101830961/GPIO-Pads-Control2
Summary is that each pin in isolation can drive with those strengths and be within the VOL/VOH limits (yes he's made a typo of VIL/VIH instead of VOL/VOH, and then picked up the wrong values from the datasheet)...
Which is one of the reasons it's not very useful and people have been asking for more detailed and correct information.

His VIL/VIH input spec seems reasonable enough though it matches what is stated for VDD_IO=2V7 in the CM datasheet which one would have expected to be different for VDD_IO=3V3 though perhaps not.

What can be taken as his VOL/VOH however seems completely wrong, with no way to guess what it should be other than assuming it's the same as for VDD_IO=2V7 with the same caveat that it would be expected to be different with VDD_IO=3V3, though again perhaps not.

An updated CM datasheet Table 5 with a VDD_IO=3V3 added should satisfy most questions.
I've asked the question of those who have the hardware design specs, now I'm dropping out of this conversation because we're going in circles. I've wasted enough time on it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Wed Apr 04, 2018 1:37 am

6by9 wrote:
Tue Apr 03, 2018 5:14 pm
I've asked the question of those who have the hardware design specs, now I'm dropping out of this conversation because we're going in circles. I've wasted enough time on it.
If your pursuit of the answers results in them being published, your time will certainly not have been wasted, and will be much appreciated.

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Thu Apr 05, 2018 4:35 am

Following up on 6by9's suggestion to look at the RPi's configuration to determine some of the default settings for the GPIOs.

"Changing the Default Pin Configuration"
https://www.raspberrypi.org/documentati ... uration.md
describes the format of the pertinent dt-blob.dts file, and the master version of that file is here:
https://github.com/raspberrypi/firmware ... t-blob.dts

The salient part of that file is:

Code: Select all

      pins_3b2 { // Pi 3 Model B rev 1.2
         pin_config {
            [email protected] {
               polarity = "active_high";
               termination = "pull_down";
               startup_state = "inactive";
               function = "input";
            }; // pin
            [email protected] { function = "uart0";  termination = "no_pulling"; drive_strength_mA = < 8 >; }; // TX uart0
            [email protected] { function = "uart0";  termination = "pull_up";    drive_strength_mA = < 8 >; }; // RX uart0
with similar sections for the other Pi models. We are concerned with GPIOs 2 through 27, here named [email protected]

Some inferences from this data:

-- Inputs (except 14 and 15) default to having a pull-down resistor. But that can be overridden by application code, so the default doesn't help or hinder an application.

-- A couple of pins have their output drive strength set to 8mA, and since all outputs of the same bank (here all Bank 0) are controlled as a group, I take this to mean that the GPIO outputs at the interface connector are all set to 8mA max output. I don't believe this can be overridden by application code, only by changing the Device Tree Blob.

-- There is no configuration information regarding the hysteresis (schmitt) input setting, so I think this file makes us none the wiser on that topic.

pin_define sections?
There are a bunch of pin_defines, such as:

Code: Select all

            [email protected]_DISK_ACTIVITY {
               type = "external";
               number = <2>;
            };
The "Changing..." page linked above gives a too-skimpy explanation of what these do. They look suspiciously like they might reserve pin <number> for a particular purpose -- here possibly for an external LED to indicate disk activity. But does that mean the pin can't be used for GPIO purpose? Or does something else have to be configured before that pin gets dedicated to the special purpose, and otherwise it's available?

Furthermore I've seen forum mentions that the dt-blob file only provides an initial configuration of the I/Os, and that these may get overridden by drivers as they are loaded. From which I get a somewhat "all bets are off" impression.

Anyhow, this is not really the place to start a full discussion of the dt-blob file. I only went to look at it because 6by9 offered it as the documentation for those parts of the GPIO electrical behavior that are software controlled. It perhaps answers a couple of questions, but raises a few new ones.

User avatar
karrika
Posts: 1063
Joined: Mon Oct 19, 2015 6:21 am
Location: Finland

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Thu Apr 05, 2018 8:09 am

Thank you for the BCM 14, BCM 15 info. I am probably doing all sensitive stuff where resonance matters on a HAT board and feed the data to the pins using a Schmitt trigger. This should also cover for the probable impedance drift caused by temperature.

I actually thought of a writing a version of Tapper using the anomalies of a gpio pin. By adding a small capacitor per customer to a gpio pin you could monitor 3 levels:
Low - empty glass, complain loudly
Flickering - complain that you want some more
High - full glass
Image
By clicking on the tab you set "pull up" on the pin to fill the capacitor. When you are not pressing tab you set "pull down" on the pin and the capacitors start discharging. Flickering would control the animation of the customers.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7144
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Thu Apr 05, 2018 8:52 am

gwideman wrote:
Thu Apr 05, 2018 4:35 am
-- Inputs (except 14 and 15) default to having a pull-down resistor. But that can be overridden by application code, so the default doesn't help or hinder an application.
Which aren't inputs (hence the uart0 designation), therefore pulling resistors are irrelevant.
gwideman wrote:-- A couple of pins have their output drive strength set to 8mA, and since all outputs of the same bank (here all Bank 0) are controlled as a group, I take this to mean that the GPIO outputs at the interface connector are all set to 8mA max output. I don't believe this can be overridden by application code, only by changing the Device Tree Blob.
Correct.
gwideman wrote:-- There is no configuration information regarding the hysteresis (schmitt) input setting, so I think this file makes us none the wiser on that topic.
Seeing as you can't be bothered to read what I write why should I bother writing anything?
Perhaps
HYSTERYSIS IS ALWAYS ENABLED BY THE FIRMWARE AND NOT CONTROLLABLE FROM LINUX
is big enough.
gwideman wrote:pin_define sections?
There are a bunch of pin_defines, such as:

Code: Select all

            [email protected]_DISK_ACTIVITY {
               type = "external";
               number = <2>;
            };
The "Changing..." page linked above gives a too-skimpy explanation of what these do. They look suspiciously like they might reserve pin <number> for a particular purpose -- here possibly for an external LED to indicate disk activity. But does that mean the pin can't be used for GPIO purpose? Or does something else have to be configured before that pin gets dedicated to the special purpose, and otherwise it's available?
Look again at the values used for those functions and NONE of them have ever been accessible via the GPIO header on the board, so a whinge about reserving GPIOs and not being available for general GPIO is just hot air.
They are configurable predominantly as on a Compute Module you do get access to all the GPIOs, and therefore being able to route the signals where you fancy is useful.
gwideman wrote:Furthermore I've seen forum mentions that the dt-blob file only provides an initial configuration of the I/Os, and that these may get overridden by drivers as they are loaded. From which I get a somewhat "all bets are off" impression.

Anyhow, this is not really the place to start a full discussion of the dt-blob file. I only went to look at it because 6by9 offered it as the documentation for those parts of the GPIO electrical behavior that are software controlled. It perhaps answers a couple of questions, but raises a few new ones.
No, I mainly offered it as a reference to what signals were on the GPIO expander.

Yes, I am getting fed up with this thread!
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7144
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Thu Apr 05, 2018 9:04 am

karrika wrote:
Tue Apr 03, 2018 5:11 am
Almost every user who is just trying to add a push button is hit with the fact that the GPIO pins have a grey area of voltages where the value oscillates. It has been well documented by paulv in this forum.

viewtopic.php?f=29&t=133740

I assume that understanding the shortcomings of GPIO pins affect the software and invites designers to use external electronics to increase long time reliability of the application.

The good thing is that after this research was made it was trivial to add countermeasures into the software. Before I had an occasional glitch triggering some effects at the theater. After adding hysteresis in the software the Pi works perfectly.
You added hysteresis, or you added switch debouncing? They are not the same thing.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
karrika
Posts: 1063
Joined: Mon Oct 19, 2015 6:21 am
Location: Finland

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Thu Apr 05, 2018 12:04 pm

6by9 wrote:
Thu Apr 05, 2018 9:04 am
karrika wrote:
Tue Apr 03, 2018 5:11 am
Almost every user who is just trying to add a push button is hit with the fact that the GPIO pins have a grey area of voltages where the value oscillates. It has been well documented by paulv in this forum.

viewtopic.php?f=29&t=133740

I assume that understanding the shortcomings of GPIO pins affect the software and invites designers to use external electronics to increase long time reliability of the application.

The good thing is that after this research was made it was trivial to add countermeasures into the software. Before I had an occasional glitch triggering some effects at the theater. After adding hysteresis in the software the Pi works perfectly.
You added hysteresis, or you added switch debouncing? They are not the same thing.
I added hysteresis in software to all gpio inputs for QLC+ software. Basically poll the gpio line 3 times with 50 ms intervals. If all are equal we accept the new changed state of the pin.

So this is not voltage level of hysteresis. It is time based hysteresis that is often used to stabilize values that keep changing rapidly. It is a pretty good technique for dealing with alerts. You may want a small number of alerts to turn a signal on and perhaps a greater number of missing alerts to turn it off.

gwideman
Posts: 45
Joined: Tue Mar 01, 2016 8:18 pm

Re: Documentation bugs: RPi2&3 GPIO electrical specs

Thu Apr 05, 2018 2:39 pm

6by9 wrote:
Thu Apr 05, 2018 8:52 am
Seeing as you can't be bothered to read what I write why should I bother writing anything?
Perhaps
HYSTERYSIS IS ALWAYS ENABLED BY THE FIRMWARE AND NOT CONTROLLABLE FROM LINUX
is big enough.
[...]
Yes, I am getting fed up with this thread!

I am not sure the customer relations effect you are trying to have here, but it's a little "unusual".

Moving on, let's take your points one by one.

What you previously wrote is that hysteresis is not exposed VIA linux, which I took to mean that the OS does not expose the hysteresis setting to applications. What you have now written is something different -- that Linux, apparently including the boot process, does not have access to those settings. Fair enough, point now understood based on your new information.

>> 14 and 15) default to having a pull-down resistor.
> Which aren't inputs (hence the uart0 designation), therefore pulling resistors are irrelevant.

Wait, are you saying that neither of GPIO14 nor 15 are inputs? Or that they are dedicated only to UART0 duty and can't be reassigned if UART0 is unused ?

>> [email protected]_DISK_ACTIVITY section [... what does it mean, any interaction with GPIO2... ]

> Look again at the values used for those functions and NONE of them have ever been
> accessible via the GPIO header on the board,

I'm looking, and what I see is that there are pin_define sections, the documentation for which I don't have, so I'm just guessing, but it appears to associate a name, suggestive of a function, to a "number", which is possibly a GPIO number. For example GPIO 2. Which is one exposed on the 40-pin header. In the absence of documentation, I don't know what to think. If the "number" doesn't refer to GPIO number, OK, fine, it's irrelevant to the current discussion. If "number" does refer to GPIO, but the function is not implemented, then OK, fine, again not relevant, but one wonders why that section is in the file. Other parts of these pins_xxx sections are relevant to understanding the GPIOs, maybe these pin_defines are not.

> so a whinge about reserving GPIOs and not being available for general GPIO is just hot air.

Not sure where you're seeing a whinge in that question.

Return to “Advanced users”