[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] CC2420 stack status

[Philip Levis]

On Mon, 5 Sep 2005, Joe Polastre wrote:

> There's no reason that the SPI can't be async (in fact, it probably
> should).  The other option is that you use SPIByte to write the first
> 2-3 bytes, and then SPIPacket to write the rest and then get a
> SendDone.  This would work fine too.
>
> Jonathan, Martin, Phil B, and I discussed the SPI interfaces about 5
> months back and all agreed that we liked the Packet based approach
> because it supports a wide array of hardware, including those with DMA
> controllers like imote2 and the msp430.  By making the sendDone async,
> you could do what it was intended for: multiple packet transfers with
> differing read/write parts.  This should still be pretty efficient.

The two above points are a bit contrary; in one case, you'll do a 
hybrid byte-level/packet-level transfer, in the other, you want to have 
only a packet-level interface so you can set up a DMA transfer.

The issue is that even if the sendDone is async, for timing reasons you 
need to either

    1) signal the sendDone from within the send operation,
    2) or control the interrupt sources so something like the timer system
doesn't sneak an interrupt in and add ~600 cycles latency (more on this 
later).

if you want to be able to send a contiguous packet over the SPI.

The issue with using the Byte interface as it's written right now is 
the master/slave relationship. For example, on the atm128, each byte 
operation puts the system into master mode. Instead, what you want is an 
SPIControl interface for stuff like master/slave mode.

These are exactly the issues that we ran into with radio packets. The 
problem is that, for a packet-level interface to be able to work well, you 
need the packet to be contiguous in memory. For the radio stack, we went 
with an alignment/padding approach, in order to prevent a single copy. I 
don't think this is feasible with the SPI. The way I see it, there are 
four basic implementation options:

1) Single copy
    Pros: Simple, easy. Allows split-phase interface above.
    Cons: requires a copy, requires a buffer, how do you size the buffer?

2) Byte-level interface
    Pros: simple, easy.
    Cons: Timing requires loops above (not split phase). Precludes DMA.

3) Scatter-gather
    Pros: Split-phase interface above.
    Cons: Precludes DMA (barring a copy), could be a bit complex to use.

4) Pad message_t for SPI command bytes
    Pros: packet *could* be contiguous.
    Cons: packet may not be contiguous, wastes RAM, size of padding?

5) Hybrid approach (2 + packet, Joe's proposal)
    Pros: current approach.
    Cons: requires lower layer to provide both, precludes full DMA (not 
sure about timing here)


> FYI- When I write an interface, I write everything without async.
> When I need async, I add it in if it makes sense.  In this case, I
> hadn't gotten far enough with the stack where I needed the call to
> occur directly from the interrupt.  Now it is clear that it should, so
> it should be changed to async.  I think with this small change, we
> should be okay.

Maybe. I'll have to look at it more closely. The basic issue is whether 
the byte-level send is interrupt driven or synchronous. If it's the 
former, then issuing an async sendDone is fine. If it's the latter, then 
you can't do it.

Hm. Maybe one thing to try out is a synchronous byte interface, except the 
last byte, when you turn on interrupts, then signal the sendDone in the 
interrupt handler.

I'm going to try out 5, and see how the SPI interfaces need to change to 
make it work. With Phil B.'s recent comment, though, this might be a waste 
of time...

Phil

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg