PROP and 74HC595

smlcaerus

Got what I hope is a simple question.· In any case, I have connected a prototype board to my PROP dev board.· The proto board has (2) inline 74HC595's to drive some transistors and relays.· Quite simple in fact.· Anyway, I am driving the 74HC595 chips with a simple SHIFTOUT function found here on the forums.· Question / Problem I am seeing/having is that the communication out of the PROP "looks" fine when analyzing it on my scope.· I am sending 16 continious bits, and the shift clock syncs up nicely to the bits being sent.· Yet, my 74HC595's sometimes have careless output, meaning not always syncing to what was sent.· This is ALWAYS the case on the 1st bit sent as well.· So if I send %1000000000000000 it should make Q8 on the 74HC595 go high, and never does, sometimes I see a high pin somewhere else, sometimes even on the second chip.

So my question I guess it, I am connecting the DATA, SHIFT, and LATCH thru a 18" long connection.· 8" from the protoboard, and 10" from the PROP dev board.· I am wondering what would be considered a "safe" distance, for this connection.· My assumption is that the connection is too long (+ the fact it is two cables connected together), and maybe the communication is stepping on bits, or something., or should I maybe make the first bit sent a little longer to compensate or something?

Any insight here would be greatly appreciated.

Thanks
Shawn

Leon

I haven't used a 74HC595 with the Prop, but haven't had any problems using it with other MCUs as an SPI peripheral (software and hardware SPI). Have you tried SPI code with it? You might have the timing wrong. 18" of cable should be OK. Do have decoupling on the '595?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Mike Green

You probably looked at the signal as it left the Propeller, not as it arrived at the 74HC595. I'm sure you'll see quite a difference.

18" is bit far to run a high speed 3.3V logic signal without some help.

1) Use a twisted pair cable with the 2nd of each pair grounded. This provides a controlled impedance.

2) Use a pullup or pulldown resistor (maybe 10K) at the 74HC595 end of each signal to help absorb noise

3) Use a small series resistor at the Propeller end (maybe 100 Ohms) to help slow down signal edges and absorb noise

4) Make sure you've got enough capacitive filtering at the 74HC595 end for the power lines

hippy

smlcaerus said...
I am sending 16 continious bits, and the shift clock syncs up nicely to the bits being sent.

It may depend on what "syncs up" means in reality; are you setting the data and asserting the clock at the same time or setting the data and then asserting the clock ? Likewise altering the data while de-asserting the clock ?

It could be a simple timing issue in which case add some delays between setting data, asserting clock, hold the clock, de-assert then alter data. I've had similar problems with parallel LCD's over long IDC cable which needed the timing stretched.

StefanL38

Hello Shawn,


what is the timebase of the shiftoutfunction?
How many micro/milliseconds ?

Is this time longer than the minimum-spec in the datasheet ?

High-level on DIFFERENT pins let's me guess that the electrical connection might be bad
or even something is free flowing

If there appears a high on the second chip: are the two chips connected serially?
(Chip1 Pin Qh connected with Chip2 Pin SI)

If this is the case the bits of the first chip where shifted into the second chip with EVERY Clockcycle.
This means you have to send ALWAYS a 16bit pattern to make sure that the state of all 16 pins is defined like you wnat to have them

the clock-signal has to be switched after every databit. How do you manage this by a simple shiftout-function ?
and after shifting in all bits you have to switch the latch

What happens if you send an alternating pattern 10101010101...?
What happens if you send 16, 17, 18 bits?

to get an insight what MIGHT be the problem, you should answer these questions and post or attach your COMPELETE sourcecode

best regards

Stefan

Post Edited (StefanL38) : 5/20/2008 3:08:24 PM GMT

smlcaerus

Well, ive got it to a point now, where it is ONLY the 1st bit being sent.· If i send all 1s, it recognizes it, if i send all 0's it recognizes it. If i send %10xxxxxxxxxx· it doesnt get the 1 on the first bit.

I am not using any decoupling at this point.· If need to do so, where is it exactly I should be putting decoupling capacitors?



Shawn

Peter Camilleri

I agree that this could very well be a software issue. If clock and data transition together, then you have a race state that can cause undesired operation. For the HC595 though I've often needed some hardware assist. This takes the form of a pair pf 74hc14 (Schmidt Trigger Inverter) gates on the clock line to debounce it a bit. This is also a good idea on the load line as well because it is also edge triggered.

