??? 03/16/05 19:08 Read: times Msg Score: +1 +1 Good Question |
#89792 - Contemplating multiprocessor |
I scanned through the archives and found some useful information, but my problem still requires some careful pondering. I'm trying to implement a communication link between two CPUs. I cannot afford dual port memory due to cost (but a 74xx type package or two "maybe") and it needs to be faster than bit-banged I2C or PS/2 et al. I have used both of those before and while they work fine, they are about an order of magnitude slower than I would like. The nice thing is that I have 12 or 13 pins available on each CPU. I was considering something like the following
http://www.8052.com/users/grantbt/CPUA_to_CPUB.jpg ![]() but this leaves a few unanswered questions. I will describe one scenario first and then raise some questions after. I'm just throwing ideas out here, so feedback welcomed (keeping in mind my constraints above). The method proposed (only considering CPU A to CPU B for now) could work something like this: - CPU A asserts BUSY* indicating it wants the "bus". (Some arbitration scheme might be needed... ) - CPU A places data on the 8-bit wide data bus. The first byte is always a byte count. - CPU A asserts RDY* to indicate data is present. - CPU B sees RDY* (assume for now it has already seen BUSY*) and reads the data. CPU B asserts ACK*. - CPU A sees ACK* and de-asserts RDY*. CPU B sees RDY* de-asserted and de-asserts ACK*. - CPU A sees ACK* de-asserted, and since RDY* is de-asserted, CPU A is allowed to set new data on data bus. - ... process continues until "byte count" number of bytes are read then CPU A de-asserts BUSY*. (CPU B would probably bail out anyway, after reading "byte count" number of bytes). This uses a lot of pins and then there is the issue of simultaneous bus requests. And then of course, the whole other direction. I can do this all using O.C. pins, so I'm not worried about the physical layer (and the CPUs are only a cm apart). If I need more control pins then I'd have to move to nibble-wide data instead of bus-wide. Perhaps ACK* and/or RDY* could be employed as part of the arbitration. It would be fine if one of them always "won" request "ties". Both CPUs are producers and consumers of data. Anyone what to chime in on this or other ideas? Thanks, GB |
Topic | Author | Date |
Contemplating multiprocessor | 01/01/70 00:00 | |
fifo | 01/01/70 00:00 | |
and also | 01/01/70 00:00 | |
multiprocessor communication | 01/01/70 00:00 | |
ACKs | 01/01/70 00:00 | |
You want it all and you want it for free | 01/01/70 00:00 | |
Why not HW I2C or SPI | 01/01/70 00:00 | |
Why not HW I2C or SPI | 01/01/70 00:00 | |
USB ??? | 01/01/70 00:00 | |
USB !!! | 01/01/70 00:00 | |
USB | 01/01/70 00:00 | |
You Correct Sir | 01/01/70 00:00 | |
USB != I2C | 01/01/70 00:00 | |
USB > I2C![]() | 01/01/70 00:00 | |
do not multimaster | 01/01/70 00:00 | |
hmm | 01/01/70 00:00 | |
concurrence | 01/01/70 00:00 | |
This is why | 01/01/70 00:00 | |
depends on data rate | 01/01/70 00:00 | |
Normally | 01/01/70 00:00 | |
Are You Sure | 01/01/70 00:00 | |
I would be | 01/01/70 00:00 | |
I would be | 01/01/70 00:00 | |
it works for me | 01/01/70 00:00 | |
Are You Sure | 01/01/70 00:00 | |
IIC speed - no limit | 01/01/70 00:00 | |
nixed by other team members | 01/01/70 00:00 | |
Multi-Proc Xface | 01/01/70 00:00 | |
exactly | 01/01/70 00:00 | |
Shift register (Mode 0)? | 01/01/70 00:00 | |
Time savers | 01/01/70 00:00 |