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

Reply via email to