Difference between revisions of "CC1100/CC2500 Recent Updates"
(→January 22, 2008) |
(→January 22, 2008) |
||
| Line 13: | Line 13: | ||
* '''Note''' the dual-radio platform cannot power on both radios simultaneously, even if all pins and interrupts are completely disconnected in software. Each radio must be powered on separately with FET switches. | * '''Note''' the dual-radio platform cannot power on both radios simultaneously, even if all pins and interrupts are completely disconnected in software. Each radio must be powered on separately with FET switches. | ||
* Removed load() and loadDone() from the AsyncSend interface. | * Removed load() and loadDone() from the AsyncSend interface. | ||
| + | * Modified the arguments to the AsyncSend.send interface: ''async command error_t send(void *msg, bool force, uint16_t preambleDurationMs);'' | ||
| + | * Changed the MCSM1 register on both radios from 0x3F to 0x2F, which allows the radio to transmit all the time except when it's receiving. This means it's up to the software to perform CCA checks. | ||
| + | * The new BlazeTransmit implementation REQUIRES fast SPI bus access. For the MSP430, this means ENABLE_SPI0_DMA needs to be defined and made default. | ||
''Tests'' | ''Tests'' | ||
| Line 19: | Line 22: | ||
* Created a PowerCycle application in the ccxx00/integration/dual test directory for continuous debugging. | * Created a PowerCycle application in the ccxx00/integration/dual test directory for continuous debugging. | ||
* Integration PowerCycle test passed on the blaze dual-radio platform (20000 power cycles) | * Integration PowerCycle test passed on the blaze dual-radio platform (20000 power cycles) | ||
| + | * MultiTransmit test created for new AsyncSend interface and implementation | ||
== January 22, 2008 == | == January 22, 2008 == | ||
Revision as of 15:25, 23 January 2008
The CCxx00 radio stack is getting some new architecture. The last stable working version may be checked out from CVS using a special update by date, on or before January 20, 2008.
January 22, 2008
Status
- NON-OPERATIONAL: Working on the SplitControl pipeline through the radio stack, while solidifying BlazeInit.
Updates
- Removed the Blaze development platform HplCC1100PinsP and HplCC2500PinsP, replaced them with a generic module called HplCCxx00PinsP.
- Removed the hacks from BlazeInitP after getting the dual-radio platform to pass PowerCycle testing
- Note the dual-radio platform cannot power on both radios simultaneously, even if all pins and interrupts are completely disconnected in software. Each radio must be powered on separately with FET switches.
- Removed load() and loadDone() from the AsyncSend interface.
- Modified the arguments to the AsyncSend.send interface: async command error_t send(void *msg, bool force, uint16_t preambleDurationMs);
- Changed the MCSM1 register on both radios from 0x3F to 0x2F, which allows the radio to transmit all the time except when it's receiving. This means it's up to the software to perform CCA checks.
- The new BlazeTransmit implementation REQUIRES fast SPI bus access. For the MSP430, this means ENABLE_SPI0_DMA needs to be defined and made default.
Tests
- Integration PowerCycle test passed on a blaze2500 platform (10000 power cycles)
- Integration PowerCycle test passed on a blaze1100 platform (10000 power cycles)
- Created a PowerCycle application in the ccxx00/integration/dual test directory for continuous debugging.
- Integration PowerCycle test passed on the blaze dual-radio platform (20000 power cycles)
- MultiTransmit test created for new AsyncSend interface and implementation
January 22, 2008
Status
- NON-OPERATIONAL: In a state of flux, dividing the prototype Blaze radio stack (blazeradio) into a new ccxx00 directory which will contain the final CCxx00 radio stack architecture.
Updates
- Updated all .platform files to point to the new ccxx00 directory
- Created a SplitControlManager component to reside just underneath the RadioSelect module.
- Isolation unit tested the SplitControlManager. All tests pass.
- Removed SplitControl functionality from RadioSelect module. The RadioSelect module is now entirely responsible for converting the non-parameterized Send and Receive interfaces it provides into parameterized Send and Receive interfaces it uses.
- Wired SplitControlManager into CC2500ControlP and CC1100ControlP to prevent Configuration commits to the radio registers when the radio is off.
- Removed SplitControl managing functionality from BlazeInit.
- Removed the BlazePower interface, replaced it with internal functions in BlazeInitP. The SplitControl and BlazeCommit interfaces are the only interfaces that should be interacting with the hardware. Also removed BlazePower connections from CC2500ControlC and CC1100ControlC.
Tests
- Isolation test created for SplitControlManager in a new blaze/tos/chips/ccxx00/ directory in TUnit: blaze/tos/chips/ccxx00/isolation/SplitControlManager.
- All tests pass.
- Integration test for BlazeInit SplitControl interface (ccxx00/integration/cc2500/init/PowerCycle) - duty cycle the power on and off.
- Test passed on a tmote2500 platform (10000 power cycles)
January 21, 2008
Status
- NON-OPERATIONAL: implementing better SplitControl architecture.
Updates
- Reduced the number of SPI register burst init elements from 39 to 25, decreasing the time it takes for init.
- Added the RadioReset interface and HplRadioResetC/P modules to allow the driver to check the SO line to see that the radio has been automatically powered up on reset.
- Removed RfResource and PriorityQueue from the radio stack.
- Removed while-loop hack functionality in BlazeInitP - this still needs to be tested with various hardware
Tests
- Created AutomaticPor test to test the RadioReset interface, which I have implemented for the MSP430-based platforms
January 20, 2008
Status
- OPERATIONAL. Stable on the MSP430. Full of hacks to try to get the hardware working. The radio typically refuses to go into TX mode on Atmega128 platforms.
