[Tinyos Core WG] Meeting: 5/30

[Martin Turon]

Hi Kevin,

This idea of grouping sensors is a good one.  The main problem with the outlined approach is that it requires hard-coding those groupings in nesC.  This will limit the ultimate scalability of the approach.  Users definitely want to group their sensors.  They also are likely to want to group them in an ad hoc/configurable way.  I think TinyDB took the right approach here.  The only problem was that their method was very RAM intensive (for a mote), and was still pretty hard-coded under the hood.

Martin 

-----Original Message-----
From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU on behalf of Kevin Klues
Sent: Wed 5/30/2007 8:51 AM
To: Philip Levis
Cc: TinyOS Core WG
Subject: Re: [Tinyos Core WG] Meeting: 5/30
 
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/5d33676d/attachment.htm