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

[Phil Buonadonna]

Although I would have to dive back in to see the details of what Phil L. is
talking about, it is the case that we tried to form an SPI interface that
supported DMA capability.  This is pretty critical...

An interface that isn't tolerant of some hardware device independantly
moving bits is a non-starter.

pb
 

-----Original Message-----
From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU
[mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On Behalf Of Joe
Polastre
Sent: Monday, September 05, 2005 4:00 PM
To: Philip Levis
Cc: tinyos2 group
Subject: Re: [Tinyos-2.0wg] CC2420 stack status

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


_______________________________________________
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