and it supports Mgmt_Bind_req! :D very cool
Last Edited: Fri. Oct 16, 2015 - 02:30 PM
BitCloud 1.12 Out now
Author
Message
Whats that?
Mgmt_Bind_req (unicast - retrieves a remote binding table)
(ZigBee Device Profile)ZDP Management Services
- The ZDP table requests and responses
- Mgmt_Bind_req (unicast)
ps: More here
- https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=102225
- http://ms11.voip.edu.tw/~kjclark/file/Freescale-Zigbee%20Wireless%20Networking/Chapter%205%20-%20ZigBee,%20ZDO,%20and%20ZDP.pdf
The Mgmt_Bind_req is important for commissioning tools to allow them to know about existing bindings. Such tools then may visualize the bindings and make it possible to unbind them.
When I can find informations about new BitCloud 1.12 features. It's support also some new clusters ?;>
Just download it from the atmel site. In the zip file is also a "Release Notes.txt", but not all new stuff is listet there.
New clusters are also in the BitCloud/ZCL dir.
Beside that, the good thing about the ZCL is, you can define your own clusters if you need some which are not part of the official release.
wondering what the #ifdef _CERTIFICATION_ guard in some places means?
Just wondering if there will be an official code release of serial net for bitcloud 1.12 128RFA1 or if I have to beg again like last release :)
manuelp wrote:
Some code is useful or helpful only for certification process, but not for production use. In released _CERTIFICATION_ will always be undefined.
wondering what the #ifdef _CERTIFICATION_ guard in some places means?
proficnc wrote:
SerialNet have not changed a bit since last release (well, except for version number string), so no need to beg.
Just wondering if there will be an official code release of serial net for bitcloud 1.12 128RFA1 or if I have to beg again like last release :)
OK, is anyone doing any work on serialnet now? has anyone optomised it a bit to take away the bloat?
and add some features?
proficnc wrote:
No, not at the moment.
OK, is anyone doing any work on serialnet now?
oh well :(
serial net has the potential to be a very useful tool
SerialNet is great. A few minutes after we had bought A2-ZigBit modules and system is ready. All application We have in AVR Mega CPU, everything is small, compact, no problem with RF, Dual-Chip-Antenna....
Please: Continue in develop SerialNet...
LX_User wrote:
To avr@atmel.com please :)
Please: Continue in develop SerialNet...
alexru wrote:
LX_User wrote:To avr@atmel.com please :)Please: Continue in develop SerialNet...
most definitely send this to avr@atmel.comthe more requests they get to indicate people are actually using this, the more likely they will improve it.
It took a few emails, but each release they have made a version of SerialNet and tested and released it for me to use.
Alex is the most helpful engineer when it comes to BitCloud, but the decisions come from ATMEL HQ.
if it is only Alex that passes on the requests for help, then ATMEL will think there are only a few people with issues.
I am going to start a new Thread entitled SERIAL NET wish list, But I will ask that anyone that posts in it must also send the same request directly to avr@atmel.com and also cc zigbee@atmel.com
Supposedly that address may help too.
I am confused. Is this wrong web?
Is it not "ATMEL's" WEB? Who read our posts Zilog, Freescale or Microchip?
LX_User wrote:
People who make decisions rarely read forums, so targeted request is much better.
I am confused. Is this wrong web?
Is it not "ATMEL's" WEB? Who read our posts Zilog, Freescale or Microchip?
LX_User wrote:
I am confused. Is this wrong web?
Is it not "ATMEL's" WEB? Who read our posts Zilog, Freescale or Microchip?
this is a user forum that is supported by lots of users of avr's
there are many from ATMEL that read this
but the correct method to get a new feature is to send an email to support
please feel free to put any suggestions here, but understand that like all other companies, ATMEL has a correct procedure that needs to be followed before changing features on products
Quote:
Some code is useful or helpful only for certification process, but not for production use. In released _CERTIFICATION_ will always be undefined.
Good to know!
And to enable it, where would be the right place todo so?
I've also noticed that HUGE amount of documenation was added everwhere, really cool to see how things evolve :-)
manuelp wrote:
In our development source code before preparing release :) You can't enable it from user SDK without having full BitCloud source code.
And to enable it, where would be the right place todo so?
:-( thats like
Why would you need functions that require special test software and test harness to use them? And they are likely to break some normal functionality and there is no documentation for them.
To be exact I just need one thing, the Mgmt_Bind_req which is also surrounded by the _CERTIFICATION_ guard.
So that a device can retrieve the binding table of other devices (to be able to show and edit the bindings in a arbitrary non-example-network)
Or a possibility to register a user-callback to handle unsupported ZDO/ZDP requests so the application could provide extra stuff if needed.
there are two problems for me:
i) the BitCloud stack can not handle the Mgmt_Bind_req nor is it possible to handle it in the application
ii) all other 'big' stack vendors support the request,
but the Mgmt_Bind_rsp to a request send with a plain APS_Data_req would be silently discarded by BitCloud (because it will be delivered into the internal ZDO). it would in some cases be nice to have more control about the ZDO, for example to get all Device_annce notifications and not only the ones filtered by direct children. :-)
... i know rare use case but important for commissioning tools :-)
You should probably ask avr@atmel.com . But including new features increases stack footprint, so we need to balance what we include and what not. Especially for ZigBits where space is tight already.
Quote:
But including new features increases stack footprint, so we need to balance what we include and what not. Especially for ZigBits where space is tight already.
Absolutely, thats why i don't ask to add these rather used features.
Just a possibility to hook into the ZDO would be nice. Like changing the ZDO APSDE-DATA.indication on endpoint 0 to a function pointer instead of the hardcoded function, so it would be possible to build a wrapper around it. :-D
I will send this to the support maybe I got luck. :-)