GPIO Ground lines

I have a GPIO question I have been meaning to ask.

So on your typical Arm GPIO board you have maybe 26 GPIO pins but only 8 Grounds.

How do you handle 26 LED's with only 8 grounds? Is it OK to co-mingle the grounds?

I am making a custom GPIO Lid for the APU1/2/3/4 with a ribbon cable to GPIO Header and terminal blocks mounted on the lid.

I am using barrier style terminal strip with screw terminals.

The terminal blocks are made for PC board/surface mount and I will drill the lid for the through-hole pins.

I will solder the wires from a 20 Pin (2x10 2.5mm P) ribbon cable to the pins from the terminal block. Shrink wrap.

Here is a look at the APU boards layout:
apu-gpio.png

So my question is what should I use for GPIO ground.
There are only two grounds here and they seem tied to a power source.
My plan is 18 individual pairs of terminals. One for each GPIO channel.
So with only 2 grounds is it OK to daisychain all these GPIO grounds together?
Should I use a chassis ground instead?
For GPIO I need a signal ground not a power ground right??
 
How do you handle 26 LED's with only 8 grounds?
All the ground pins are connected to the same ground. It's not like a differential signal where you specifically need two wires (one is the exact opposite of the other). It's a ground, it doesn't matter which one you use. All signals and voltages are relative to this ground.
 
How do you handle 26 LED's with only 8 grounds?
In addition to what SirDice said, each LED will need a serial resistor to limit the current to up to a few Milli-Ampere. Then one common ground wire of some Milli-Ohm will not hurt. Especially if there are just LEDs as consumers. Things can be difficult if the output currents are high and if you use GPIOs or pins at the "other side" where the board is connected to as input, especially when they are used as interrupt and cannot be de-bounced in software.
 
So in that scheme they are using a power supply for lighting the led but controlling with gpio.
I have been debating using the boards supplied 3V and 5V in a fused fashion.
 
Thank you all for your help. It is apparent I have to retool my approach.
I was hoping for general input and output, not just LEDs but switches and relay control too.
APU don't have PWM or anything complex.
All our GPIO Interrupt code is for FDT/OFW so that is unusable along with the OneWire driver.
I am trying to make the APU into a poor mans PLC.

My terminal blocks.
8 position so was planning on 4 each mounted on the APU top cover or lid for 16 pairs.
Separate the power with marine fusebox with spade connectors.

This was my original plan but nothing is drilled yet.
 
I've thought about using a Raspi to switch on more power-hungry computers in this way. I settled on using opto-isolators

But that's as far as I got.
 
Did you ever hear about the circuit simulation software LTSpice? I found this extremely useful for my circuit developments for the BeagleBone Black, and note, I started from almost zero.

The point is that this tool allows us to verify our ideas before we burn down the ARM SoC’s or even worse explode our office.

For example here is the LTSpice circuit of a simple relay driver using a transistor. The 3.3 V line (V1) is the GPIO, and the 5 V source (V2) comes from the very power supply of the BBB. The 10k resistors prevent that the transistor base draws high current from the GPIO.
Bildschirmfoto 2021-06-05 um 17.56.37.png

Bildschirmfoto 2021-06-05 um 17.56.45.png


If you want to drive a series of relais, then you are better done with darlington driver array ICs like the ULN2803A https://www.ti.com/product/ULN2803A. In one application, I use this one to drive six 12V relais with GPIOs from the BeagleBone. I cannot find know the final KiCad layout, I found only the one for 4 relais, and this is missing also diodes for preventing inductive current flow on switching the relais. The GPIOs would be connected directly to the DO.x input pins. As you see, there is only one common GND for all.

I am sure electronic professionals can do this much better than I. Anyway, these circuits are working ones, and my BeagleBone is still alive.

Bildschirmfoto 2021-06-05 um 18.17.33.png

Bildschirmfoto 2021-06-05 um 18.20.48.png

Bildschirmfoto 2021-06-05 um 18.31.49.png
 
Since this was my area of expertise for decades I guess I should chime in.

The multiple ground pins show that the potential current carrying load of the pins can be heavy-ish and, therefore, only one ground pin would not suffice as most regular chips have. One thing that might need to be checked is whether some of the IO pins are meant to work with one particular ground pin. They might not all be connected together. This can be found on the data sheet along with any recommendations of how to use the chip.

