I've never seen an SPI implementation that would allow for a continuous
bit stream. Even highly buffered versions (68332) will pause after 256
bits, or whatever the buffer size is.
If you truly need a continuous bit stream, SPI may not be the way to go.
You might consider building your own double buffered serial transmitter
with a latch, shift register, and a gate or two.
"Reynolds, Alfred" wrote:
> I am a little confused about the SPI port on the MC68EZ328.
> First, if anyone can find documentation about how SPI is implemented in this
> uC I would love to read it.
> Now, the problem. I need to have a constant bit rate (CBR) stream
> (16kbits/sec) on the port. My plan was to use periodic interrupts using
> RTLinux to keep the SPI buffers services (for input and output). As I
> understand it, you copy in your bits (0-16 bits worth), then set enable and
> it starts clocking the bits out. Then, you have to wait for all the bits to
> be finished before you can copy new bits in. How can this method possibly
> provide a CBR stream? Every 16th bit will have a glitch in it (small yes,
> but there).
> Even using the interrupt on the SPI port will have exactly the same problem.
> What is wrong with my thinking?
> It is possible to service the SPI buffers while bits are still coming in? Do
> you copy your 16 bits in, then it moves it to another area and clocks them
> out, leaving you free to copy more in? (So you are constantly 1 "buffer"
> ahead of the data?)
> Has anyone had experience with a CBR stream and can enlighten me ??
This message resent by the email@example.com list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:36 EST