Content originally posted in LPCWare by MindBender on Mon Aug 03 00:48:27 MST 2015
Quote: rocketdawg
Leaving MISO disabled for the addr and cmd would make the master clock in Hi-z bits. We assume the master is not interested in this return data anyway.
True. But a remarkable side-effect of disabling MISO is that during this period, the slave is not dequeueing data from the TX FIFO.
Quote: rocketdawg
Might be better to leave MISO active and just prime the slave FIFO with 2 bytes of dummy data to send out.
That data is placed in the FIFO (at init, and) when CS goes high, so it is ready to send when CS goes low.
Would be better indeed, but not necessary because of the property above.
And we can't leave MISO active on our bus: The first byte is an address byte, addressing one of multiple slaves sharing a single CS line... Yeah, I know what you're thinking.
For a test, I have left MISO enabled all the time, to rule out that shenanigan being the cause of the problem, but it's not.
Quote: rocketdawg
what I do not see is the master sending out a dummy byte so it can clock in the rply from the slave. Or is that just missing from the ascii art?
Well, it's a synchronous bus, so as long as there's a clock, there's data. Perhaps not valid data, but still data. In the ASCII art I have drawn don't-care data as an asterisk. And the clock is drawn as hashes. It may not be very clear, because I drew it on a byte level, not a bit level.
Quote: rocketdawg
I see the clock, but that should only occur if there is master data being sent, so I assume it is being sent.
I'm sure we mean the same: Either read, write or read/write transactions require a clock. You can just read or write, but one doesn't go without the other, so there will be don't-care data.
Quote: rocketdawg
the problem is, that the master has no way of telling when the slave will have the data ready for the response, so it does not know when to send the dummy.
I assume it takes some time for the slave to calculate the response from the addr/cmd, and I bet that time is something like 1/120kHz.
you might want to rethink this protocol or have a sufficient delay time so that the slave is always ready.
That's why the reply byte is delayed a bit; It will give the slave time to prepare data.
I'm afraid I don't have the luxury to rethink this protocol. It's not mine; I just need to develop a slave to work with this protocol in existing equipment. Personally I would not have went with SPI in the first place, because the slave not being able to tell the master there's no data yet, is a problem I have encountered many times before. I2C is superior in that way (clock stretching) and many more ways.