Shiftregister for 74HC165N

Hi Ron @zander,

   All of what you say is true ... but to do something about it, we need to identify a specific pin.

And looking at this particular program, the incoming data with errant value, as well as 7 values that are as expected, all come through the same pin, which is driven by the same 74HC165  CMOS output pin, so I can't see how there is a pin which could reasonably cause this problem.

-------

You are actually pointing to a more general concern of mine... microcontrollers often have GPIO pins which are not connected to anything by people linking up breadboards, etc., simply because they are 'spares' or 'not needed'.

In real life, it rarely makes any difference, but it is poor practice that could cause 'occasional' glitches, etc, as well as increasing power consumption. (The latter in CMOS gates can result in both transistors conducting when the input voltage is intermediate between high and low values .. a condition that is only 'supposed' to happen very briefly in each transition.)

I doubt if it would cause a problem with consistent data corruption on a different pin, which is being reported in this case.

Best wishes, Dave

@davee AFAIK, there is only the one INPUT pin. What made me think of it was his photo showing the long wires. Like I said, it can't hurt to change INPUT to INPUT_PULLUP. The only possible change is if he has the code wrong way round, open will now be HIGH, closed is LOW.

Hi Ron @zander,

The observation reported was

• The D0 at ic pin 11, is not showing any difference than 11111111,  which is the result when no button is hit. Tried exchange the IC, and its the same. What to do?

ie it is a missing "Pulldown", not a missing "Pullup".

Best wishes, Dave

@davee One of us is losing it. If he didn't specify INPUT_PULLUP then the pin is floating and those long wires could be picking up soe signal. As the Arduino documentation states

seemingly random changes in pin state, picking up electrical noise from the environment, or capacitively coupling the state of a nearby pin.

I am looking to see if I have that chip but it doesn't look like it. I will order some in any case and do the experiment myself. I can't wait for the OP to change the code.

EDIT: Part ordered, supposed to be here Wed.

Hi Ron @zander,

  Sorry, but the microcontroller pin connected to the Q output of the 74HC165, is best defined as INPUT, not INPUT_PULLUP, because the '165 output will always drive it to '1' (near) VCC or '0' (near) Ground voltages. That is, this pin is never 'floating'.

"Floating" input pins are usually due to:

• pin is unconnected
• pin is connected to a switch which shorts it to ground when closed ... hence the pin is 'floating' when the switch is open
• pin is driven by 'open drain' or 'open collector' output ..... this will result in 'floating input when the driving pin is not actively pulling it low.

----------

For this specific case, specifying it as INPUT_PULLUP, assuming the circuit is actually connected correctly, will not make any visible difference to performance of the circuit. The only effect will be to increase the power consumption by roughly 50 microAmps, when the input is driven low by the '165. Obviously, this will not be noticeable in normal conditions.

Best wishes, Dave

@davee Thanks for the clarification Dave, that does sound like I am on the wrong track, but the part is ordered and I will therefore run the experiment in any case, I have no experience with any of this so it is all good. I will report back late next week unless my Dr puts me in the hospital.

Hi Ron @zander,

  I think you are on the wrong track, but we haven't figured out the 'real' problem yet, so you might be able to discover a solution.

Hope the news from your Doctor is good ... take care of yourself.

Best wishes, Dave

@davee At least if I am wrong I will have ruled out one issue. Keep in mind I threw this out as a shot in the dark. I am interested as I may have a need for many buttons input and want to look at this solution versus some sort of multiplexor.

Still having pin setup like this:
// PL pin 1
int load = 13;
// CE pin 15
int clockEnablePin = 22;
// Q7 pin 7
int dataIn = 21;
// CP pin 2
int clockIn = 18;

Tried the changes on Q7 pin 7:

All tests were tried with and without a 500R resistor in place at the button.

 and the : byte incoming = shiftIn(dataIn, clockIn, MSBFIRST);

The scetch is suggesting LSBFIRST, giving number results in reverse or not. So i managed to get result from both MSBFIRST and LSBFIRST.

The script is set to print this:

Serial.print("Pin States: ");
Serial.println(incoming, DEC);

Testing pinMode's:

Only using one button, while moving a wire over the pinrow to test with.

Test 1) pinMode(dataIn, INPUT); Monitor result: 

This (pinMode, INPUT) test gives a number in result with resistor or no resistor:

D0 pin 11 - 255 Button pushed and/or not, gives 255 allways when no button is hit or not, and with both LSBFIRST and MSBFIRST.

D1 pin 12 - Gives the number LSBFIRST 127 and MSBFIRST 254,

D2 pin 13 - LSBFIRST 191, MSBFIRST gives 253, so at this D2, it begins to reverse a little, but haven't seen 253 at LSBFIRST.

D3 pin 14 - LSBFIRST 223, MSBFIRST 251

D4 pin 3 - LSBFIRST 239, MSBFIRST 247

D5 pin 4 - LSBFIRST 247, MSBFIRST 239

D6 pin 5 - LSBFIRST 251, MSBFIRST 223

D7 pin 6 - LSBFIRST 252, MSBFIRST 63

Test 2) pinMode(dataIn, INPUT_PULLDOWN);Monitor result: typing the highest nr. 255 continously, and is giving same results as test 1.

Test 3) pinMode(dataIn, INPUT_PULLUP);Monitor result: typing the highest nr. 255 continously, and is giving same results as test 1.

(At the print board, there is 4.7K resistor for every D pin, to GRND for making stabile when no button is pushed).

This might mean, that all pins are allready pulled down by default at the board.

So we have 8 buttons, where the first at pin zero will repeat itself.

Most likely, we have 7 useable pinouts. Its like the D0 referes to a standby posistion. I can't atm test, how D0 is doing without being pulled to GRND, as the resistors are soldered to the board.

@fungreenfox Good luck.