Issue #260 has been updated by Stefano Lenzi. Status changed from New to Feedback Assignee changed from Miguel Nunes to Stefano Lenzi
You are partially right. In fact, the abstraction from the ZStack was designed by means of the SimpleDriver API, which at the moment are using ZToolPacket, which are dependent to the ZStack (only the data model). The idea is to define new classes or just use parameters in the SimpleDriver API so that no ZToolPacket are exposed at the level of the SimpleDriver API: I think that we need the definition of new classes because using parameters is not enough for all the option given by ZigBee. Regarding the execution model (how packet are sent and read from the serial port), we already have an abstraction. In fact, the zigbee.cc240.datalink represent a library for handling the DataLink protocol defined by the ZStack, but we a device (i.e. XBee) uses a different execution model then the developer of the ZIC (aka SimpleDriver API) will have to create it from scratch. Of course ZIC developer can reuse and fork the code from the zigbee.cc2480.datalink bundle as the same way the can fork the XBee-Api projec ( https://code.google.com/p/xbee-api/ ) or they can start from zero Is it more clear? ---------------------------------------- Improvement #260: "CC2480 Data Link protocol library" bundle. http://zb4o.aaloa.org/redmine/issues/260#change-670 Author: Miguel Nunes Status: Feedback Priority: Low Assignee: Stefano Lenzi Category: zigbee.cc2480.datalink Target version: unplanned Has a patch: No Has license agreement signed: No Correct me if I am wrong. The CC2480 Data Link bundle decodes and encodes frames to be sent to the driver. The current implementation includes code specific to a number of devices. If one needs to implement a ZIC for an AT command based module or dongle that doesn't expose a similar interface to CC2480, one ends up "reversing" the frame to get the higher level parameters. An example would be the ZDO command to get the IEEEaddress. Alternatively, couldn't one think in decoupling the contents of the bundle and call it "ZigBee Application Layer Data Link Protocol" and remove everything related to the specific protocol and then do the following: 1 - Add constructors to completly create the ZToolPacket based objects based on "higher level" data abstractions. 2 - Add getters and setters to simplify the objects manipulation (and possibly the logging). 3 - Remove the Serial port code and add a way to assign a specific driver data link protocol that would, if required, contain the serial code. I am new to this project and things shift in my mind several times a day. Just would like to know if this is considered useful to abstract from the ZStack infrastructure. -- DO NOT ANSWER TO THIS E-MAIL ADDRESS, NO ONE WILL READ IT. PLEASE WRITE TO [email protected] ZigBee 4 OSGi - Redmine E-Mail Notificatioon You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://zb4o.aaloa.org/redmine
_______________________________________________ Dev mailing list [email protected] http://zb4osgi.aaloa.org/mailman/listinfo/dev
