| ??? 09/09/04 14:01 Read: times |
#77128 - RE: Alternative bus strategies Responding to: ???'s previous message |
Erik: If you implement the "slave holding the line low means busy" technique and make that work without performance attrition, I will be surprised, I have tried many ways, but with no success. I tend to agree. And when I wrote the previous message I actually was going to include the note that, really, the slave should never mark itself as busy. The only time I can imagine a slave being busy is if the central 8052 issued it a command that it knows is going to take some amount of time to execute but that the slave immediately ackowledges so the central 8052 can go do other things. Even so, the slave should be able to receive and buffer additional commands as long as the subsequent commands don't depend on the result of the previous command being done. Anyhow all schemes I have used with any success are based on communicating via ISR driver. I agree that ISR is the only way we should consider going about this regardless of the bus we select. I have found that using chips with hardware IIC I can achieve a "communication does not slow the process down" operation. Parallel I have achieved it by the communications control lines being interrupts at the receiving end and this can be achieved by using the "lots of interrupt sources" chips. E. g. a comparator input that generate an interrupt acn be used just as well as a logical interrupt source. I'm starting to think that if we have some kind of shared or DMA memory that we could consider an I2C bus since any large quantities of data would be passed through memory itself but if there isn't shared memory we ought to consider a parallel approach similar to what I suggested above. Regards, Craig Steiner |