Best regards;

Peter

Praxis

This sounds like a timing problem.

The setup time for DS to SH_CP is minimum of about 25 nS, so set the data bit add a delay >25nS then assert the clock output.

Leon

You should have a 100 nF capacitor directly across the '595 supply and ground pins, and a 10 uF capacitor where the supply enters the board.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

BTX

Hi Shawn
What I have working fine is the following code:

PUB Main ' only an example, not my exactly code here.
 
   HC595(DataOut, Clock, Comp_Out, 16)            ' Send outs to both HC595's
   
   ' Wiring: 
   'pin  11 of both HC595's are Clock.
   'pin  14 HC595 and 9 of this (first) HC,  with pin 14 of the following HC595, are DataOut.
   'pin  12 of both HC595's and R of 10KOhm to GND are Latch.
   'pin  10 of both HC595 to +Vcc

PUB HC595 (Dpin, Cpin, Value, Bits)
{{
   Shift data out, MSBFIRST
}}
    outa[noparse][[/noparse]Dpin]:=0                                       ' Data pin = 0
    dira[noparse][[/noparse]Dpin]~~                                        ' Set data as output
    outa[noparse][[/noparse]Cpin]:=0
    dira[noparse][[/noparse]Cpin]~~

    outa[noparse][[/noparse]Latch]:=0                                      '
    dira[noparse][[/noparse]Latch]~~                                       '

    REPEAT Bits                                                                
       outa[noparse][[/noparse]Dpin] := Value >> (bits-1)                  ' Set output           
       Value := Value << 1                              ' Shift value right    
       !outa[noparse][[/noparse]Cpin]                                      ' cycle clock          
       !outa[noparse][[/noparse]Cpin]                                                             

    outa[noparse][[/noparse]Dpin]~                                         ' Set data to low
    !outa[noparse][[/noparse]Latch]                                        '
    !outa[noparse][[/noparse]Latch]                                        '

But I have not tested this for long wires.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

smlcaerus

Here is my modified shiftout code, with some delays (yes started placing them all over the place - [noparse]:)[/noparse]

PUB Out ( OutputLatchPinNo, OutputDataPinNo , OutputClockPinNo , OutputEnablePinNo , OutputNoOfBits , OutputByteValue )

DIRA [noparse][[/noparse]OutputLatchPinNo] ~~ '' SET the LATCH Pin to OUTPUT
OUTA [noparse][[/noparse]OutputLatchPinNo] := 0 '' TOGGLE the LATCH Pin OFF

DIRA [noparse][[/noparse]OutputDataPinNo] ~~ '' SET the DATA Pin to OUTPUT
OUTA [noparse][[/noparse]OutputDataPinNo] := 0 '' TOGGLE the DATA Pin OFF

DIRA [noparse][[/noparse]OutputClockPinNo] ~~ '' SET the CLOCK Pin to OUTPUT
OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' TOGGLE the CLOCK Pin OFF

WAITCNT(2500 + CNT)
myloop :=0

REPEAT OutputNoOfBits '' Start REPEAT LOOP for NoOfBits ie 8
·· myloop++
·· OUTA [noparse][[/noparse]OutputDataPinNo] := OutputByteValue >> ( OutputNoOfBits -1 ) '' SET the DATA pin to the first bit·
·· WAITCNT(1500 + CNT)
·· OutputByteValue := OutputByteValue << 1 '' SHIFT the BYTEVALUE to the Next Bit
·· OUTA [noparse][[/noparse]OutputClockPinNo] := 1 '' TOGGLE the CLOCK Pin ON
·· WAITCNT(5000 + CNT)
·· OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' TOGGLE the CLOCK Pin OFF
·· if myloop == 8
···· waitcnt(10000+cnt)

OUTA [noparse][[/noparse]OutputLatchPinNo] := 1 '' TOGGLE the LATCH Pin On
WAITCNT(1500 + CNT)
OUTA [noparse][[/noparse]OutputLatchPinNo] := 0

DIRA [noparse][[/noparse]OutputLatchPinNo] ~~ '' SET the LATCH Pin to OUTPUT
OUTA [noparse][[/noparse]OutputLatchPinNo] := 0 '' TOGGLE the LATCH Pin OFF

