Sharing GND pin with several wires

B

balanga

Apart from using a breadboard is there any way to connect several wires to a GND pin?

I've been looking for some sort of connector, but can't find anything suitable...
 
SirDice said:
A soldering iron can do wonders.
Click to expand...
Yes, and for somebody who is not ready to solder, a plain screw terminal could do a good job as well:
220px-Leuchterklemme_75dpi.jpg
 
I would ground the several ground wires to chassis or a bus bar to chassis and then have just 1 ground wire going to the connector. Depends on the application.
 
There isn't enough information here to give a proper answer. Please provide a context. Ground pin to what? Is it a chip? Socketed? Soldered in-place? Analog or digital?

Normally you don't connect "several wires to a ground pin". You connect each pin (that needs to be grounded) to ground - where ground is a relatively thick trace on a circuit board or one of the two power-bus rows on a breadboard.

Ground wires should be kept short. If you are adding a jumper to an existing circuit board, you will often find a spare solder-able ground location on a nearby capacitor. Visual inspection plus an ohmmeter can confirm which pins are connected to ground. Given multiple choices - pick the closest one.
 
Second what unitrunker said. You need to provide context. Here is an example of a detailed question: You are using a RPi2, and you are wire-wrapping wires directly to the 40-pin GPIO connector, and sticking the wires into the Frankenstein monster you are assembling in a transsylvanian castle (please watch Mel Brooks "Young Frankenstein" for some amusement). You are sticking a GPIO pin into each digit of the monster (for the dirty jokes from the movie regarding some digits, you'll have to watch it yourself, explaining the jokes here would violate the CoC). Every GPIO pin requires a matching ground wire attached to the table, and you don't have 11 ground pins. Unfortunately, your blonde and very well-endowed assistant Inga doesn't know how to solder, and Frau Blucher has hidden the only breadboard for the RPi2. So how to use out the few ground pins on the RPi2 connector to get enough grounding to the monster's table? Wire nuts? Luesterklemmen?

Well, good question! Instead of answering it, I'll fire up youtube, and watch the monster and Gene Wilder sing and dance "puttin' on the ritz" now.
 
I ran into this problem last night. I was attempting to build a multiple GPIO pin OneWire device tree overlay. The mechanism for Linux doesn't work so I built my own overlay with muptiple pins for separate onewire buses. Each bus is limited to 10 devices.
I kept having troubles as the pins would work in one arrangment but in 2 seperate busses only 1 bus pins would show devices.
The other the bus was erroring out.
So I added a second power and ground to my breadboard for the second onewire pin and all the sensors worked fine.
It was a ground problem all along. Separate onewire buses did not work with a shared ground.

So this is a good example of why a shared power source for multiple IO pins is bad. It looked like a software issue but was hardware.
I can't tell you how many times I redid that overlay. I tried every possible combination possible from the 3 examples.
In the end it was the last gasp of trying a separate power source that solved my 8 hour struggle.
Yes the GPIO power and ground pins are limited so plan accordingly. I was able to power my RTC sharing power/ground pins.
Some of the problem with my setup is there is a parasitic mode that the ds1820 onewire temp sensor can run in. It shares data and power line. I am using all 3 wires to my sensors so maybe parasitic mode is the reason. With a shared power line to the two buses maybe data was leaking over. Supposedly FreeBSD onewire does not support parasitic power. I did not address that in my overlay. I should have disabled it. I noticed the RPi W1 overlay has a parasitic setting.
 
Phishfry
Interesting!
Do you experience that problem also if you solder instead of using a breadboard?
I wonder if that could be caused by breakdown voltage of the oxide layers involved in breadboard connections.
 
No I think onewire bus data is leaking over the power line causing OneWire bus error. Just a wild guess.
I need to explicitly disable parasitic to test this theory.
Could also be a ground problem. I had problems in the past with multiple OW buses and I bet it is related.
 
I've been designing hardware as an electronic engineer since 1974 till 1995 for everything from medical computers to cash registers to computer graphic workstations. I mostly switched to software, though I still do hardware projects for theatre companies, and I just want to say that I have no clue what you are talking about.
 
https://en.wikipedia.org/wiki/1-Wire
I am inputting 1 wire temperature sensors on the Beaglebone. I am using a 3 wire configuration with power, ground and onewire signal. I can only use 10 onewire devices per bus(pins on Beaglebone)
So I wanted to add more pins for more 1-Wire temperature sensors.
To do so you have to modify the device tree. This describes the hardware to the OS similar to plug and play.
So I have to tell the device tree that another pin is now input for onewire data.
To do that I modify the Linux device tree overlay library. This is where devices are cataloged for non-plug and play devices.
Like Arm powered Device Tree boards without plug and play.
https://source.android.com/devices/architecture/dto/
So the standard Linux pin overlay for onewire is for only one GPIO pin use. Like I said I want multiple GPIO pins for onewire. So modifying the device tree overlay is like a black art. There are no instructions. You just need to try things and see what the result is.

I tried from 3 different Linux examples and modified with my knowledge of what the FreeBSD to Linux differences are in the device tree structure.

I could tell from dmesg output that the device tree overlay I created for two pins worked correctly and was actually assigned to the GPIO pins in the proper input capacity.

So then I went looking for culprits to the onewire bus errors I was seeing in dmesg and considered powering the second GPIO onewire pin sensors with a second set of power leads coming from the Beaglebone.
The average plastic breadboard has accommodations for power pins on both sides. I usually only supply 1 set of power connections to the breadboard for all the sensors to share.

I have found that such an arrangement did not work correctly for me and when I supplied a second set of power leads to the breadboard the second onewire bus stopped erroring out and sensors were available.
So each onewire pin needs a separate set of power connectors.

Using 2 onewire pins with one set of power leads for powering the sensors caused the onewire bus errors.
The onewire temp sensors I use have 4K7 resistors on each board.

There is a software mode to turn off parasitic power in the device tree overlay.
I will try that to see if I can isolate the two buses. With parasitic power on and a common power source I can now see trouble.

So this was really a story about troubleshooting. How a hardware power problem led to onewire bus errors.
Similar to sharing a bunch of GPIO grounds and trying to troubleshoot.

Anyway welcome back doc. I have really missed your critiques.

Code: 
owc0: <FDT GPIO attached one-wire bus> at pin 15 on gpiobus3
ow0: <1 Wire Bus> on owc0
ow_temp0: <Advanced One Wire Temperature> romid 28:ee:ba:09:2f:16:02:74 on ow0
ow_temp1: <Advanced One Wire Temperature> romid 28:ff:4e:51:70:16:05:c2 on ow0
ow_temp2: <Advanced One Wire Temperature> romid 28:ff:61:b3:70:16:04:45 on ow0
owc1: <FDT GPIO attached one-wire bus> at pin 14 on gpiobus3
ow1: <1 Wire Bus> on owc1
ow_temp3: <Advanced One Wire Temperature> romid 28:ff:a8:08:70:16:04:91 on ow1
gpioc3: <GPIO controller> on gpio3
 
The only suggestion I have, if I'm understanding this correctly, is to make sure a 4.7K resistor is the right size for pulling the pin all the way down or all the way up and the signal isn't hanging somewhere half way between.
 
Phishfry said:
https://en.wikipedia.org/wiki/1-Wire
So each onewire pin needs a separate set of power connectors.

Using 2 onewire pins with one set of power leads for powering the sensors caused the onewire bus errors.
The onewire temp sensors I use have 4K7 resistors on each board.

There is a software mode to turn off parasitic power in the device tree overlay.
I will try that to see if I can isolate the two buses. With parasitic power on and a common power source I can now see trouble.
Click to expand...

If you are using parasite power mode make sure you have also strong pull-up (in addition to weak pull-up via 4.7k resistor). Otherwise even 2 sensors on the bus will drain too much current for weak pull-up while in conversion mode (can be even 1.5mA each so then voltage drop across 4.7k resistor will not leave enough voltage for sensor to operate, minimum is 3V). Hence you may be observing errors.
It is explained in sensor datasheet:

However, when the DS18B20 is performing temperature conversions or copying data from the scratchpad memory to EEPROM, the operating current can be as high as 1.5mA. This current can cause an unacceptable voltage drop across the weak 1-Wire pullup resistor and is more current than can be supplied by Cpp. To assure that the DS18B20 has sufficient supply current, it is necessary to provide a strong pullup on the 1-Wire bus whenever temperature conversions are taking place or data is being copied from the scratchpad to EEPROM. This can be accomplished by using a MOSFET to pull the bus directly to the rail as shown in Figure 6. The 1-Wire bus must be switched to the strong pullup within 10μs (max) after a Convert T [44h] or Copy Scratchpad [48h] command is issued, and the bus must be held high by the pullup for the duration of the conversion (tCONV) or data transfer (tWR = 10ms). No other activity can take place on the 1-Wire bus while the pullup is enabled.
Click to expand...

Here on page 7 you have correct wiring in case of parasite power (how to connect MOS) and for external power.
Generally you do not need additional power leads if one can deliver sufficient current, and provided wiring is done correctly.
And from experience - when you are done with breadboard also check with long wires - this is where I had most issues with transfer due to parasitic capacitance introduced.
Hope it helps

*edit - and please check in datasheet of the chip you are using how much current you can drain from a pin. I think for Beaglebone it is just few mA which might not be enough for couple of sensors. If that is the case then you can only use external power, not parasite mode.
 
You must log in or register to reply here.
Back
Top