[Tinyos Core WG] Meeting: 5/30
Martin Turon
mturon at xbow.com
Thu May 31 09:23:06 PDT 2007
Oh, I didn't realize your system allowed this level of granularity. If you can truly build a runtime query system with this, that's great!
I don't think I fully understand how the GroupedSensors interface and parameterized pieces overlap yet. What functionality is the GroupedSensors interface providing if the individual sensors themselves are parameterized? Is there someway to pass the list of sensor_ids to GroupedRead?
Martin
-----Original Message-----
From: Kevin Klues [mailto:klueska at gmail.com]
Sent: Thu 5/31/2007 9:20 AM
To: Martin Turon
Cc: Philip Levis; TinyOS Core WG
Subject: Re: [Tinyos Core WG] Meeting: 5/30
If you wanted something like TinyDB where you had the flexibility to choose
which sensors you wanted to access at runtime, then you would have to
include them all in your application at compile time, and allow them to be
configured as well as powered up and down based on the queries supplied by a
user at runtime.
Using my approach, this would mean instantiating the GroupedSensors
component to include all the sensors available on a platform and adding in
interfaces that allow you to specify which ones should actually be grouped
together for the next query. This could be done through parameterized
interfaces, where each sensor is given a unique ID, and that id is
associated with both its Resource and its Read/ReadStream interfaces.
Specifying a query for a group of sensors (2,5,6) would mean telling the
GroupedSensors component to sample sensors 2,5,6 by calling the
parameterized instances of Resource.request() and Sensor.read() on those
sensors only.
Kevin
On 5/30/07, Martin Turon <mturon at xbow.com> wrote:
>
>
> 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
>
>
--
~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070531/73540cf5/attachment.htm
More information about the Tinyos-2.0wg
mailing list