[Tinyos Core WG] Meeting: 5/30
Jan Hauer
jan.hauer at gmail.com
Thu May 31 10:54:58 PDT 2007
> 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);
> }
Does GroupedSensorsC represent a predefined set of sensors ? Where is
the configuration data stored (I assume within GroupedSensorsP) and
would you need a different component for another (sub)set of sensors ?
> a group of sensors (2,5,6) would mean telling the GroupedSensors component to
> sample sensors 2,5,6
This looks platform-dependent - what is "sensor 2" on eyesIFX, what on
telos ? How can an app using "sensors (2,5,6)" be portable ?
> If I remember correctly, the ADC doesn't actually use one of the standard
> Arbiters at the moment (or is this just the ReferenceVoltage component).
Like most other HW/driver implementations the ADC code is
platform-specific - currently both msp430 and atmega use the
"SimpleRoundRobinArbiterC" on the HAL. TEP 101 used to include a
sentence that it SHOULD be "RoundRobinArbiter", but that requirement
was dropped.
> I wonder if there might be a way to implement an ADC specific arbiter that
> does what you suggest, rather than reimplement the entire ADC itself.
I don't understand why you want to reimplement "the entire ADC" just
to provide a platform-independent way for sampling multiple sensors
"at the same time". If we really want this functionality to be
provided in a platform-independent way (I don't think we should), why
don't we specify the platform-independent interfaces, call them HIL
and leave the rest to the platform implementers ? Of course, library
components (like ArbitratedReadC.nc or GroupedSensorsP (?)) can be
helpful, but they should never be a requirement. For example, on the
msp430 ADC the HAL client "Msp430Adc12ClientC" provides the
"Msp430Adc12MultiChannel" interface which does exactly what we are
talking about. A simple wrapper could map this to a "HIL" without the
need for a GroupedSensorsP that "cycle(s) 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."
I think we are pushing this too much - if you have strong requirements
w.r.t. performance then you should simply use the HAL.
Jan
On 5/31/07, Martin Turon <mturon at xbow.com> wrote:
>
>
>
>
> Sounds good.
>
> > > (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
>
> One idea for the resulting packet format:
>
> Add extra generic parameters to GroupedSensorsC:
> <uint8_t max_reading_size>
>
> Then, GroupedRead returns a Sensor header followed by an array of readings
> interpreted either as a buffer of byte[], or an array of {uint8_t sensor_id;
> uint16_t sensor_reading}:
>
> [Header]
> 0x0000 Version (uniquely identify this packet as GroupedSensor version
> 2.x)
> 0x0001 Flags / Details (sensor_id = 1 byte, readings = 2 bytes, ...)
>
> [Payload]
> Address Value
> 0x0000 sensor_1_id
> 0x0001 sensor_1_value_H
> 0x0002 sensor_1_value_L
> 0x0003 sensor_2_id
> 0x0004 sensor_2_value_H
> 0x0005 sensor_2_value_L
> 0x0006 sensor_3_id
> 0x0007 sensor_3_value_H
> 0x0008 sensor_3_value_L
> ...
>
> It is really handy to be able to parse the packet format without a ton of a
> priori knowledge about the nodes on the network. If there are too many
> sensors, add transport layer fragmentation/defragmentation of larger data
> objects.
>
> Martin
>
>
> -----Original Message-----
> From: Kevin Klues [mailto:klueska at gmail.com]
> Sent: Thu 5/31/2007 9:29 AM
> To: Martin Turon
> Cc: Philip Levis; TinyOS Core WG
> Subject: Re: [Tinyos Core WG] Meeting: 5/30
>
> So its not really a system yet -- its still just a discussion at this
> point. Something similar to what you suggest is what I hinted at in the
> last email though. Specifically, a way to pass the list of sensor_ids to
> GroupedRead is definitely something that would be needed.
>
> Kevin
>
> On 5/31/07, Martin Turon <mturon at xbow.com> wrote:
> >
> >
> > 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 <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
> >
> >
>
>
> --
> ~Kevin
>
>
>
>
> _______________________________________________
> 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
>
More information about the Tinyos-2.0wg
mailing list