More Questions on 74HC165 and 74HC595 Shift registers (2)

@mikeburton_2000 I have not had my first coffee, so maybe I am missing something but you mentioned touch sensors and buttons and I don't see any in the sketch.

As a troubleshooter there are a few things I like to do or see happen. The first is to reduce that large setup to a smaller setup.

The second is to not make changes independent of those trying to help.

Your problem will not be caused by choice of a valid processor.

The shift register is likely at the heart of things, so you can go two ways with that. First prove to yourself that you can make the shift register work with a simple sketch, and then the reverse, can you make your circuit do anything without the shift register. TBH, I don't think that exercise will help much but sometimes we get stuck in a rut and miss something obvious.

So your homework is:

1. Explain about the button or touch sensor.

Let's just do that before we start rewiring.

@mikeburton_2000

I have dropped the script onto the ESP32 and updated the pins in use etc but when it's running the patterns displayed on the LEDs and the info in the serial monitor show random button presses when no button are being touched. There does seem to be some recognition of actual button presses, but they are inconsistent.

I would suggest that is the part to concentrate on?

I am unable to read a M$ RTS file.

One good high res photo and maybe another from another angle to reveal hidden connections should be sufficient. They can be opened in a new window which provides a magnifier for closer inspection of parts of the photo. Just right click the image and choose Open in new window.

I have only experimented with the shift regiister IC's using a UNO and MEGA Arduino board. Although I have an ESP32 I haven't played with it yet. Many years ago I used to use the Shift register IC's to pump data in and out of a centronics port pin on the old MSDOS PC using Turbo C++ and Assembler.

Sorry about your stroke something I fear as I get older.

@robotbuilder @mikeburton_2000 What you will not see in that source file you can't read is any mention of reading a button. What he has is a random noise machine.

@zander Thanks for the input. To clarify, the touch sensors are part of a project I am piecing together. My mode of operation is to experiment with the various bits I know I will need to make up the project and add them to it once I something that works. in the case of the original project, I wanted to have 9 buttons that would switch on 9 12v DC devices, but wanted the buttons to be touch pads.

I started by getting the hang of touchpads, which I am okay with now. Then I wanted to protect my microprocessor so started playing with optocouplers. A the moment the larger project has nine touch-sensitive buttons that are latched/unlatched by the script which is currently running on a Nano. They operate the optocouplers which operate the relays, and a series of RGB LEDs confirm the touches, latching and relay operation.

I wanted to expand the available touchpad inputs and optocoupler outputs to twelve or more. So I started to play with shift registers. I had the DBW 595 example up and running counting to 256 in binary all happy. I then constructed the 165 example and this is where I ran into the issue of the serial monitor showing that ghost button presses were being observed. 

Not deterred I developed the project into the 2x165s and 2x595s with 16 buttons and 16 LEDs. Hoping that in the rebuild I would spot something I did wrong, and knowing that I would need to do a little extra learning to understand how to daisy-chain the registers. However, I found the ghost inputs were still being observed and as I couldn't see what was causing I reached out for help, and here we all are.

I have since gone back to basics on yet another breadboard and reconstructed the 595 example as seen on DBW. It's running merrily away counting to 256 as expected. I have cobbled it up using an ESP32-WROOM but will shortly throw an XIAO -ESp32-C3 at it, reassign the pins in the script and see if it continues to be happy.

If it does, I'll start to add the 165 example from DBW on the other side and see if that works happily by itself, before I try merging the two examples. 

The reason you don't see any mention in the RTF/script of anything looking for a button press is because it's the 165 that's "looking" for the button press and should be telling the 595 which LEDs to illuminate and extinguish.

I'll report back on the experimenting once I've got it set up if that's okay.

@mikeburton_2000 Excellent procedure. I am so used to seeing nothing but 'shotgunners' so I failed to recognize your procedural approach.

Did you consider MOSFET's in place of the optocoupler and relay approach? 

A schematic would help along with the code. I recommend removing the relays and opto couplers and simplify down to the minimum to get the software working then them back once your happy with the logic.

@noweare Who are you talking to? 

@zander Mike Burton

@noweare Then use the Reply link so he is notified.

@mikeburton_2000 I see you use a lot of breadboard. Do you often have problems with bad connections? I finally found a review of boards and there were two that were MUCH better. They are almost identical in performance, but one is more expensive since it handles board stacking a little better. If you have problems in this area and I will post the name of the board manufacturer.

Yes, there is no such thing as having too many breadboards. I like to lay things out with plenty of room (big hands & sausage fingers). Then condense it down a bit and replace the jumpers with something more low profile. 

I’ve not had any problems to date with the breadboards I have and don’t use too thick of a gauge of wire when laying things out do as not to stretch the receivers.

I’ve put together the DBW 165 Example and although I’m now not getting ghost presses (Steady 11111111), all the button presses go unseen except the last button on my string which when pressed produces 11111100 in the serial monitor.  

So I’m not really any further forward. It’s a different 165 (I have 5 to hand) so it’s less likely to be a faulty IC. I can only guess my understanding of something is out of whack. 

