Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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



List of 31 messages in thread
TopicAuthorDate
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      

Back to Subject List