Hi Don,
>
> I don't know of any 21-bit memory devices.
>
> So 24 bits is just as good.
Right, its not a memory device, the objective is to
emulate the interface to a 21-bit serial-interface angular
encoder (used on radio telescopes in this application).
Its not an SPI device either, more like a 21-bit shift-register.
> SPI transfers are 8-clocks then an interrupt. ( if enabled)
> If there is ony 5 clocks, how does the receiver know that byte is
> valid. And where will the interrupt happen?
The 5-bit transaction is the last, so I don't think it will
matter. If I use a timer channel to count clock edges, then
I should be able to tell when the transaction is done.
Depending on the microVAX control signals, one of those
may deassert when it is done, so I can just use that
to determine the end-of-transaction too.
The way I envisage it is;
- microVAX asserts its request signal (which would
be routed to an LPC interrupt)
- LPC reads the encoder position, checks CRC etc.
- LPC asserts acknowledge to the microVAX
- the microVAX then expects to clock 21-bits of
data from the 'encoder' (which is now the LPC processor).
The LPC device will write the first 8-bits to the SPI
transmit register before acknowledging to the microVAX.
The microVAX (as the SPI master) will then clock those 8-bits
out after receiving the acknowledge. Once the first 8-bits
are shifted, an LPC SPI IRQ will fire, and the second
8-bits will be written to the SPI transmit register,
and ditto for the last byte that contains 5 valid
bits.
The microVAX code will not be modified, so it'll only
send 21-clocks (not 24-clocks). The last byte written
to the SPI transmit register will never be fully
transmitted, hence my comment that I would deassert
SSEL triggering an abort (which is ok, since the
microVAX has already read the data).
> If the clock is not running, then you can take as long as you want
> before the next byte. The slave SPI port can not force the master to
> do anything. It will just have to wait.
Right, but in this app, the LPC is the SPI slave to the
microVAX master, and so the microVAX is controlling
the clock timing. (Which I have yet to obtain, as
I am waiting for another engineer to supply it).
> The SPI port is just fine. Unless you need an FPGA ?
Yep, if the SPI port works that's what I'll use.
So the question still remains as to what is the bit
timing of a multi-byte SPI transaction with regard to;
* bit 7 (the last bit of the first byte) and bit 8
(the first bit of the second byte)
* bit 15 (the last bit of the second byte) and bit 16
(the first bit of the third byte)
i.e., I'm unsure about what happens with the data on the
SPI slave output pin during the following sequence;
- last bit is present on the slave-out pin
- SPI interrupt occurs
- new data is written to the SPI transmit register
now, if the SPI transmit register is directly connected
to the SPI slave out pin, the data on the slave output
will change when the transmit register is written to.
If its not directly connected and in fact there is a
1-bit slave output register, then the data will stay
until the next clock edge from the microVAX master comes
along.
So, perhaps that last description clarifies my concern.
(I'm not really looking for a solution, I can figure
it out, just leaving these comments 'out there' until
I have time to code up a couple of tests).
Dave