DIRA [noparse][[/noparse]OutputDataPinNo] ~~ '' SET the DATA Pin to OUTPUT
OUTA [noparse][[/noparse]OutputDataPinNo] := 0 '' TOGGLE the DATA Pin OFF

DIRA [noparse][[/noparse]OutputClockPinNo] ~~ '' SET the CLOCK Pin to OUTPUT
OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' TOGGLE the CLOCK Pin OFF

Propability

How you clock the 74HC595 depends on how you have it hooked up. Since it can be a tri-state device -you can shift in data but not allow the output pins to toggle as you do so then clock the data to the outputs with the storage register clock or you tie the two clock pins together and the output pins toggle(non tri-state)·as you clock in data . If you are driving the 2 clock signals together then you will need· an extra dummy clock to move the data since the shift register is always one clock ahead of the storage register( the actual output). That is why you see that in your outputs which I suspect is how you are driving the 74HC595.



Pete

Propability

OK -I stared at your code and it looks like you are driving the latch for every data bit but you only need to do it after the last data bit has been strobed in (just need only one latch strobe).






Post Edited (Propability) : 5/20/2008 5:14:12 PM GMT

StefanL38

Hello Shawn,

first of all

if you use the POST REPLY Button you get menu Buttons like "CODE" "URL" etc.

you can use the button CODE to switch between normal text and SPIN-Code

(CODE) at the beginning

and (/CODE) at the end of the code

but with sharp edged brackets instead of "(" ")"

on thing that i can see is
for triggering the clock you use

   OUTA [noparse][[/noparse]OutputClockPinNo] := 1 '' TOGGLE the CLOCK Pin ON
   WAITCNT(5000 + CNT)
   OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' TOGGLE the CLOCK Pin OFF

the clock is triggert by a low-to-high -transition

so you would have to code vice versa

   OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' TOGGLE the CLOCK Pin OFF
   WAITCNT(5000 + CNT)
   OUTA [noparse][[/noparse]OutputClockPinNo] := 1 '' TOGGLE the CLOCK Pin ON

as probability mentioned
it depends on how you connected the Prop and the 74595

Here is my way. It does not use any pullup or pulldown-resistors at all

        74HC595 'QA-QH 8Bit parallel Output           
      QA─────────────┐
        ┌──┐┌──┐     │
      QB┤01└┘16├Vcc  │
      QC┤02  15├QA───┘
      QD┤03  14├SI     'serial Data In 
      QE┤04  13├G      'if low QA to QH-Outputs are enabled. If high QA to QH-Outputs are DISabled 
      QF┤05  12├RCK    'low  high: ShiftRegister-Data is stored in Output-Latch-Register
      QG┤06  11├SCK    'low  high: triggers the ShiftRegister-Clock "shifts in" the bitvalue of SI
      QH┤07  10├SCLR   'if low ShiftRegister is cleared. If not connected to an Prop-IO connect to +Vcc
     GND┤08  09├Qh     'serial Data Output connect this Pin to SI of next 74xxx595 for cascading
        └──────┘




    ┌ ←QA1─────────────┐
    │     ┌──┐┌──┐     │
    B ←QB1┤01└┘16├Vcc  │
    y ←QC1┤02  15├QA1──┘
    t ←QD1┤03  14├SI─←────────────── ←connected to Propeller-IO-Pin "Prop_serial_out"
    e ←QE1┤04  13├G─→ Gnd
    1 ←QF1┤05  12├RCK──────────┳──── connected to Propeller-IO-Pin "serial_out_RCK"
    │ ←QG1┤06  11├SCK──────────┼─┳── connected to Propeller-IO-Pin "serial_out_SCK"
    └ ←QH1┤07  10├SCLR→+Vcc    │ │
       GND┤08  09├Qh─→───────┐ │ │
          └──────┘           │ │ │

you posted only the modified PUB
NOT the whole program.

I cannot see how the PUB is called
maybe there is a fault too

a long time ago i made a program in SPIN for the 74595
i made separate PUB-Methods for everything that's a senseful unit.
By this way of coding you make sure if one PUB ist working you are REALLY sure
that an error is NOT inside this PUB because it has been tested separatly
There are only VERY few times where the error is still inside the tested PUBs

This is a quick copy and paste of the sourcecode

It compiles but i did not check it TODAY with the real hardware
in the past it was working

CON    
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  Delay = 1
  Pin = 16

