Another 74HC165 Example (Prop Version of StampWorks Program)

Duane Degn

I know there are lots of examples of using the 165 parallel to serial shift register with the Propeller but here's yet another one.

I wanted to make sure I understood how to use the chip myself and wanted a simple test program.

This program is based on the one from the StampWorks book page 141 (page 151 of pdf).

I've tested this and it works fine but I'd be thankful if any of you would point out any problems it may have.

_CLKMODE = XTAL1 + PLL16X                            
  _XINFREQ = 5_000_000                                

  
  CLOCK = 0                     ' Connected to pin 2 of 74HC165
  LOAD = 2                      ' Connected to pin 1 of 74HC165
  DATA  = 1                     ' Connected to pin 9 of 74HC165 (for inverted data use pin 7)
                                ' The data pin should be connected to the Propeller with
                                ' a 4.7K Ω series resistor.
  BITS_IN = 16
  
  DEBUG_BAUD = 115_200
  DEBUG_HEADING_X = 2          ' Output formatting data
  DEBUG_HEADING_Y = 2
  DEBUG_DYNAMIC_X = DEBUG_HEADING_X + 8
  DEBUG_DYNAMIC_Y = DEBUG_HEADING_Y + 2
  
VAR
  long xInputs
  
OBJ
  Pst :  "Parallax Serial Terminal"
   
PUB Setup
  Pst.Start(DEBUG_BAUD)
  waitcnt(clkfreq * 3 + cnt)  ' time to open serial terminal
  
  dira[CLOCK] := 1
  outa[LOAD] := 1
  dira[LOAD] := 1
  
  Pst.Clear
  Pst.Position(DEBUG_HEADING_X, DEBUG_HEADING_Y)
  Pst.Str(string("xInputs FEDCBA9876543210", 13))
  Pst.PositionX(DEBUG_HEADING_X)
  Pst.Str(string("------- ----------------", 13))
  Pst.PositionX(DEBUG_HEADING_X)
  Pst.Str(string("Status  ................"))
  MainLoop
  
PUB MainLoop
  
  repeat
    xInputs := 0                                        ' clear variable to hold input states
    outa[LOAD] := 0
    outa[LOAD] := 1
    repeat BITS_IN
      xInputs <<= 1
      xInputs += ina[DATA] 
      outa[CLOCK] := 1
      outa[CLOCK] := 0
    Pst.Position(DEBUG_DYNAMIC_X, DEBUG_DYNAMIC_Y)
    Pst.Bin(xInputs, BITS_IN)

The attached version has additional comments and MIT license.

74HC165_120929e.spin

Duane Degn

I'm just updating this thread to include an object to make it easier to include the 74HC165 code in a larger program.

The next time I have a couple '165 wired up I'll add a demo program to show how this object is used. It's a very basic object. You just call the "Init" method to set the pins used with the chips and then call "ShiftIn" with the number of bits you want to read (up to 32 if you are using four chips). The return value from "ShiftIn" contains input bits.

This object has been previously uploaded to the forum as part of a larger program.

Edit(3/11/15): Warning, the code attached is an old version. There are likely better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't code similar to what is attached here on my on GitHub, send me a message and I'll make and check for any improved versions of the code.

JonnyMac

Coincidentally, my January column is about using the x165 and x595 in Propeller programs to painlessly expand IO. At EFX-TEK we've recently designed a road sign controller that uses both to expand pin counts, and even does PWM through the x595s (I'm not the first to do this, I just presented my version). Anyway, here's my dirt-simple x165 object from the column.

Duane Degn

Thanks JonnyMac. I'll take a look at it next time I have some '165s wired up.

One of the things on my todo list is to combine what I learned from your quadrature encoder article with a PASM version of a '165 driver to read multiple quadrature encoders with a couple of these chips. I have several projects with four quad encoders, the eight I/O pins used to read the encoders is a big hindrance to my efforts of adding additional sensors to the robots.

I think many QE's are slow enough to allow a '165 catch all the transitions. I know the Rover 5 produces transitions at 500Hz, I'm pretty sure a PASM '165 driver could be read this fast. I could sure use the five I/O pins this would free up.

JonnyMac

I don't imagine that being a problem, especially if you wire the A/B pairs to the x165 in a consistent manner; you can sample all, do a shift, and determine the direction of each pair very quickly -- the way Jeff Martin does in his encoder object.