unebonnevie 
Hi,
I am planning to use the 74HC245, which is a directional bus. Say, the 74HC245 is between two simple pieces of firmware sending data to each other via the 74HC245. If one end of the firmware wants to send two consecutive zeros, that is, two 0x00 bytes, through the 74HC245. How would the other end now that there is also a 2nd 0x00 byte, since it's the same byte as the 1st 0x00 byte?
Thanks.
It probably needs to be strobed (e.g. "clocked")
Jim
The fact that two values are identical is irrelevant. How does either unit know that the other wants to send data. Someone is going to have to control the direction of the buffer.
And what happens if they both want to send at the same time?
Why do you even need the buffer?
As Jim suggests, you need extra signals to manage the transfer. You need to implement a mechanism whereby the transfer of data is controlled by both devices. - otherwise known as 'handshaking'
Try to google ECP and EPP for the PC printer port.
>> How would the other end now that there is also a 2nd 0x00 byte
You could send a byte at a time, flip the bus direction, and wait for an ack from the receiver after every byte. Not very efficient but you do get an explicit confirmation of receipt (or a timeout), which may be useful depending on your 'protocol'. You could also implement a 'nack' response when the byte received is incorrect or unexpected, according to the protocol. Rather like an RPC (remote procedure call).
>> sending data to each other
I assume you have some kind of protocol, otherwise how would you know which node is the sender and which the receiver, and thus the bus direction, at any point in time ?
>> simple pieces of firmware
Or, perhaps you don't care, or don't want the associated complexity or overhead.
clawson 
Try to google ECP and EPP for the PC printer port.
unebonnevie I think you're suggestion is good, without clocking, as I had also thought. The 74HC245 has a directional pin, which can act and input/output direction. I think flipping direction, coupled with a defined protocol, with an ACK/NACK can help.
Thanks, all, for your input.
The traditional use of a 245is to enable bidirectional communication between two busses. Which is what you want... you'd often find it, for example, between the data bus of a processor and some external device.
But there are two controls to it: an output enable, which enables the normally high impedance output of the device, and the direction, which says which of the two ports is the output and which is the input. Driving those controls is more likely to be an issue for the hardware design (e.g. a r/~w signal to select direction, and a decoded address line to enable) than for a software protocol; if you want to drive those two pins there's nothing to stop you, but you'll need extra signals to do it (as well as something to tell the other end that you either have data to send, or that you expect to receive data).
One thing you might consider is using a latch (e.g. hc374, or for a better pinout in many cases, hc574). You'll need two of them; each has its outputs connected to the inputs of the other and to the data bus of the far end. You still need a flag from each end to say data is available... either end can write to its own latch, but only the other end can read it, so now you can write asynchronously and the data will stay there until the other end decides to read it. Ideally, you'd have a signal from the far end to say it's ready to receive, and one to say it has data waiting. You achieve the same result as using the single 245 but without the need for synchronisation between the busses. If you're planning on driving the 245 from a microcontroller data port, you don't need this, but then, you don't need the 245 either; just a control signal to say what's going on.
<A wants to send data to B>
- A observes that B is asserting 'I am ready to receive'
- A places data on output port
- A asserts 'I have data' signal
- B sees A's 'I have data' signal and reads the data
- B deasserts 'I'm ready to receive'
- A observes B's 'I am ready to receive' is not asserted and deasserts it's own 'I have data' signal
- B asserts 'I'm ready to receive'
And of course, the same in reverse if B wants to talk to A; each transfer is unique and so can be interleaved. Placing data on an output port is the same as writing to a latch.
I recall a very handy interface chip for the 6502/6800 processors forty years ago that included outputs specifically for this situation, but handled in the hardware if IIRC: an external write could latch data onto a port, while an internal write to the port generated a data waiting signal. Don't think it was bidirectional on the same port, though.
Neil
unebonnevie The traditional use of a 245is to enable bidirectional communication between two busses. Which is what you want... you'd often find it, for example, between the data bus of a processor and some external device.
But there are two controls to it: an output enable, which enables the normally high impedance output of the device, and the direction, which says which of the two ports is the output and which is the input. Driving those controls is more likely to be an issue for the hardware design (e.g. a r/~w signal to select direction, and a decoded address line to enable) than for a software protocol; if you want to drive those two pins there's nothing to stop you, but you'll need extra signals to do it (as well as something to tell the other end that you either have data to send, or that you expect to receive data).
One thing you might consider is using a latch (e.g. hc374, or for a better pinout in many cases, hc574). You'll need two of them; each has its outputs connected to the inputs of the other and to the data bus of the far end. You still need a flag from each end to say data is available... either end can write to its own latch, but only the other end can read it, so now you can write asynchronously and the data will stay there until the other end decides to read it. Ideally, you'd have a signal from the far end to say it's ready to receive, and one to say it has data waiting. You achieve the same result as using the single 245 but without the need for synchronisation between the busses. If you're planning on driving the 245 from a microcontroller data port, you don't need this, but then, you don't need the 245 either; just a control signal to say what's going on.
<A wants to send data to B>
- A observes that B is asserting 'I am ready to receive'
- A places data on output port
- A asserts 'I have data' signal
- B sees A's 'I have data' signal and reads the data
- B deasserts 'I'm ready to receive'
- A observes B's 'I am ready to receive' is not asserted and deasserts it's own 'I have data' signal
- B asserts 'I'm ready to receive'
And of course, the same in reverse if B wants to talk to A; each transfer is unique and so can be interleaved. Placing data on an output port is the same as writing to a latch.
I recall a very handy interface chip for the 6502/6800 processors forty years ago that included outputs specifically for this situation, but handled in the hardware if IIRC: an external write could latch data onto a port, while an internal write to the port generated a data waiting signal. Don't think it was bidirectional on the same port, though.
Neil
Thank you very much for your input!
What is the problem you want to solve? Usually for inter-processor communication the more obvious choices would be spi, I2C (twi) or uart. This is because most microcontrollers have specific hardware to implement them. Using your proposed 8 bit parallel method, not only will you use more port pins, the net performance may be less than other methods.
I would question why the bus transceiver is even needed. If you have to pass a full 8-bit byte in parallel, just wire the two ports together, and add a couple of handshake lines.
What I would do, then, is to have both ports idle in inputs with pull-ups on. The one sending asserts one of the handshake line and, when ack'd by the other,. puts the data on its port. Maybe it holds for a specific time, or holds until it releases its handshake line or holds until its partner releases the partner's handshake line. Any of those would probably work. Pretty simple. Lower cost.
Jim
There's always DN035 which can be found in Tutorials in the Design Notes topic.
