• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 57 subscribers
  • Views 550 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530 and Zigbee 2007... any news?

Steve3483
Intellectual 645 points

Other Parts Discussed in Thread: CC2430, CC2530, Z-STACK

Hi,

I understood that a 256k version of the CC2430 was expected Q4 2008.

Anyone know what's happening?

Steve

 

  • 0
    TI__Prodigy 510 points

    Steve,

    Unfortunately the information you received on the CC2430 is incorrect.  We will not be releasing a 256K version of the existing CC2430 chip.  However please stay tuned for upcoming product announcements in the not too distant future.

    Thanks,

    Brian

  • 0 in reply to PME_BLUM
    Intellectual 645 points

    Hi Brian,

    We've hit the buffers on the CC2430 with our application image now running at over 118k. We've had to cut much needed functionallity even to get down to this.

    Are you saying that an 8051 based Zigbee SOC with more than 128k will not be happening RSN?

     

    Steve.

     

  • 0 in reply to Steve3483
    Expert 1835 points

    Hi Steve,

    CC2430 won't have other revision. The next ZigBee soc will be the CC2530 which is a 8051 core and accept ZigBee 2007 Zstack.

    Launix.

  • 0 in reply to launix
    Prodigy 30 points

    I'm waiting for SOC by CC2520TRX & MSP430F6core ,,,

  • 0 in reply to tkashi
    TI__Prodigy 510 points

    tkashi,

    Thanks for your feedback and input on the community forum.  Out of curiousity can you comment on why you would like the 802.15.4 SoC with the MSP core?  Are you looking for lower power, the use of MSP430 tools, or any other particular feature?  You might be surprised when you start to look into the capabilities of the 8051 as it is quite a good core for this market.

  • 0 in reply to PME_BLUM
    TI__Expert 4155 points

    Most applications don't need to use the REFLECTOR compile option. This brings in all the binding functionality which is typically not needed and sometimes easier and more convenient to do service discovery and device discovery
    via an application developed algorithm using the match descriptor request followed by a simple descriptor request. The source device then just stores the destination address of the short address of the match. This method requires
    less information to be stored in the binding table as only the short address of the destination needs to be saved. Your application can use the NV memory apis to store a user section.

    You can also turn off any HAL drivers that are not needed (e.g HAL_LCD=FALSE).

    Also, defining HALNODEBUG removes all the MAC assert code that is there in the MAC for debug purposes.

    Turn off any MT compile options that are not needed, such as MT_TASK, MT_ZDO_FUNC, ZTOOL_P1, etc.

    Use an external flash to store NV memory. You will have to write your own flash driver, but this will save 4K of code since we use 2 2K pages for our stack NV memory.

    If you are also not using Z-stack 1.4.3-1.2.1, you need to upgrade as they uses 7.30B of the IAR EW8051 that provides significant code savings as code bank utilization was optimized in this version of the compiler.