• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 55 subscribers
  • Views 281 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Hexadecimal in Z-Stack 3.0

Jack Loop
Guru 17870 points
Other Parts Discussed in Thread: Z-STACK

Hi,

I just wanted to know why hexadecimals are used in the Z-Stack 3.0 such as the line, "#define UI_KEY_AUTO_PRESSED 0xFFFF" which is equivalent to 65,535 in decimal. Besides easiness (like typing), is there there any other reasons as to why hex is used over the decimal value? Also in the Z-Stack 3.0, why would such a high value need to be used in the line above instead of something low like 100 (decimal)?

  • 0
    TI__Expert 8950 points
    Hi Jack,

    Using hex like this is not unique to Z-Stack, it is common coding practice when using an embedded platform. We do similar things in many of our stacks. Among other things, using hex over decimal is particularly useful for two things:

    1. Condensing binary data into hex, e.g.:
    0x(F)(0)(A)(1) = 0b(1111)(0000)(1010)(0001)

    2. Performing bitwise operations, which is done frequently on an embedded system, e.g.:
    0x1 | 0x2 | 0x4 = 0b0001 | 0b0010 | 0b0100 = 0b0111 = 0x7

    As for why this particular variable is defined as 0xFFFF, it is used in a context where the variable current_keys is a uint16 that represents the current state of the keys. The lower byte of this uint16 is a bitmask for keys pressed, and the upper byte is a bitmask for keys released. In some cases a key is held down and we want to pass unique data into this function for this case, and since this function takes a uint16 we decided to pass in this value. It could have just as easily been a different uint16 value that does not conflict with either "keys pressed" bitmask, but using 0xFFFF doesn't take any more space than using, say, 0xFEFD.