I don't know anything about this controller but the outputs might be powerful enough to handle LEDs by themselves and all you should use is a current limiting resistor. Again, this should be given in the data sheet. Otherwise, external transistors can be used to add more power. Fusing for that is somewhat controversial and I would say unnecessary.

Data sheets often give examples of usage and a perusal will also answer most of your questions.
 
The Arm boards have the advantage of having built in PU/PD resistors on some pins.
Good for prototyping.
I don't see those on the APU schematic.
They are wired right to the LPC UART with a capacitor on V3A domain.
PU/PD resistors are relevant only for digital input, and even then, if you connect for example a push button, you are better done to turn the internal resistors off and use external ones together with a capacitor for debouncing the button.

Here is an example LTSpice scheme:
Bildschirmfoto 2021-06-06 um 00.11.18.png


Bildschirmfoto 2021-06-06 um 00.11.26.png

The simulated switches of the button show, that the rising and the falling edges are damped (debounced) because of that 33n capacitor. Even with an internal PU or PD resistor, you would need to attach the external PU or PD resistors and a capacitor for the mere purpose of debouncing.

A few month ago I attached a rotary encoder to the BBB and believe me, without debouncing I get interrupt trains of ten and more in a row for any single snap. So, I turned the internal PU off and instead attached the above external PU together with the debouncing resistor/capacitor circuit. This works perfectly by 100.0 %.

The circuit can easily be accommodated for other models of buttons and encoders with other bouncing characteristics by simply changing the value of the capacitor.

PS:
Said all that, the bottom line is: „Internal PU/PD resistors are nice NOT to have.“
 
So with only 2 grounds is it OK to daisychain all these GPIO grounds together?
If you are just activating steady state indicator LEDs which only change a few times a second, you can have a common ground from near the power supply. But there are certain circuits that need to be done carefully..

- when doing ATOD conversion, there should be a separate ground for the analogue input signal
- high speed serial buses can glitch because of poor grounds
 
For example here is the LTSpice circuit of a simple relay driver using a transistor.
That is very nice. Did you have to put the chip part numbers in or are they part of a toolbar.
What packages are needed for LTspice? I see ngspice and gspiceui and then there is spice-gtk.

I see for Q1 you used the BC547B. That is the same transistor as the Pi example.
I bought 25 pairs of those and the PNP variant BC557B.
These are versatile for GPIO work?
 
Sorry, in my enthusiasm, I forgot that we are on the FreeBSD forums, when I mentioned LTSpice. That is not Open Source Software but Free Ware provided by Analog Devices, and it comes with tons of device specifications for the most general parts and of course for most of the AD and Linear Technology products which are AD since 2017. There is a Windows version and people are using this in Wine on Linux, so most probably this would work on FreeBSD in Wine as well.

If you prefer open source, KiCAD, which is in the ports of FreeBSD, comes with a Spice simulator. I had a look into it, but the workflow was very different from what I was used to do with LTSpice, and I was in a hurry and didn’t come to explore this more in deep -- I would like to, since the benefit is that we may use our KiCAD designs directly for simulation as well, and would not need to draw everything again in another Spice software. For Spice, you want to install KiCAD devel, since in v5, Spice was very new and under heavy development. Supposedly it is better supported in KiCAD devel -- the upcoming v6. Also the new KiCAD will come with different file formats, and that means, everybody who starts with KiCAD 5 today, would need to convert all libraries and files once KiCAD 6 comes out, so it would be better to start directly with the devel version.

BC547B is a known part in the LTSpice library and can be selected from a huge list of all sorts of transistors.
Bildschirmfoto 2021-06-07 um 09.08.34.png


The Spice directives of other less common parts must be imported. For example TI provides pSpice models for their parts, and these can be imported into LTSpice and work out of the box.

BC547B works quite well here for my switching tasks. We must not connect the base of the transistor directly to the GPIO, but between GPIO and base always use a 10k resistor which limits the current that could be drawn from the GPIO to max. 330 µA.

When I need to switch more than two relais in an application, I prefer the ULN2803 IC, since it is almost ready to use without attaching additional components. Also this one can drive relais with higher current than the BC547B (max. 100 mA) can. This IC is also very cheap, and you will find it in any electronics shop.
 
Back
Top