cc2420

http://docs.tinyos.net/tinywiki/index.php/CC2420_Settings_and_Registers

To interact with registers on the CC2420 chip, the SPI bus must be acquired, the chip select (CSn) pin must be cleared, and then the interaction may occur. After the interaction completes, the CSn pin must be set high.

All registers and strobes are defined in the CC2420.h file, and most are accessible through the CC2420SpiC component. If your application requires access to a specific register or strobe, the CC2420SpiC component is the place to add access to it.

Configuring the CC2420 requires the developer to access the CC2420Config interface provided by CC2420ControlC. First call the CC2420Config commands to change the desired settings of the radio. If the radio happens to be off, the changes will be committed at the time it is turned on. Alternatively, calling sync() will commit the changes to the CC2420.//here，I disable crc check,but it has some errors,so I am learning the chip cc2420 now."First call the cc2420Config command",does it means I must call it?when I have changed the cc2420config.I will try it later-yliang

RSSI can be sampled directly by calling the ReadRssi interface provided by CC2420ControlC. See page 50 of the CC2420 datasheet for more information.

http://docs.tinyos.net/tinywiki/index.php/CC2420_Layer_Architecture

The CC2420 radio stack consists of layers of functionality stacked on top of each other to provide a complete mechanism that modifies, filters, transmits, and controls inbound and outbound messages. Each layer is a distinct module that can provide and use three sets of interfaces in relation to the actual radio stack:Send, Receive, and SplitControl. If a general layer provides one of those interfaces, it also uses that interface from the layer below it in the stack. This allows any given layer to be inserted anywhere in the stack through independant wiring. For example:

 provides interface Send; uses interface Send as SubSend;  provides interface Receive; uses interface Receive as SubReceive;  provides interface SplitControl; uses interface SplitControl as subControl;
 

The actual wiring of the CC2420 radio stack is done at the highest level of the stack, inside CC2420ActiveMessageC. This configuration defines three branches: Send, Receive, and SplitControl. Note that not all layers need to provide and use all three Send, Receive, and SplitControl interfaces:

 // SplitControl Layers SplitControl = LplC; LplC.SubControl -> CsmaC;  // Send Layers AM.SubSend -> UniqueSendC; UniqueSendC.SubSend -> LinkC; LinkC.SubSend -> LplC.Send; LplC.SubSend -> TinyosNetworkC.Send; TinyosNetworkC.SubSend -> CsmaC;  // Receive Layers AM.SubReceive -> LplC; LplC.SubReceive -> UniqueReceiveC.Receive; UniqueReceiveC.SubReceive -> TinyosNetworkC.Receive; TinyosNetworkC.SubReceive -> CsmaC;

If another layer were to be added, CC2420ActiveMessageC would need to be modified to wire it into the correct location.

// what is the real meaning?I am muddled!how to add a new one?-yliang

http://docs.tinyos.net/tinywiki/index.php/CC2420_Layer_Descriptions

CC2420 Layer Descriptions

Contents

 [hide]

• 1 ActiveMessageP
• 2 UniqueSend
• 3 PacketLink
• 4 DefaultLpl
• 5 UniqueReceive
• 6 TinyosNetwork
• 7 CSMA
• 8 TransmitP/ReceiveP
• 9 CC2420 Layer Diagram
• 10 See Also
• 11 Next

ActiveMessageP  // for app level,fill in details in the packet header-yliang

This is the highest layer in the stack, responsible for filling in details in the packet header and providing information about the packet to the application level[2]_. Because the CC2420 radio chip itself uses 802.15.4 headers in hardware [1]_, it is not possible for the layer to rearrange header bytes.

UniqueSend     //for detect duplicate packets-yliang

This layer generates a unique Data Sequence Number (DSN) byte for the packet header. This byte is incremented once per outgoing packet, starting with a pseudo-randomly generated number. A receiver can detect duplicate packets by comparing the source and DSN byte of a received packet with previous packets. DSN is defined in the 802.15.4 specification.

PacketLink

This layer provides automatic retransmission functionality and is responsible for retrying a packet transmission if no acknowledgement was heard from the receiver. PacketLink is activated on a per-message basis, meaning the outgoing packet will not use PacketLink unless it is configured ahead of time to do so.PacketLink is most reliable when software acknowledgements are enabled as opposed to hardware auto acknowledgements.

DefaultLpl  //

This layers provides a default asynchronous low power listening implementation. Supporting it is PowerCycleP, which is responsible for turning the radio on and off and performing receive checks. Each receive check only keeps the radio on long enough to take a physical energy reading on the channel. After energy is detected during a receive check, PowerCycleP hands off responsibility to DefaultLplP to perform some transaction and turn the radio off when convenient. Packetized wake-up transmissions are generated on a per-message basis, not globally, and the layer will continuously retransmit the full outbound packet until either a response from the receiver is heard or the transmit time expires.

Other low power communication implementations have been experimented with, including a BMAC type method in which a transmitter node transmits a continuously modulated wake-up transmission. A continuously modulated signal allows a receiver's energy check to be incredibly small, which saves lots of power in networks that spend most of their time listening. This method was never stable enough to make public, only due to time constraints in development.

UniqueReceive

This layer maintains a history of the source address and DSN byte of the past few packets it has received, and helps filter out duplicate received packets.

TinyosNetwork  

This layer allows the TinyOS 2.x radio stack to interoperate with other non-TinyOS networks. Proposed 6LowPAN specifications include a network identifier byte after the standard 802.15.4 header [5]_. Interoperability frames are now the default. This dispatch layer provides functionality for setting the TinyOS network byte on outgoing packets and filtering non-TinyOS incoming packets.

CSMA   // here,it means that csma is not implemented in csma but in cc2420TransmitP ?

