[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] recommendation for coding convention on state variables

[David Gay]

On 10/12/05, Philip Levis <pal at cs.stanford.edu> wrote:
> I've recently been using JTAG a lot, and it's amazingly useful for
> debugging code on the node (shocking, I know). There's something that
> you can do with your code to make this much easier, specifically for
> inspecting state variables.
>
> The standard TinyOS component does something like this:
>
> enum {
>   STATE_ONE,
>   STATE_TWO,
>   STATE_THREE,
> };
>
> uint8_t myState;
>
> In a debugger, when you inspect myState you'll see 0, 1, or 2. In this
> case, you can figure out what state that is pretty easily, but in
> something like a radio stack where there are 8 different states,
> counting the enums (or looking them up when explicitly assigned) is a
> pain. Instead, if you do this:
>
> typedef enum {
>   STATE_ONE,
>   STATE_TWO,
>   STATE_THREE
> } my_state_t;
>
> my_state_t myState;
>
> then when you inspect myState the debugger will tell you STATE_ONE or
> STATE_TWO or STATE_THREE.
>
> Which is kind of nice.

Btw, the annoying workaround to find the values is
  p (int)STATE_TWO

> I'd therefore recommend doing state variables in this way. There's no
> cost, etc.

There is, alas, a cost. enum's are stored (as per the C spec) as ints,
so take two bytes.

Three  fixes:
- use uint8_t, like we've been doing...
- use __attribute__((packed)). Our code now becomes gcc-specific (ok,
we could use a macro and #ifdef to avoid that, but see next solution
too)
- use -fshort-enums when compiling. The RAM savings are now
gcc-specific. There's also a potential problem when linking with
libraries using enums inside structs, but I doubt we have any of
those.

David

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg