Searching \ for '[PIC] 16F SPI slave multibyte transfers - impossib' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=spi
Search entire site for: '16F SPI slave multibyte transfers - impossib'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F SPI slave multibyte transfers - impossib'
2008\08\06@044440 by Hector Martin

flavicon
face
[Argh, forgot the tag. Sorry for the dupe.]

Hello all,

I seem to have stumbled across a limitation of the 16F SPI peripheral.
I'm trying to implement an SPI slave that communicates with a master
with the following simple protocol (as seen from the master):

Assert SS
SEND 16bit 0x0000 (discard received data)
RECEIVE 32bit
Deassert SS

Clockrate = 1Mhz.

As far as I can tell, implementing this properly on a slave with CKE=1
CKP=0 is not possible, or at least not practical. The transaction is
multibyte, and there is no wait between the two 8-bit halves of, say,
the 16-bit part (and only a small wait between the 16bit and the 32bit
part, since the master here is *very* fast) - the clock just keeps
running. In CKE=1 mode, the first bit of the output data has to be
available as soon as the clock switches into the idle state. However,
that is also (going by the diagrams) the precise moment that BF is set.
Even if the PIC is okay with having SSPBUF loaded after the clock goes
low, I would only have 0.5us to do so before the clock goes high again
and the master samples the data. This isn't enough if you take into
account the BF check latency and the time needed to read, store, and
write to SSPBUF (8 cycles). I'd need a PIC running at over 64Mhz :(

The main problem here is that the TX side of SSPBUF isn't double
buffered, so I have to wait until the first byte is transmitted and then
somehow set up the second byte in the impossibly short amount of time
between them.

When actually trying to implement this, ignoring the timing constraints
(i.e. I'm sure I'm late loading SSPBUF after the first byte), what I see
is that the PIC's SPI peripheral just refuses to perform any
transmissions after the first byte, until SS is reset. Even BF never
gets set again after the first byte is done, and the master just sees
zeroes for the rest. Although I can control the master for debugging
purposes, the protocol is fixed and I can't change it in the final
application.

Have I missed something, or is implementing what I say, in fact, not
possible?

Thanks,
Hector Martin



2008\08\06@095243 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
{Quote hidden}

set.
> Even if the PIC is okay with having SSPBUF loaded after the clock goes
> low, I would only have 0.5us to do so before the clock goes high again
> and the master samples the data. This isn't enough if you take into
> account the BF check latency and the time needed to read, store, and
> write to SSPBUF (8 cycles). I'd need a PIC running at over 64Mhz :(
>
> The main problem here is that the TX side of SSPBUF isn't double
> buffered, so I have to wait until the first byte is transmitted and
then
> somehow set up the second byte in the impossibly short amount of time
> between them.
>
> When actually trying to implement this, ignoring the timing
constraints
> (i.e. I'm sure I'm late loading SSPBUF after the first byte), what I
see
> is that the PIC's SPI peripheral just refuses to perform any
> transmissions after the first byte, until SS is reset. Even BF never
> gets set again after the first byte is done, and the master just sees
> zeroes for the rest. Although I can control the master for debugging
> purposes, the protocol is fixed and I can't change it in the final
> application.
>
> Have I missed something, or is implementing what I say, in fact, not
> possible?

What clock speed is your SPI master running at?  The big problem with
SPI is that there is no mechanism to slow the master down, unlike I2C
where you can use clock stretching.  If you have no control over the SPI
master (i.e. slow down clock speed or make it pause between byte
transfers) this may well be impossible.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\08\06@112801 by Hector Martin

flavicon
face
Michael Rigby-Jones wrote:
{Quote hidden}

It's 1Mhz, and I don't have any control over it. I can experiment all I
want with the master, but the "production" version of the code that this
thing will have to work with has already been written and cannot be
touched (because it would defeat the purpose of this device).

--
Hector Martin (EraseMEhectorspam_OUTspamTakeThisOuTmarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2008\08\06@114750 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: piclist-bouncesspamspam_OUTmit.edu [@spam@piclist-bouncesKILLspamspammit.edu] On
Behalf
> Of Hector Martin
> Sent: 06 August 2008 16:27
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] 16F SPI slave multibyte transfers - impossible?
>
>
> It's 1Mhz, and I don't have any control over it. I can experiment all
I
> want with the master, but the "production" version of the code that
this
> thing will have to work with has already been written and cannot be
> touched (because it would defeat the purpose of this device).
>

Did you see Adams reply to your untagged post?  He's described a cunning
method that might work around the problem.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\08\06@124102 by Alan B. Pearce

face picon face
>Did you see Adams reply to your untagged post?  He's described
>a cunning method that might work around the problem.

Ah, a cunning method (with apologies to Baldric)

Could someone please tag it and resend it?


2008\08\06@130623 by M. Adam Davis

face picon face
I didn't notice the original was untagged, sorry:

Well, it is tricky, but you might be able to do one of the following:

1)
Track the master clock carefully (maybe use a CCP pin?) to get your
timing right, and don't wait for the BF to be set - prepare and then
shove the data into the SSBUF according to a timer you have setup
that's as close to the master clock as possible.  You can probably
safely load it during the last half of the last transmitted bit,
rather than waiting for it to complete before loading.

2)
If you use a PIC with two SPI peripherals (there are 47 18F pics with
two MSSP channels) then you could use external logic to switch between
the two in a sort of double buffering arrangement.  Load the data in
one and while it's feeding the master load the next chunk in the
other.  Switch the clock and data lines to the other (maybe be able to
merely switch the clock line), and reload the first.

3)
Beyond that - you may want to look at using programmable logic chips
(FPGA/CPLD/etc).  This should be able to fit into the
simplest/cheapest of them...

-Adam



On 8/6/08, Alan B. Pearce <KILLspamA.B.PearceKILLspamspamrl.ac.uk> wrote:
> >Did you see Adams reply to your untagged post?  He's described
> >a cunning method that might work around the problem.
>
> Ah, a cunning method (with apologies to Baldric)
>
> Could someone please tag it and resend it?
>
>
> -

2008\08\08@043712 by Hector Martin

flavicon
face
M. Adam Davis wrote:
{Quote hidden}

Solution 3 is what I'll probably use for the final version - a tiny
Xilinx CPLD could certainly do the job well, and they're cheap. I'm not
sure I like solution 2. However, since I already have a board with an
18F PIC built, I'll experiment with 1 and variants of it.

Thanks for the ideas!

--
Hector Martin

2008\08\09@002444 by Dave Lagzdin

picon face
2008/8/6 Alan B. Pearce <RemoveMEA.B.PearceTakeThisOuTspamrl.ac.uk>

> >Did you see Adams reply to your untagged post?  He's described
> >a cunning method that might work around the problem.
>
> Ah, a cunning method (with apologies to Baldric)
>
>
I missed how the turnip fits in?

2008\08\11@045934 by Alan B. Pearce

face picon face
>> Ah, a cunning method (with apologies to Baldric)
>>
>>
>I missed how the turnip fits in?

If you haven't seen the UK originated TV show Blackadder, you would totally
miss the reference. There is a character called Baldric who always has 'a
cunning plan' ...


2008\08\11@051447 by Jinx

face picon face
> >> Ah, a cunning method (with apologies to Baldric)
> >>
> >>
> >I missed how the turnip fits in?
>
> If you haven't seen the UK originated TV show Blackadder, you would
> totally miss the reference. There is a character called Baldric who always
> has 'a cunning plan' ...

And Blackadder would say probably answer something like "Oh, a little
reluctantly, but with some shoulder help from Percy it'll fit just fine"

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...