This layer is responsible for defining 802.15.4 FCF byte information in the outbound packet, providing default backoff times when the radio detects a channel in use, and defining the power-up/power-down procedure for the radio.

Unfortunately, the actual CSMA implementation is integrated with the code in CC2420TransmitP. Volunteers are needed to redo this architecture and allow the CC2420TransmitP layer to asynchronously attempt a packet transmission. This would let the CSMA layer truly perform backoffs, and allow researchers to build other types of channel sharing mechanisms (i.e. TDMA). The CC1100/CC2500 radio stack is a good architecture example, separating the CSMA behavior from the transmission functionality.

TransmitP/ReceiveP

These layers are responsible for interacting directly with the radio through the SPI bus, interrupts, and GPIO lines. Again, the TransmitP layer is actually responsible for performing the CSMA functionality right now.

CC2420 Layer Diagram

+--------------------------------------------------+|               Application Layer                  ||                                                  |+-----------------------+--------------------------+  +----------------------+-------------------------+ |             Active Message Layer               | +----------------------+-------------------------+  +----------------------+-------------------------+ |              Unique Send Layer                 | +----------------------+-------------------------+                   +----------------------+-------------------------+ |         Optional Packet Link Layer             | +----------------------+-------------------------+                         +----------------------+-------------------------+ |  Optional Low Power Listening Implementations  | +----------------------+-------------------------+                         +----------------------+-------------------------+ |        Unique Receive Filtering Layer          | +----------------------+-------------------------+                         +----------------------+-------------------------+ |      Optional 6LowPAN TinyOS Network Layer     | +----------------------+-------------------------+                         +----------------------+-------------------------+ |     Carrier Sense Multiple Access (CSMA)       | +----------------------+-------------------------+                                                           +----------+----------+   +----------+----------+|      ReceiveP       |   |      TransmitP      |+----------+----------+   +----------+----------+                                                            +-----------------------+-------------------------+|    SPI bus, GPIO, Interrupts, Timer Capture     |+-------------------------------------------------+

http://docs.tinyos.net/tinywiki/index.php/CC2420_Hardware_and_Software_Acks

CC2420 Hardware and Software Acks

Originally, the CC2420 radio stack only used hardware generated auto-acknowledgements provided by the CC2420 chip itself. This led to some issues, such as false acknowledgements where the radio chip would receive a packet and acknowledge its reception and the microcontroller would never actually receive the packet.

The current CC2420 stack uses software acknowledgements, which have a higher drop percentage. When used with the UniqueSend and UniqueReceive interfaces, dropped acknowledgements are more desirable than false acknowledgements. Received packets are always acknowledged before being filtered as a duplicate.  // first ack then filter

Use the PacketAcknowledgements or PacketLink interfaces to determine if a packet was successfully acknowledged.

Acknowledgment Controls

Defining the preprocessor variable CC2420_NO_ACKNOWLEDGEMENTS will disable all forms of acknowledgments at compile time.

Defining the preprocessor variable CC2420_HW_ACKNOWLEDGEMENTS will enable hardware acknowledgments and disable software acknowledgments.

Acknowledgments can also be toggled at run-time by accessing the CC2420Config interface provided by CC2420ControlC. Be sure to sync() the hardware if you reconfigure the CC2420 radio at runtime.

 /**  * Sync must be called for acknowledgement changes to take effect  * @param enableAutoAck TRUE to enable auto acknowledgements  * @param hwAutoAck TRUE to default to hardware auto acks, FALSE to  *     default to software auto acknowledgements  */ command void CC2420Config.setAutoAck(bool enableAutoAck, bool hwAutoAck) {   atomic autoAckEnabled = enableAutoAck;   atomic hwAutoAckDefault = hwAutoAck; }  /**  * @return TRUE if hardware auto acks are the default, FALSE if software  *     acks are the default  */ async command bool CC2420Config.isHwAutoAckDefault() {   atomic return hwAutoAckDefault;     }  /**  * @return TRUE if auto acks are enabled  */ async command bool CC2420Config.isAutoAckEnabled() {   atomic return autoAckEnabled; }

 

http://docs.tinyos.net/tinywiki/index.php/CC2420_Packet_Formats

CC2420 Packet Formats

The CC2420 Packet structure is defined in CC2420.h. The default I-Frame CC2420 header takes on the following format:::

 typedef nx_struct cc2420_header_t {   nxle_uint8_t length;   nxle_uint16_t fcf;   nxle_uint8_t dsn;   nxle_uint16_t destpan;   nxle_uint16_t dest;   nxle_uint16_t src;   nxle_uint8_t network;  // optionally included with 6LowPAN layer   nxle_uint8_t type; } cc2420_header_t;

All fields up to 'network' are 802.15.4 specified fields, and are used in the CC2420 hardware itself. The 'network' field is a 6LowPAN interoperability specification only to be included when the 6LowPAN TinyosNetwork layer is included. The 'type' field is a TinyOS specific field.

The TinyOS T-Frame packet does not include the 'network' field, nor the functionality found in the Dispatch layer to set and check the 'network' field.

No software footer is defined for the CC2420 radio. A 2-byte CRC byte is auto-appended to each outbound packet by the CC2420 radio hardware itself.

On reception of a packet, the 2-byte hardware generated CRC is replaced with an RSSI and LQI byte. The most significant bit of the LQI byte represents a boolean CRC pass/fail.

The maximum size of a packet is 128 bytes including its headers and CRC, which matches the 802.15.4 specifications. Increasing the packet size will increase data throughput and RAM consumption in the TinyOS application, but will also increase the probability that interference will cause the packet to be destroyed and need to be retransmitted. The TOSH_DATA_LENGTH preprocessor variable can be altered to increase the size of the message_t payload at compile time.