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

[Joe Polastre]

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.

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.

I don't see a need for rewritting the interfaces or completely
overhauling the design.

-Joe


On 9/5/05, Philip Levis <pal at cs.stanford.edu> wrote:
> It looks like making the CC2420 stack 2.x happy is going to require a
> complete redesign of the HPL interface. The issue I ran into that broke
> the current HPL design is pretty simple: the HPLCC2420RAM interface.
> 
> The interface has a pretty simple call that lets you write to the CC2420
> memory:
> 
> async command error_t HPLCC2420RAM.write(uint16_t addr, uint8_t length,
> uint8_t* buffer) {
> 
> This call sends a RAM write command over the SPI interface to the
> CC2420. The RAM write command is basically the address with a few
> control bits thrown in (3 bytes), followed by the data. The radio then
> pulls the packet out of RAM when it sends it.
> 
> In 1.x, the CC2420 was build on top of a blocking SPI abstraction. So
> what you do is pretty simple: send the first three control/address
> bytes, then enter a for loop to send the data bytes over the bus.
> 
> In 2.x there's a full SPI abstraction, with packet interfaces,
> nonblocking calls, etc. The problem is trying to send a complete RAM
> write request without copying the data buffer. There's no good way to
> send the first three bytes, then the rest of the packet; with the
> interfaces as written, it's very easy to introduce some latencies that
> will cause you to miss out on the data bytes.
> 
> Looking at how the telos code was going to do it, it's taking the
> two-write approach: first you send the control bytes over the SPI, then
> in the sendDone try to send out the data bytes. I'm really wary of this
> approach, especially given that the sendDone is in a task!
> 
> My conclusion is that one of two things needs to happen in order to have
> a usable, cross-platform CC2420 stack that doesn't enter spin loops on
> control registers in atomic sections (which is what the current 2.x
> micaz stack does, following the 1.x code):
> 
> 1) Completely rewrite and redesign the SPI interfaces.
> 2) Institute a single copy.
> 
> I think 1) is greatly preferable to 2). There's no way that I can do
> this by myself: among other things, I'm wary of being responsible for
> designing and implementing the interface, the stack above, and the SPI
> code below.
> 
> There are also a few places where I think the CC2420 HPL abstraction can
> be cleaned up: once we go to a split-phase approach, all of those calls
> to registers become a real nightmare (unlike the 1.x blocking calls).
> Note that the presence of bus arbitration requires that calls be
> split-phase. Looking at the datasheet, you can send multiple commands in
> a single SPI communication, so code like
> 
> call RXFIFO.read();
> call RXFIFO.read();
> call SFLUSHRX.cmd();
> call SFLUSHRX.cmd();
> 
> rather than becoming a 5-state operation, can just be something like:
> 
> put RXFIFO read command into command buf
> put RXFIFO read command into command buf
> put SFLUSHRX strobe into command buf
> put SFLUSHRX strobe into command buf
> send command buf
> 
> Who's interested in working on this? Crossbow? Moteiv?
> 
> 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
>


_______________________________________________
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