Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Z zigbee-dongle-kw2x
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Gianmarco Garrisi
  • zigbee-dongle-kw2x
  • Wiki
  • differences nxp ti

differences nxp ti · Changes

Page history
Writing wiki authored May 11, 2017 by Gianmarco Garrisi's avatar Gianmarco Garrisi
Show whitespace changes
Inline Side-by-side
differences-nxp-ti.md
View page @ deb75386
...@@ -4,3 +4,5 @@ The first one is that lots of packets in ZStack are sent as synchronous packets ...@@ -4,3 +4,5 @@ The first one is that lots of packets in ZStack are sent as synchronous packets
To complain with the ZStack, the library contains a function called waitAndLock3WayConversation, where 3Way means the request, the synchronous response and the callback. That function uses a map to avoid that more request of the same type are sent so that the system doesn't know which request the response is for. Actually the function never checks that the conversation is performed that way, so it could be used also for the message exchange as it is done through the NXP dongle. I should have fixed all places where the library was waiting for a synchronous response over the asynchronous one but, obviously, I could have missed someone. To complain with the ZStack, the library contains a function called waitAndLock3WayConversation, where 3Way means the request, the synchronous response and the callback. That function uses a map to avoid that more request of the same type are sent so that the system doesn't know which request the response is for. Actually the function never checks that the conversation is performed that way, so it could be used also for the message exchange as it is done through the NXP dongle. I should have fixed all places where the library was waiting for a synchronous response over the asynchronous one but, obviously, I could have missed someone.
Some incoming packets (Asynchronous responses) from ZStack reports the source address in their contents where the equivalent packet from BeeStack does not. Maybe there are still some methods that expect to found this field. They should be modified to avoid run-time exceptions.
Clone repository
  • bug dongle ti
  • clusters and endpoins
  • differences nxp ti
  • Home
  • long term plan
  • setup
  • short term plan
  • start
  • state of impl