Octal switches: Maximising MCU pin usage with data busses

It would seem, if I understand you correctly, that you need to use some octal latches such as the 74HC373 or similar. You would wire all of the latchs' data inputs to their respective bits of one of the first port each of the latch's LE (latch enable) inputs to the individual bits of the second port. Your code should first initialize the second port (the latch enables) to all 1's. Then, to write to any of the latches, output the desired data to the first port and then strobe the desired latch enable by setting its second port bit to 0 and then back to 1.

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
    mrkesti at comcast dot net     |          - The Who, Bargain

than

then

all

switches

to

octal

data

latch's LE

code

Then,

and

and

and

instruction

Ello :-)

Erm, I need to go bi-directional. Whoops. Reading and writing via an 8bit bus.

Just trying to get my head round this...

Aly

....

Which is just a 74373[1] variant.

Sounds to me that you need latches in BOTH directions to get around timing issues of each bus, Therefore if you actually need Bi-directional registered transceivers, which Texas Instruments make a range from 8bit wide upwards from 24 pin packages to larger.

Last used the 74652[1] series manyyears ago and need to get your head around the modes.

If you just need latches I would use 74574[1] for easier layout (in one side of chip, out on other side), or for just plain buffers 74245[1].

[1] For 74245 I mean any variant in the 74LS245/HC245/AC245/HCT245/AHC245.... There are many variants. I generally use 74AHC range for 3V3 usage as well as 5V operation.

First look at the timing between the two busses and what you need to see waht can be done.

Personally these days I would use a small PLD for bidirectional multiple busses to sort out timing, latching and simplified control from micro. Especially if the other side could clock and overrun data.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

than

busses

16

and

maintained

to

latchs'

port

0

these

8bit

around

side

74LS245/HC245/AC245/HCT245/AHC245....

well

Hello Paul,

They're the ones :) Brilliant!!

Well here's what I'm practically doing to stop being to cryptic..; SCSI-1

8-bit IDE 16bit conversion. It's for an old piece of kit where one of the requirements is a silent CF card for storage. I can get away with an 16F877, slow although it is, as the kit is from the 1980's anyhow. I'm practically in control of the timing either side as can inhibit/bus master both sides. 8x CF limit is about 1Mbyte/second. SCSI variant is towards the upper 1Mbyte/second too, non parity as well in this case.

What I'm thinking of doing now is having PORTA and PORTB (example) set aside for the IDE words, and say PORTB going through two 74LS245 to double up for the SCSI-1 bus. That then leaves me with 33-16=17 pins for control. Some of these could possibly be doubled up with more 245's, with only the totally critical lines being under direct control. A 2nd MCU for flow control with the main MCU reacting to simplified generated control could be a consideration.

I'm still information trawling at the moment and about 2 weeks away from the IDE side, the SCSI side is so simple as it's a cut down version comprising only 10 or so commands and 2^21 addressable sectors / 1Gb. Big in those days.

Would still be eager to hear of any ideas / approaches on this one.

Aly

Many I/O bound designs have used the concept of a pseudo address and pseudo data busses. Use one port as a bidirectional data buss, do NOT use the PORTA on a PIC unless you confirm that bit 4 is not an open collector style output (it is on the 877), and another port as a control/address buss. The trick is to come up with some routines to keep the signal timings sane as to not have a buss contention when switching from read to write and so on.

Jim

than

busses

16

then

all

chips

switches

to

and

instruction

Hi James,

Thanks for replying, yep will go with things as they come.

I'm presently looking at a central bus to run right through the project, something like this;

The 373 latches I think are there to hold the memory address in place while the RAM is written. So the operation would be to set the RAM address, lock the latches, fetch the byte, dump it in ram, and then move onto the next byte / word.

In some ways I'm tempted to do away with the RAM and latches, as I don't really need to process the information or have it in the PIC, just to pass it back n forth. Say pull a word from the IDE port, and dump it out as 2 bytes to the SCSI-1 non-parity variant. All in real time.

This is very much an information gathering excercise.

Aly :-)