I verified over the weekend that each button is sending volts to the 165 and each one is. I also managed to resolve the above situation, where, when pressing the last button (connected to register pin 6) - the only one that is observed - it also registers a press for the next digit in the binary sequence. This is a button that is connected to the other side of the register - pin 12 I think.

I added a quick High-Low of the clockIn pin before the Low-High of the clockEnablePin. It stopped the false read on the other button but did nothing to make any other button presses observed.

// Get data from 74HC165
  digitalWrite(clockIn, HIGH); //
  
  digitalWrite(clockEnablePin, LOW);
  byte incoming = shiftIn(dataIn, clockIn, LSBFIRST);
  digitalWrite(clockEnablePin, HIGH);
  
  digitalWrite(clockIn, LOW); //

  delay(250);

So the next thing is to swap out the 165 in case I broke it somehow. Then if that doesn't work, I'll throw it all in the bin and use something that has enough GPIO's with SR's.

I'll try to draw out my scheme and post it here when I have time and have sharpened my crayons.

Hi Mike @mikeburton_2000,

 I sympathise with your frustration, and confess to having a lot of sympathy with the general principle of choosing a microcontroller that has enough GPIO pins to do the job, without needing shift registers, because to 'misuse' Bill's (@dronebot-workshop) pun, shift registers can indeed be a bit 'shifty'.

That is not to say they don't work. It is because each register is a 'memory' that can change state in a few nanoseconds, so they can be susceptible to noise glitches, contact bounce and other transitions that are 'invisible' to all but very fast oscilloscopes, and even then, the 'scope has to be carefully set up to be looking in the right place at the right time, to see some of the sneaky problems that can arise in real circuits.

Hence, if you are still willing to try to get them to play nicely, I would recommend starting with the simplest circuit and software, and gradually make it 'smarter'.

----------

A couple of general points, to kick off.

In Bill's circuits he usually has just 1 chip, say a 74HC165, and also one decoupling capacitor. What may not be appreciated is that in 'real circuit' with several logic chips, such as those from the 74HCxxxx series, it is normal to fit at least one, sometimes two or more, decoupling capacitors to each logic chip. These capacitors need to be attached as directly as possible, across the power supply pins, such pin 8 to pin 16 of a 74HC165 in 16-pin dil package.

A common scheme, on a printed circuit board layout,  would be a 0.1 microFarad ceramic capacitor across 74 series chip, plus an electrolytic capacitor of say 100microFarad 'shared' by up to 4 such chips, assuming they are very close together. With the longer wires using breadboards, you might need more electrolytic capacitors than this.

As you probably already know, their function is to provide a small reservoir of charge. When the logic changes from high-to-low or low-to-high, the chip takes a short 'gulp' of current. The resistance and inductance of the power wiring opposes this momentary high current flow, causing the voltage at the chip to fall, sometimes by enough to cause a high to look like a low, or vice versa. The capacitors' job is to supply charge and maintain the power voltage at the chip.

----------------

The other point is that all ESP32xxxx (and ESP8286) chips that I am aware of, use 3.3V logic. This means that all connections to external circuits, such as the 74HC165, must also be 3.3V powered. (The 'original' Arduino boards like Nano and Uno are 5V logic, although some of the later versions, sometimes with similar names, maybe 3.3V.)

A common confusion is that the ESP32 development boards have a 5V input, and also commonly a USB socket, which is also 5V for power and data.

However, in general, the pins of the ESP32 are only designed to cope with a maximum voltage of 3.3V. The development boards have an on-board voltage regulator to convert incoming 5V power to 3.3V, and the more common ESP32 boards have an interface chip to convert the 5V USB data to 3.3V. The majority of GPIO pins must not be directly connected to a logic circuit powered at 5V. Although, your ESP32 may appear to survive the experience, premature device failure is the probable result.

In some cases, it is necessary to interpose voltage level converters between the ESP32 and a 5V external circuit, but as the 74HC165 (and 74HC595) are specified to run at lower voltages than 5V, the simplest solution is to reduce their supply voltage to 3.3V.

This will mean that the current through the LEDs will be less, so they will be less bright, but hopefully sufficient for the purpose. "Ideally", the series resistors would be changed to compensate, so that the current through each LED was the same as before, but if they light up, you will probably be fine.

-------------------

Presently, I do not have any 74HC165s in my spares box, so I can't easily reproduce your experiments, although I could obviously order some. But before I do that, please let me know if you wish to try to fix your circuits, or to change to another microcontroller with more GPIOs.

Best wishes, Dave

@davee thank you so much for your post. I have been feeding the buttons and therefore the 165 and input pins of the ESP with 5v. 

I will make the required changes and drop this to 3.3v. If I need to swap the ESP and 165 for new ones, I can as I’ve plenty in my box. 

Hopefully this will move things forward as it wasn’t something I had considered. Probably a rookie mistake, but it’s all part of the learning game. 

Again, thanks for your valued input.