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

[Philip Levis]

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