CON
  Prop_serial_out = 0'from Propeller to SI (serial in from shiftregister SN74HC595 
  serial_out_SCK  = 1
  serial_out_RCK  = 2
  serial_out_SCLR = 3
  serial_out_G_QEnable = 4
  
  Input  = 0
  Output = 1
  Delay1 = 10
  
VAR
  long Delay_microS
   
  byte dummybyte
    
PUB Main
  SO_Init_IO_74LS595
  SO_ClearShiftR
  SO_ClearStoreR

  repeat
    SO_Write1Byte(3)
    
    SO_Write1Byte(6)
    SO_Write1Byte(12)
    SO_Write1Byte(24)
    SO_Write1Byte(16)
    SO_Write1Byte(48)
    SO_Write1Byte(64+128)
    SO_Write1Byte(128)
    
    wait_MS(500)
    
PUB SO_Init_IO_74LS595
  'set IO_direction
  DirA[noparse][[/noparse]Prop_serial_out] := OutPut
  DirA[noparse][[/noparse]serial_out_SCK ] := OutPut
  DirA[noparse][[/noparse]serial_out_RCK ] := OutPut
  DirA[noparse][[/noparse]serial_out_SCLR] := OutPut
  DirA[noparse][[/noparse]serial_out_G_QEnable] := OutPut

  'Initialize Pin-state with value that does not change anything
  OutA[noparse][[/noparse]Prop_serial_out] := 0
  OutA[noparse][[/noparse]serial_out_SCK ] := 1 ' 
  OutA[noparse][[/noparse]serial_out_RCK ] := 1
  OutA[noparse][[/noparse]serial_out_SCLR] := 1
  OutA[noparse][[/noparse]serial_out_G_QEnable] := 0 


PUB SO_Write1Byte(B) | BitFilter
  BitFilter := 128

  repeat 8
    if B & BitFilter 
      OutA[noparse][[/noparse]Prop_serial_out] := 1
    else
      OutA[noparse][[/noparse]Prop_serial_out] := 0
    SO_Shift
    BitFilter >>= 1             'shift "1" right  

  SO_Store
  
 
PUB SO_ClearShiftR
  OutA[noparse][[/noparse]serial_out_SCLR] := 0 'state 0: ShiftRegister is clear
  wait_MS(Delay1)            'Wait for DelayMS cycles    
  OutA[noparse][[/noparse]serial_out_SCLR] := 1 'change to state 1 after clearing  
  
  
PUB SO_ClearStoreR
  SO_ClearShiftR
  SO_Store


PUB SO_Shift
  OutA[noparse][[/noparse]serial_out_SCK ] := 0
  wait_MS(Delay1)            'Wait for DelayMS cycles    
  OutA[noparse][[/noparse]serial_out_SCK ] := 1           'low-to-high triggers shifting
  wait_MS(Delay1)            'Wait for DelayMS cycles    


PUB SO_Store
  OutA[noparse][[/noparse]serial_out_RCK ] := 0
  wait_MS(Delay1)            'Wait for DelayMS cycles    
  OutA[noparse][[/noparse]serial_out_RCK ] := 1           'low-to-high triggers storing
  wait_MS(Delay1)            'Wait for DelayMS cycles    

  
PUB wait_MS(p_WaitTime_ms) 

  waitcnt((clkfreq / 1000) * p_WaitTime_ms + cnt)
      

Stefan

Post Edited (StefanL38) : 5/20/2008 5:26:16 PM GMT

Peter Jakacki

Shawn, you're are driving RELAYS and you don't have any decoupling capacitors on the 595s?! I would not even look at the code.

How do the relays hook up, do they share the same return ground over 18 inches?
What are you using to strobe the shift registers other than clock and data?
If you are only using clock and data then outputs are tripped as you clock and with relays that means inductive spikes.

You need:
Proper grounds
Proper decoupling

*Peter*

smlcaerus

Attached to this reply is a copy of the scope image connected to both the DATA and SHIFT clock.

As I look at it, I am more convinced this is not a software/sync issue, but if anyone see's something i do not, let me know.

As it stands now, the relays following the 74HC595 are non-inductive, in that the only thing flowing thru them is an alarm 12v 2.5ma signal.· No motor or anything which would "throw back".·

It seems the problem is ONLY with the 1st bit in series, all others function PERFECTLY.· No matter what bit i send as the first, the 74HC595 NEVER enables Output 8 as HIGH.· Only ODDITY is if I send all ("%1111111111111111") then it goes high (as do all the others).

