Hello Dmitry, Just answering that last one (I took note of the other ones).
[...] >> It makes it extra easy to match a request to its response and to >> compute the >> response message in the case you don't even support the command >> (provided >> that all your command have the same "header", such as "s2" and >> <status>, you >> can indicate a failure). Perhaps that not needed if you report >> errors in a >> different manner. > > I know why both V1 and V2 have that | 0x80 ;) > > I was asking especially about received-block event. V2 has that 0x80 > inverted > in received-block (if compared to V1). OK, I get it now. I swapped the logic a little here unintentionally when I was renumbering the various commands. However, on a second though I think the inversion is preferable here because it respects the property that the response cmdId is the "|0x80"'ed of the request cmdID. Given that the version 2 does not intend to be backward compatible, that does not seem to raise any issues. Does that seems fair to you? Do you see any problem with this approach? I always though the serial protocol V1 was designed for the Econotag in mind, thanks for showing me wrong. :) Regards, Tony ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
