|
--- In , "Bob Smith" <bobsmith5@v...> wrote: > Sorry about the typo -- > > > See the 74HC165 for input ports and the 74HC794. > > should read - > > > See the 74HC165 for input ports and the 74HC794 for output ports. > > Bob Smith. I am familiar with the 74HC165, but I have never used or heard of the '794 - and a quick web search did not turn up anything. I also checked the Fairchild website, without success. Did you intend to refer to the 74HC594 8-bit shift register instead? I have used the 373/573 (as a memory-mapped device) in the past to create a basic 8-line output port. The edge-triggered latching '374/'594 is a good device to use for a memory-mapped 8-bit input port (I tie MCU ALE to the latch-enable input, and MCU [E & RW] to the output-enable input). The '595 (the device I think Bob intended to cite) is a good choice for creating a 8-bit output port that is loaded serially. This device has a seperate shift register and output latch, so one can load the shift register serially, then strobe the latch enable pin to transfer the shift register to the output latch. This way, glitch-free output state changes can be realized. The '299 parallel- load shift register can be used as a serially-read input port. The '165 part that Bob mentioned also serves this purpose, and is somewhat easier to comprehend. There is, presumably, a replacement available for the venerable 68HC24 PRU device that was discontinued by Motorola some years ago. A quick web search I did turned up a company named TEKMOS that provides a replacement: http://www.tekmos.com/standard_products/TK68HC24.htm One thing I wish was present on the 68HC24 is a 'select output' that would go active when registers within the device were being accessed. Such an output would make it possible for one to overlay other memory in the same address space, which could be deselected (with minimal extra logic) when the PRU was being read/written. A while ago, I modified a stock Mot EVBU and added extra RAM, FLASH and a PRU. I used a PLD (22V10) to de-select the RAM (mapped at $0000-$7FFF) when a read to address $x000 (x=0..F, set by a 16- position hex switch) occured. However, since the I/O page (for both HC11 and PRU registers) can be changed in software, my solution was less than optimial, since I would have to manually change the rotary page-select switch if the I/O register base was changed. A 'device selected' output from the PRU would have simplified my external logic considerably, not to mention making the manual rotary switch page selection control unnecessary. I used to have a supply of PRUs in my parts kit, but I lost them a few years ago (along with most of my parts collection) in a fire that took out most of my lab :( |
|
|
I/O expansion
Started by ●May 22, 2004
Reply by ●May 22, 20042004-05-22
|
To Mark, et al -- Ok, lets see if I can unravel some of the confusion I have caused by trying to use the keyboard before getting a full pot of coffee into me this a.m. > I am familiar with the 74HC165, but I have never used or heard of > the '794 - and a quick web search did not turn up anything. I also > checked the Fairchild website, without success. > > Did you intend to refer to the 74HC594 8-bit shift register instead? > Yes, the 74HC594 is the part I was referring to for a SPI driven output port device. See more below. > I have used the 373/573 (as a memory-mapped device) in the past to > create a basic 8-line output port. The edge-triggered > latching '374/'594 is a good device to use for a memory-mapped 8-bit > input port (I tie MCU ALE to the latch-enable input, and MCU [E & > RW] to the output-enable input). While latches are essential for "memory mapped" output ports to hold data stable between bus write cycles, I do not as a rule use latches for inputs. I use, instead, simple line receiver/buffer devices such as the 74HC540 or 541 (depending on whether you want inverting or non-inverting input function). You need to assemble some glue logic to generate a bus read cycle strobe to strobe their inputs and they will simply sample the instaneous state of the input lines when commanded to do so by a suitable software instruction such as a LOAD accumulator. > > The '595 (the device I think Bob intended to cite) is a good choice > for creating a 8-bit output port that is loaded serially. I _really_did_ mean the 74HC594 as the preferred device as you suggested several lines above. There is (in my mind anyway) a very important difference between the '595 and the '594. The more widely manufactured '595 provides an output enable (OE) function for its registered outputs, _whereas_ the '594 instead provides an asynchronous reset function for its registered outputs. This distinction is important in some applications such as the typical motion control applications that I work with because the state of the output port can be assured from RESET time. The remainder of what you say is true. > This device has a seperate shift register and output latch, so one can > load the shift register serially, then strobe the latch enable pin > to transfer the shift register to the output latch. This way, > glitch-free output state changes can be realized. The '299 parallel- > load shift register can be used as a serially-read input port. > The '165 part that Bob mentioned also serves this purpose, and is > somewhat easier to comprehend. > I have never found the bi-directional and other complexities of the '299 to be of advantage and have always used the '165 devices for SPI based inputs. Thanks for the note on the PRU replacement. TKMOS does sound familiar as the second source. Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-2608 ----- Original Message ----- From: "Mark Schultz" <> To: <> Sent: Saturday, May 22, 2004 5:21 PM Subject: [m68HC11] I/O expansion > --- In , "Bob Smith" <bobsmith5@v...> wrote: > > Sorry about the typo -- > > > > > See the 74HC165 for input ports and the 74HC794. > > > > should read - > > > > > See the 74HC165 for input ports and the 74HC794 for output ports. > > > > Bob Smith. > > I am familiar with the 74HC165, but I have never used or heard of > the '794 - and a quick web search did not turn up anything. I also > checked the Fairchild website, without success. > > Did you intend to refer to the 74HC594 8-bit shift register instead? > > I have used the 373/573 (as a memory-mapped device) in the past to > create a basic 8-line output port. The edge-triggered > latching '374/'594 is a good device to use for a memory-mapped 8-bit > input port (I tie MCU ALE to the latch-enable input, and MCU [E & > RW] to the output-enable input). > > The '595 (the device I think Bob intended to cite) is a good choice > for creating a 8-bit output port that is loaded serially. This > device has a seperate shift register and output latch, so one can > load the shift register serially, then strobe the latch enable pin > to transfer the shift register to the output latch. This way, > glitch-free output state changes can be realized. The '299 parallel- > load shift register can be used as a serially-read input port. > The '165 part that Bob mentioned also serves this purpose, and is > somewhat easier to comprehend. > > There is, presumably, a replacement available for the venerable > 68HC24 PRU device that was discontinued by Motorola some years ago. > A quick web search I did turned up a company named TEKMOS that > provides a replacement: > > http://www.tekmos.com/standard_products/TK68HC24.htm > > One thing I wish was present on the 68HC24 is a 'select output' that > would go active when registers within the device were being > accessed. Such an output would make it possible for one to overlay > other memory in the same address space, which could be deselected > (with minimal extra logic) when the PRU was being read/written. A > while ago, I modified a stock Mot EVBU and added extra RAM, FLASH > and a PRU. I used a PLD (22V10) to de-select the RAM (mapped at > $0000-$7FFF) when a read to address $x000 (x=0..F, set by a 16- > position hex switch) occured. However, since the I/O page (for both > HC11 and PRU registers) can be changed in software, my solution was > less than optimial, since I would have to manually change the rotary > page-select switch if the I/O register base was changed. A 'device > selected' output from the PRU would have simplified my external > logic considerably, not to mention making the manual rotary switch > page selection control unnecessary. > > I used to have a supply of PRUs in my parts kit, but I lost them a > few years ago (along with most of my parts collection) in a fire > that took out most of my lab :( > > -- ------ > Yahoo! Groups Links > > a.. To |
|
|
Reply by ●May 23, 20042004-05-23
|
At the risk of seeming as if I'm beating a dead horse, I am responding to Bob's comments on the appropriate use of various 74HCxx logic that can be used to provide I/O expansion. My comments are interspersed with Bob's original text below. --- In , "Bob Smith" <bobsmith5@v...> wrote: > While latches are essential for "memory mapped" output ports to > hold data stable between bus write cycles, I do not as a rule use > latches for inputs. I use, instead, simple line receiver/buffer > devices such as the 74HC540 or 541 (depending on whether you want > inverting or non-inverting input function). You need to assemble > some glue logic to generate a bus read cycle strobe to strobe > their inputs and they will simply sample the instaneous state of > the input lines when commanded to do so by a suitable software > instruction such as a LOAD accumulator. I agree that a latch is not absolutely NECESSARY for a input-port application. There is one subtle benefit from using a latch - it ensures that the (data) bus remains in a stable state during the read. If input(s) change state during the read operation, the bit (s) affected could be misread. In most cases, where input states are being constantly polled, this is not a problem, but if you happened to be monitoring something that is returing byte or word or multi-bit data as a logical 'group', and that device is running asynchronously to the CPU bus, then latching the input state may be desirable. In addition to the 540/541 devices that Bob mentioned, the venerable '244 works too, if that is all you have on hand. The '244's pin arrangement is not as PCB-layout friendly ("thru- line") as the 540/541, but it performs the same logical function, so if that is all you have in your parts kit, it will do. > I _really_did_ mean the 74HC594 as the preferred device as you > suggested several lines above. There is (in my mind anyway) a > very important difference between the '595 and the '594. The more > widely manufactured '595 provides an output enable (OE) function > for its registered outputs, _whereas_ the '594 instead provides an > asynchronous reset function for its registered outputs. This > distinction is important in some applications such as the typical > motion control applications that I work with because the state of > the output port can be assured from RESET time. Good point. I can envision applications such as the example you cited where choosing the '594 over the '595 (or vice versa) would simplify a given application. > I have never found the bi-directional and other complexities of > the '299 to be of advantage and have always used the '165 devices > for SPI based inputs. No argument here. I mentioned the '299 simply because it happened to be a part that I have in my present parts collection that I have used recently. The '165 is in almost all cases a better alternative. > Thanks for the note on the PRU replacement. TKMOS does sound > familiar as the second source. Regrettably, a rather expensive alternative - $10 USD/ea in small quantities. Also, the part is not readily buy-able by the 'average hobbyist' - you have to deal with main-line distributors, who usually will not give small-volume purchasers the time of day. While I'm on the subject of using 74HCxxx-series devices for I/O support, I'm curious as to if there were ever any 74xxx-series devices developed that provide(d) full read-modify-write style output capability. This has always been (in my mind) the major drawback of using devices like the '573 for output-port creation. Since you cannot read back the contents of these latches (unless you add additional logic, such as a '244 or '540), you cannot use instructions like BSET/BCLR to change individual bits. To perform the equivalent of a bit-set/clear operation, you have to maintain a copy of the last output value in RAM somewhere, then perform a multi- instruction (and register-corrupting) sequence to modify individual output latch bits. I find it somewhat surprising that a 74HCxxx- series device that provided readback capabilities was never developed or put on the market, given that output-port expansion is a fairly common application. |
Reply by ●May 23, 20042004-05-23
|
> -----Original Message----- > From: Bob Smith [mailto:] snip.. > I _really_did_ mean the 74HC594 as the preferred device as > you suggested several lines above. There is (in my mind > anyway) a very important difference between the '595 and > the '594. The more widely manufactured '595 provides an > output enable (OE) function for its registered outputs, > _whereas_ the '594 instead provides an asynchronous reset > function for its registered outputs. This distinction is > important in some applications such as the typical motion > control applications that I work with because the state of > the output port can be assured from RESET time. I use the 595 most of the time, as I use the output enable line often, eg driven with a PWM to control LED brightness. If you required the outputs to power up to a know level this can be achieved with pull-up (down) resisters on the output of the 595, and the output enable disabled, this way some can default high and others low. It's a pity that you can't have both OE and RESET, as I never require the extra reset into the shift reg, that the 595 has. Another chip I have been using lately is the TI TPIC6C595, this is a great device, and at a good price also. It has RESET, and OE, and also 100mA output drivers. Although they are open collector outputs. Darren Moore |
