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.

z-stack end device programming

Expert 1925 points
Other Parts Discussed in Thread: CC2530EM, Z-STACK, CC2530, CC2591

Hi,

I am trying to write a program for an end device of lighting, a CC2530EM board would be placed on the device board in hardware, and i think it's a good way to satrt from the SampleLight example of z-satck.

One thing i am confused is, how the z-stack programs know it would be running in a coordinator or a router or an end device? looks like the defination of  ZSTACK_DEVICE_BUILD is the answer, but, for example, when the program runs to HAL_BOARD_INIT() in Zmain.c, there is no config option which would stop it from run through it, which is by default designed for CC2530EB board, and should not be run through by an end device.

Please help, thanks in advance.

Zhu

  • Hi Zhu,

    To specify the function set of the device you define one of the following.

    • ZDO_COORDINATOR for Coordinator
    • RTR_NWK for Router functionality
    • Nothing for End Device, though there are ED typical definitions, such as POWER_SAVING

    If you are using IAR workbench these definitions are defined in config files,  f8wCoord.cfg, f8wRouter.cfg and f8wEndDevice.cfg, passed to the compiler and referenced in Project Options->C/C++ Compiler->Extra Options.  They are in the Tools file group in the sample projects.

    As you mentioned, these compile options are used to define ZSTACK_DEVICE_BUILD in ZGlobals.h.  

    If you want to know the device type at run time a task usually picks up a state change event:

    T_uint16 task_event_handler ( T_uint8 task_id, T_uint16 events )

    {

    if ( events & SYS_EVENT_MSG )

    {

    MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( this_task_id );

    while ( MSGpkt )

    {

     

    switch ( MSGpkt->hdr.event )

    {

     

    // Handle a state change.

    case ZDO_STATE_CHANGE:

    {

    _deviceState = (devStates_t)(MSGpkt->hdr.status);

    if ( _deviceState == DEV_ZB_COORD )

    {

    // Device is a coordinator.

     

    }

    if ( _deviceState == DEV_ROUTER)

    {

    // Device is a router.

     

    }

     

    if ( _deviceState == DEV_END_DEVICE )

    {

    // Device is an end device.

    }

    } break;

    } // End switch.

     

    // Release the memory.

    osal_msg_deallocate( (T_uint8 *)MSGpkt );

     

    // Next message, if any.

    MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( this_task_id );

     

    } // End while.

    // Discard the event.

    return (events ^ SYS_EVENT_MSG );

     

    } // End if.

    // Discard unrecognized events.

    return (0);

    }

    The device states are defined in ZDApp.h.

    Regarding HAL_BOARD_INIT, this is a macro defined in hal_board_cfg.h which compiles differently depending on which board is selected ( another definition in the file).  To make HAL work for whatever IO configuration you design for your application, you need to customize hal_board_cfg.h.

    iR.

  • Hi, iR,

    Thanks for your detailed description.

    supposed that the CC2530EM board would run on Battery baord, then it will run through HAL_BOARD_INIT(), right?

    Or maybe the content in HAL_BOARD_INIT() is just same for EB or BB board?

    Regards,

    Zhu

  • Hi Zhu,

    The HAL_BOARD_INIT() function is always used to initialize your kind of board. Each board has

    a different description in this function.

    Launix.

  • I think for the CC2530 evaluation projects that there is only one HAL_BOARD_INIT(), ostensibly for the EB05.

    There are a couple of versions for EB05 rev. 1.3 and rev. 1.7, there's also a rev 1.8 EB but I think this uses rev. 1.7 configuration.  These are selected by defining HAL_BOARD_CC2530EB_REV17 or HAL_BOARD_CC2530EB_REV13 in hal_board_config.h.  HAL_BOARD_CC2530EB_REV17 is defined by default.

    Ideally, if you are using another circuit then you want to create a new board definition and specify the correct IO throughout hal_board_config.h, including a new definition for HAL_BOARD_INIT(), though you can probably copy the original and just tweak it a little.  You shouldn't have to change anything in any of the driver files.

    As an example, if you are using LEDs on different pins, say Port 1 pins 5 and 6, then you just need to change #define LED1_SBIT P0_0 to #define LED1_SBIT P1_5 and #define LED1_SBIT P0_1 to #define LED1_SBIT P1_6.  It would be likely in this situation that you might be using NPN transistors to power the LEDs off Vdd or Vbat, so LEDs are on when the pin is low instead of high.  In this case all you have to so is change #define LED1_POLARITY ACTIVE_LOW to #define LED1_POLARITY ACTIVE_HIGH and #define LED2_POLARITY ACTIVE_LOW to #define LED2_POLARITY ACTIVE_HIGH.

    The way to think about it is not as board configuration but as the setup for the microcontroller's peripherals.  Of course, some of the chip's peripherals depend on the circuit, such as LED's and switch inputs.  But Timers, DMA, Flash NVM, UART, Encryption are all, or in part, internal.  The aim is to provide the correct functionality, obviously, but also to minimize power consumption and remove unnecessary code.

    In the case of the EB05 init macro, the only circuit specific code is the LED initializations (assuming you are using the same external crystal), so you could start without those and take it from there.  The chip initializes with peripherals off and IO set to high impedance inputs, which should be a safe place to start regardless of what's attached in the circuit.

    Is this kind of thing helpful?

    iR.

  • Hi, iR and Launix,

    Yes, your replies are helpful of course.

    the EM board can be programmed with codes compiled with End Device option and run on Battery Board, right?

    That's why i think the content in HAL_BOARD_INIT() is just same for EB or BB board.

    thank you, once again.

    Regards,

    Zhu

  • Zhu,

    It might not be power optimized, depending on the IO, but it should work.  Remember, you will also change the IO of the chip if you define LCD_SUPPORTED or HAL_KEY=TRUE and such like.  I don't know the BB circuit but I would guess it would work fine.

    iR.

  • Hi,

    I have question about other boards with CC2530. I have board made by my mate from work, there is only CC2530 with CC2591 and some pins. Nothing else.

    In future he will build next board which willbe connect to this board, with some extra stuff like temperature sensor.

    I work on SampleApp project try to configure it and add some my edits in term of my work. 

    And question is how to configure SampleApp project -> board configuration for that little clear board (my mate board)?

    Greetings.