[Tinyos Core WG] Meeting: 5/30

[Kevin Klues]

I was thinking a bit about the Read/ReadStream problem and was wondering
what everyone thought about creating some sort of generic component that
allowed multiple sensors to be grouped together in such a way that it would
be guaranteed that they were sampled simultaneously.  A user would still
need to wire in the HAL implementations of their sensors (in order to get
access to their Resource interfaces), but wouldn't have to mess with writing
the code that handled the arbitration:

generic configuration GroupedSensorsC(typedef val_t, uint8_t numSensors) {
   provides {
      interface ReadRef<val_t> as GroupedRead;
      interface ReadStreamRef<val_t> GroupedReadStream;
   }
   uses {
      interface Resource as SensorResources[uint8_t id];
      interface Read<val_t> as SensorReads[uint8_t id];
      interface ReadStream<val_t> as SensorReadStreams[uint8_t id];
   }
implementation {
   components new GroupedSensorsP(val_t, numSensors);
}

A struct would need to be created which held all of the sensor values that
get sampled simultaneously.  This struct will be passed to calls of
GroupedRead.read(val_t* sensorValues).

A call to GroupedRead.read( sensorValues )  (or GroupedReadStream.read(
sensorValues )) in GroupedSensorsP would then cycle through "numSensors"
requests in a for loop for all connected Resource interfaces, waiting for
them all to be granted before issuing a read() command on all of them
concurrently.  Only once all readDone() events came back would a
GroupedRead.readDone() event be signalled with the values placed into the
location pointed to by the "sensorValues" variable accordingly.

A user would only need to create a component that used GroupedSensorsC and
wire in the chip specific sensors (as if they were using their HALs), but
not have to worry about rewriting the code that handles all the arbitration,
etc.

#define UQ_ACCEL_XY "AccelerometerXY.GroupedSensors"
typedef struct accel_xy {
  uint16_t x;
  uint16_t y;
} accel_xy_t;
configuration AccelXandY {
  provides interface ReadRef<uint16_t>;
  provides interface ReadStreamRef<uint16_t>;
}
implementation {
  components new GroupedSensorsC(uint16_t, 2);
  components SomeAccelerometerHalC;

  enum {
    ACCEL_X = unique(UQ_ACCEL_XY),
    ACCEL_Y = unique(UQ_ACCEL_XY).
  }

  GroupedSensorsC.SensorResources[ACCEL_X)] ->
SomeAccelerometerHalC.ResourceX;
  GroupedSensorsC.SensorResources[ACCEL_Y] ->
SomeAccelerometerHalC.ResourceY;

  GroupedSensorsC.SensorReads[ACCEL_X] -> SomeAccelerometerHalC.ReadX;
  GroupedSensorsC.SensorReads[ACCEL_Y] -> SomeAccelerometerHalC.ReadY;

  GroupedSensorsC.SensorReadStreams[ACCEL_X] ->
SomeAccelerometerHalC.ReadStreamX;
  GroupedSensorsC.SensorReadStreams[ACCEL_Y] ->
SomeAccelerometerHalC.ReadStreamY;
}

Problems I see with this approach...
(1) Different Read / ReadStream interfaces have different val_t parameters.
Only sensors with the same val_t would be able to be grouped together
(2) I'm not sure how well the current design will allow for something like
this to be easily implemented.....
(3) The whole thing with setting up a struct and having the generic
component fill it in in the proper order seems a bit messy

Kevin


On 5/29/07, Philip Levis <pal at cs.stanford.edu> wrote:
>
> Wednesday, May 30, 2007, 09:30 AM US Pacific Time
> Bridge: 3, Passcode: 7486633
>
> US: 1-916-356-2663 or 1-888-875-9370 (non-Intel)
> UK: +44 1793 402663
> Denmark: +45 4527 5090
>
> Agenda:
>
> Fred Jiang and John Regehr
>
> TEP Progress (1, 102, 109, 114, 117, etc.)
>    - Shepherding
>    - Steering Committee/Alliance WG
>
> Power management of sensors: ReadStream vs. Read vs. ReadNow
>
> Communication
>   - AM group
>   - Packet metadata (ToA, RSSI)
>   - TEP 125: Frame format (attached)
>   - 2.1?
>
> Phil
>
>
> _______________________________________________
> 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
>
>


-- 
~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070530/78bec57a/attachment.htm