SoI am wondering if it is something about NOT having a capacitor between VCC/VDD (decoupling).

Now to implement decoupling, I was told to place a capacitor between VCC and VDD.· 100nf.· Does this need to be on BOTH chips, or just the first in series...

Before I break out my little box horrors and stick one/two on, anyone see anything wrong with the image?

Shawn

Leon

Put it on both chips. It would be a good idea to add a 10 uF as well. Do you have diodes across the relay coils and are they powered from a different supply?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

smlcaerus

Im using semiconductor relays with built in diodes. [noparse]:)[/noparse]

where should i place the 10uf?· im powering this protoboard directly from the parallax prop dev board.

as for the "on chip" capacitors, can i just go pin to pin on the 74HC595 (meaning connect one end of cap to one and other end of cap to other pin) without removing any other connections?

Propability

Never hooked up 2 595's in series but you would think that you would send 16 bits then the latch strobe but in your code it looks like you are sending 8 bits twice with a latch strobe at the end of each 8 bit routine. I bet the first 595 in series looks OK but not the second one.

smlcaerus

No, im sending all 16 bits, then latching, may be the indentation got a little funky when I cut/paste code into my previous reply.

As I said, its only the first bit (left most on the SCOPE image i posted, as bits move from right to left on the image), that does not go HIGH when sent. All other remaining when·I send 1 to the 74HC595 set the outputs to high.

Its just the screwiest thing.

Propability

Well here is the snippet from your code that led me to this.

REPEAT OutputNoOfBits '' Start REPEAT LOOP for NoOfBits ie 8
myloop++
OUTA [noparse][[/noparse]OutputDataPinNo] := OutputByteValue >> ( OutputNoOfBits -1 ) '' SET the DATA pin to the first bit
WAITCNT(1500 + CNT)
OutputByteValue := OutputByteValue << 1 '' SHIFT the BYTEVALUE to the Next Bit
OUTA [noparse][[/noparse]OutputClockPinNo] := 1 '' TOGGLE the CLOCK Pin ON
WAITCNT(5000 + CNT)
OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' TOGGLE the CLOCK Pin OFF
if myloop == 8
waitcnt(10000+cnt)

I see an 8 in there not a 16.

If this is not the code you are using then maybe post the code that does the 16 .

smlcaerus

That is the code, when the subroutine is called, i send 16 as the "OutputNoOfBits".

At the end of the sub their, the myloop ==8, is just create a little pause for me to see on the scope.

so, the repeat loops 16 times (or the number I send in when calling the method)

BTX

Hi Shawn.
In this picture are the HC's, the code is what I wrote before in this thread, try that code, believe me ...it works, just is closer than your.
If you can try with short wires could be better, then you could larger them... & I always decouple all IC's with 0.1 uf (like in the picture...as near as possible the IC's).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

StefanL38

Hello Shawn,

please reopen your mind to "the error CAN be EVERYWHERE"

The fact that all other bits are working perfectly does NOT mean
that the error HAS TO BE here or there

If you lost a key at night in the FOREST but search for the key on the STREET because there is more light
you will never find the key.

What happens to the leftest bit if you send 17 bits ?

What would be the worst thing that could happen if you post your COMPLETE code ?
Punishment-payments because you are not allowed by a contract?

does your scope-picture show the following bitpattern

16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01
1  0  0  0  0  1  1  0  0  0  0  0  0  0  0  0   

what happens if you send 

16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01
1  1  0  0  0  1  1  0  0  0  0  0  0  0  0  1   

what happens if you send

16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01
1  0  1  0  0  1  1  0  0  0  0  0  0  0  1  0   

did you check this carefully ?


Did you debug your software like this:

connect LEDs to EVERY of the 16 outputs to get a REALLY EASY overview about the logic state of each output
measuring voltages as too buggy

- insert codelines that printout the values of myloop and the state of databit and clock and latch via RS232 to a terminalsoftware
- toggle the latch after EVERY change of databit or clock
- waiting before and after EVERY toggle of the latch for a user-command to go on

By this way you can trace EVERY single detail of the shiftout-process

best regards

Stefan

Post Edited (StefanL38) : 5/21/2008 1:54:08 AM GMT

DavidM

HI,

