Defining the sample structure

[Willem Ferguson]

Here follows another iteration of a proposal for the sample structure. 
There is quite a bit of to-and-fro about this, but it is important enough.

typedef struct        //unchanged
{
     int mm;
} depth_t;

typedef struct        // unchanged
{
     int seconds;
} duration_t;

typedef struct        // new definition; type uint16_t
{
     uint16_t seconds;
} shortduration_t;

typedef struct        // type changed to uint16_t
{
     uint16_t mbar;
} pressure_t;

typedef struct        // type changed to uint16_t
{
     uint16_t mkelvin;
} temperature_t;

struct __attribute__((__packed__)) {    //new structure definition
     uint16_t setpoint;
     uint16_t o2sensor[3];
} o2ccr;

struct sample {                 //TYPE        UNITS RANGE          BYTES
     duration_t time;            //int         seconds (0-very long)     4
     shortduration_t stoptime;   //uint16_t    seconds (0-18h)           2
     shortduration_t ndl;        //uint16_t    seconds (0-18h)           2
     depth_t depth;              //int         mm (0-very deep)       4
     depth_t stopdepth;          //int         mm (0-very deep)       4
     temperature_t temperature;  //unit16_t    mdegr K (0-65 degr C)       2
     pressure_t cylinderpressure;//uint16_t    mbar (0-65 bar)          2
     pressure_t sensor;          //uint16_t    mbar (0-65 bar)          2
     pressure_t pdiluent;        //uint16_t    mbar (0-65 bar)          2
     pressure_t po2;             //uint16_t    mbar (0-65 bar)          2
     uint8_t cns;                //uint8_t     % (0-255%)            1
     unint8_t heartbeat;         //uint8_t    beats/s (0-256)            1
     o2ccr o2data;               //o2ccr       mbar (0-65 bar)          8
     int bearing;                //int        degrees -largeto+large       4
     bool in_deco;               //bool        y/n --               1
};
//                                Total size    41 bytes
//                                (+3 bytes for filling to 44?)
//                                ( = next word boundary?)

Because I am not sure how the tabbing will show on other email clients, 
I attach a PDF copy of the code fragment.

Again, I have some questions relating to efficiency of variable allocation.

1) The variables are arranged so that they are in increments of a word 
(4 bytes). What assurance is there that the compiler will actually 
allocate the data efficiently and that it will not use a whole word for 
a uint16 or other small units?

2) If it does allocate the space efficiently, is there a need for the 
structure o2ccr? Could one not insert four consecutive uint16 variables 
into the main sample structure?

3) If efficient variable allocation cannot be assured, is there a case 
to be made for packing the whole sample structure?

4) Please look at the typedefs, the ranges for the variables as well as 
other practical issues. Do they appear to be realistic at all?

Kind regards,
willem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample_structure_23Apr.pdf
Type: application/x-pdf
Size: 17146 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140423/d95b0b55/attachment-0001.bin>