• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 1289 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.

Adding/Initializing Application Objects with ZCL/AF while OSAL system is running?

Jeff Lia
Intellectual 270 points

Other Parts Discussed in Thread: Z-STACK

Hello,

I've followed the Z-Stack Home Developer's Guide's "One OSAL Task per many Application Objects" application design and all is working fine.

The single task initialization performs:

  1. initialization of variables specific for the corresponding Application Object
  2. initialization and registration of the Application Object with the AF layer by executing:
    1. zclHA_Init
    2. zclGeneral_RegisterCmdCallbacks
    3. zcl_registerAttrList
    4. afRegister
  3. registration with the applicable OSAL or HAL system services (e.g. RegisterForKeys)

Post task initialization, the OSAL system is started and runs indefinitely without problem.

So here's the question...

I would like to (if possible) be able to do all the above and then, while the system is running, register additional Application Objects with the AF layer (all of step 2 above) on the fly.  Furthermore, I'd like to be able to unregister Application Objects such that the system behaves as if they never existed.

Is this possible?

The reason I'd like to do this is because my project has 2 pieces of hardware: let's call them the base and the module.  When the base starts up, I'd like for it to execute steps 1-3 effectively exposing all the Application Objects that exist within the base hardware.  Then, when the hardware module connects, I'd like for the base hardware to register the Application Objects that exist on the module.  Furthermore, if the module detaches, I'd like the base to unregister all the module Application Objects such that the system is running just like it was before the module became available (attached).  In reality, the Application Objects do not exist in the base firmware -- they are communicated to the base from the module.  However, for simplification purposes, let's ignore this and assume the all the Application Objects exist in the base firmware and all that the act of connecting the module to the base triggers an event within the base that indicates this special group of Application Objects (that is always initialized and available for the base firmware) should be registered, or unregistered if the module is disconnected.

My fallback solution is that when the module attaches, I just restart the entire OSAL system which would include physically resetting the CC2530ZNP.  Though, I am wondering if there is a better solution, as ideally I would be able to register these objects without disconnecting and rejoining the ZigBee network.

For example, can I just restart the OSAL system but leave the CC2530ZNP on the network?

Or, can I just register and unregister Application Objects at will while the OSAL system is running?

Or, something else?

Please advise best practices.

Thanks in advance,

Jeff

  • 0
    Guru 735695 points
    There is no way to unregister objects. The alternative is that You can do a restart to your device and do some "if-else" to register different object in init function according to module is plug in or not.
  • 0 in reply to YiKai Chen
    Intellectual 270 points
    Thank you YK Chen,

    So since I cannot unregister objects, would it be possible to just start the OSAL system again without having to go through the network joining process again?

    Note, I failed to mention that my solution is with a CC2530ZNP, so I have a host MCU running a ZAP that is controlling the ZNP soc via UART.

    My hope is that I can restart the OSAL system running on the host MCU and not restart the CC2530ZNP so that it does not have to rejoin the network.

    For example, maybe I could modify zap_app.c zapInit() function to not call zapPhyInit()?

    Jeff
  • 0 in reply to Jeff Lia
    Guru 735695 points
    I am not familiar with ZAP. I would say it is possible but you have to do and test to know it.
  • 0 in reply to Jeff Lia
    Intellectual 270 points
    Looking into this a little further, I notice that zclHA_Init() eventually results in a call to znp_afRegisterExtended() which actually sends data over the UART, as opposed to performing initialization local to the host MCU. And, there I suspect is the problem of not being able to unregister, as that data is now on the CC2530ZNP.

    I don't suppose it's a trivial task to modify the ZNP code to allow an unregister function?
  • 0 in reply to Jeff Lia
    Guru 735695 points
    It won't be trivial task but I suppose it is doable.