The code some of you are referring to was posted by me some time ago ( it was modified from the BS2 functions) , see my entry in this thread.

http://forums.parallax.com/forums/default.aspx?f=25&m=252598&g=252626#m252626

It works for me I have used it a lot with no problems, but please delete the "myloop++" and the "if my loop == 8" lines of your code , it is not needed as the REPEAT function handles the bit count.

Also make sure your xtal setting is set to..

CON
_CLKMODE =XTAL1 +PLL16X
_XINFREQ =5_000_000

refer to the PCB Layout PDF I posted there as well as that is my exact circuit I am still using today. note the de-coupling capacitors 0.1uf and the PULL-UP & PULL DOWN resistors 10K. The are also 1K current limiting resistors between the shift register and the prop as I am running the shift register at 5V so I can run leds!

test it with just LED's first before connecting the relays. ( MUST DO!)
Also, try short leads ( use one bread board) , I have used leads about 8" long and that works.
I have also used this with up to 4 shift registers with no problems!

I am not sure about "StefanL38" post about the low to hi transitions of the clock signal, but add some delay between the toggles.

OUTA [noparse][[/noparse]OutputClockPinNo] := 1 '' SET the CLOCK Pin ON
WAITCNT(1000 + CNT) '' add some delay , Try this
OUTA [noparse][[/noparse]OutputClockPinNo] := 0 '' SET the CLOCK Pin OFF


Again read my previous post!

Thanks

Dave M

Propability

Maybe the QH outputs got switched. The picture of the scope looks ok.

Peter Jakacki

Hi Shawn,

I was busy racing out the door before and missed the fact that you mentioned you had a latch signal as well. There is nothing wrong with the software as the scope shows it clocking out bits nicely (although very very slowly). Can you post the circuit because it has to be in the circuit or incorrect hookup if it's breadboarded.

*Peter*

Pyrotom

On two of my projects (a pipe organ controller and an automated firing system for fireworks) I use lots of daisy-chained 74HC595's. I also had lots of problems until I put a 74LS245 chip in to drive the Data, Clock and Latch lines. All of my problems disappeared immediately. The 74LS245 is much nicer than the more common 74LS244 in terms of layout IMHO. I use ULN2803 peripheral drivers to interface the output of the 74HC595 to electro-pneumatic valves in the pipe organ or relays in the fireworks system.

Peter Jakacki

Pyro brought up an issue that you can face with interfacing to +5V logic (I'm assuming this). The 74HC minimum input high can be 0.7Vcc = 3.5V so it may be that the shift registers are barely detecting a 3.3V signal as logic high. The simple solution is to use 74HCT595s as these have a much lower Vih of a fixed 2V. Pyro got around this by adding extra chips which you could also do or just choose the simpler solution.

I noticed too in an earlier post that mention was made of placing a decoupling cap between VCC and VDD. Well the decoupling cap should go between VCC and VSS or between VDD and VSS depending upon which terminology you employ. I prefer to say VCC for any +5V logic and VDD for any other logic voltage (higher or lower) as VCC refers to bipolar logic which usually runs at +5V.

*Peter*

BTX

Hey.
I'm missing something ?
I used HC595 at 3.3Vcc to drive 16 optocouplers.....why to use it with +5 Vcc ?
NO buffers, only one resistor to GND, and it works fine in a machine....what's the problem ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Peter Jakacki

The 595s will run off +5V and at that voltage you may be able to drive 5V relays directly etc. Also the +5V may be able to supply more current than the 3.3V rail plus you are isolating your heavier loads from the CPU supply rail. If you drive 16 optocouplers from a linear 3.3V regulator then you are asking probably around 160ma or more for the optos plus the 100ma or so for the Propeller. If your input supply is +9V then that means at least 1.5W of dissipation in the regulator which means you need a large regulator plus a good heatsink.

I use switching regulators to +5V and a tiny SOT-23 pack 3.3V regulator for the final supply to the prop so naturally I would tie the heavier loads to the +5V rail. This also can include any visible light LEDs that the prop may drive as the forward voltage drop of any led is at least 1.6V and more. So I can drive my leds hard if I like yet not worry about the 3.3V supply.

Also, there is no rocket science involved in driving shift-registers but some thought has to be given to how they are connected up and what happens at reset when the I/O lines are floating (pull-down clock line), how long a line you are driving etc.

*Peter*