[Tinyos-host-mote-wg] Re: Re[2]: [Tinyos-2.0wg] Aligning TEP 101 (ADC) with TEP 108 (Resource Arbitration) and 109 (Sensorboards)

[David Gay]

On 5/10/05, Jan Hauer <hauer at tkn.tu-berlin.de> wrote:
> You propose that the ADCC offers a parameterized AcquireData[Now] HIL
> interface:
> 
> configuration ADCC {
>   provides {
>     interface Init;
>     interface StdControl;
>     interface Resource[uint8_t client];
>     interface AcquireData[uint8_t port];
>     interface AcquireDataNow[uint8_t port];
>   }
> 
> I assume there is going to be something like a global enum defining
> all possible platform independent 'port's.

Actually no, I assume ports are per-platform (see mica2/hardware.h for
an example) and per-sensorboard (e.g., "basicsb" uses two ADC channels
for light and temperature).

> Problem No. 1: Each chip's ADCM would perform the mapping of a 'port'
> to the actual settings for the specific chip. These settings are,
> however, platform dependent! E.g. two platforms using the same ADC,
> e.g. telos and eyes, would map 'port' to different settings. But ADCM
> is chip dependent (located in the msp430/chips/adc12 directory) and
> has no knowledge about a certain platform. I.e. ADCM cannot perform
> the mapping from port to platform settings. To make this clear, it is
> maybe important to say that on msp430 a 'port' like CHANNEL_RSSI is
> not exhaustively defined by an ADC channel (in contrast to the current
> atmel implementation,  BTW couldn't you set a sampling rate in
> tinyos-1.x for the atmel ?), but also by e.g. reference voltage level
> or sample-hold-time.

Sampling rate: that's something that the AcquireDataBuffered
implementation might use (mind you, on the ATmega128, the sampling
rate options aren't that useful, so you probably wouldn't)

Other settings: I think some of this discussion comes down to how
useful it is to provide less-than-100%-portable higher level
abstractions. I agree with you that it is too hard to provide a
useful, 100% portable A/D abstraction, but I still think it's useful
to say that if you have an A/D, then there should be an ADCC component
with the interfaces described above. You're going to want this
component to implement the various sensors built using this A/D at the
very least; by specifying what ADCC looks like we can then provide
useful things like the example ADCChannelC component (which is
platform independent) in TinyOS.

It's also true that code using ADCC may still have to configure stuff
at the HAL level. I'm assuming that this is made possible by using the
HAL level (under the assumption that HAL and HIL port numbers are
identical, or at least have some obvious mapping). If you don't do
this configuration, you'll get some default settings for reference
voltage, etc.

To get back to the bigger picture: even if the A/D abstraction fully
specified things like reference voltage, etc, that wouldn't really
help that much I think: both the set of available channels, and the
meaning of a particular voltage for a particular sensor are going to
be platform-dependent anyway.

> Problem No. 2: Let's assume a platform independent app wires to
> ADCC.AcquireData[CHANNEL_RSSI] but the actual platform the application
> is compiled for does not provide the RSSI on an ADC pin, i.e. there is
> no CHANNEL_RSSI. The app would compile but all calls would return fail
> or errors (because there is no corresponding port). Unfortunately this
> is only detected at runtime...

Actually no -- see above. If no channel, no constant ;-)

> Some minor issues:
> - In the AcquireData interface: Wouldn't it be simpler (easier for the
> programmer) to have only one event
>    event void AcquireData.dataReady(uint16_t data, uint16_t errorInfo)
> and get rid of the AcquireData.error event instead of two different
> events for data and errors ?

We've had this discussion many times ;-) Having multiple events forces
you to actually write the code to deal with the error, and avoids
cluttering the success case with error tests. Phil L. will correct me
if I've forgotten all the arguments ;-)

There should be a 2.x style guide which contains all these rules
(along with their rationale).

> - The policy I had in mind when providing the Resource interface from
> the HAL/HIL was that a "successful call to an HAL's Resource.request()
> would reserve the ADC for the caller until he calls
> Resource.release()", but an application would not be forced to call
> Resource.request() prior to every call to getData(). If it didn't call
> Resource.request(), then getData() could fail if the ADC (component)
> was busy serving another request. But a simple call to getData() would
> succeed, if the ADC was free. This is not as strict as your proposal.

One of the problems is that 1.x-style implicit allocation doesn't mix
well with async code. Consider a HAL with an async getData command and
async dataReady event. Consider also a user of this HAL which needs to
maintain a state variable S which reflects whether it's currently got
a HAL operation in progress. The obvious code is:

  if (HAL.getData() == SUCCESS)
    S = USING_HAL;

  in HAL.dataReady:
    if (S == USING_HAL) do_something;

Problem 1: the HAL.dataReady event may happen after getData returns
but before the 'S = USING_HAL' event.

Fix 1:
  atomic
      if (HAL.getData() == SUCCESS)
        S = USING_HAL;
Issue 1: we're forced to call getData in an atomic section. Yuck
(especially if getData is a slow operation).

Problem 2: after HAL.dataReady is signaled, the lower-level component
is typically idle (you want this, because you often want the dataReady
event to call getData). If the HAL doesn't signal the dataReady event
in an atomic section, you effectively have the same bug as Problem 1
(just in the other direction).

Fix 2: change the HAL to signal the dataReady event in an atomic
section. Yuck again (even more so than before, as the HAL has little
idea what dataReady events do, and they won't all need this atomic
section).

Effectively, we've now said that all interactions across components
using 1.x-style implicit allocation happen in atomic sections, i.e.,
aren't very async ;-) (it would probably then be better to just say
that all interrupt handlers run with interrupts disabled).

I think I'll argue that this means that 1.x-style implicit allocation
is a bad idea for interfaces with async commands and events :-) If you
look at the mica2 ADCM.nc file, it incorporates fix 1, and has a
cryptic comment describing problem 2.

David

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-2.0wg