[Tinyos-devel] Re: TEP 101 - the proposal for ADC interfaces

Philip Levis pal at eecs.berkeley.edu
Tue Feb 15 11:15:17 PST 2005

On Feb 14, 2005, at 1:41 PM, Yuval Peduel wrote:

>> If on the mica (on the MSP430 as well) a reserve() is less meaningful
>> then an application programmer does not need to use it (you don't need
>> to use the commands, but only implement eventhandlers and there is
>> only one event, dataReady). If you look closely at the interfaces you
>> will see that they extend the old interfaces (ADC, ADCControl), i.e.
>> they offer you more functionality - whether you use it or not is up to
>> you.
> You seem to have missed the point. I am in no position to judge 
> whether the reserve-related methods do or do not belong in the HIL (if 
> only because I don't know enough about them). That was not the issue I 
> raised. I noted only that if they were in the HIL, then they had to be 
> well documented enough for:
> 1. An application programmer to know when and how to use them.
> 2. A platform developer to know how to implement them.
> My point was that the documentation I saw was completely inadequate 
> for either function. For example, on the application level, your 
> description says:

I think Yuval's points are well taken: the semantics of the interface 
are not clear.

>>    * Reserves the ADC for one single conversion.  If this call     * 
>> succeeds the next call to <code>getData</code> will also succeed    * 
>> and the corresponding conversion will then be started with a
>>    * minimum latency.
> This raises the following questions that I couldn't find an answer to:
> 1. Is there any reason for not calling reserve() before every call to 
> getData? After all, we all want minimum latency. And if they should be 
> called before every call to getData, why not merge them in with 
> getData?
> 2. Under what circumstances can a call to getData otherwise fail? (How 
> can I write application code not knowing what a failure means?)
> (Note that once I understand the reserve() family, I may come to some 
> conclusions about whether they belong in the HIL. :-)

I have an additional question: when reserve() is called, who reserves 
the ADC? Is it in on a per-port basis? Or on a per-client basis? I am 
uncertain on the semantics of this operation. The former is clearly 
problematic, if multiple components both use access the same port...

> Are you seriously claiming that the HPLADC interface provides access 
> to all the registers as an HPL interface in the HAA should? How do I, 
> with the current HPLADC interface keep ADC Enable on all the the time 
> so my samples take only 13 cycles rather than 25? How do I abort a 
> sample and yet leave the ADC in a good state with the current HPLADC 
> interface?
> We've had to modify the HPLADC interface in order to use the hardware 
> as Atmel suggests. In the HAA model, one should not have to modify the 
> HPL level to take full advantage of the hardware. In fact, my 
> understanding is that in the HAA model only the developer of the HAL 
> implementation should even see the HPL. Applications should all be 
> using either the HIL or the HAL.

Yes. I think, in your example, the sorts of things you have had to do 
would be through the HAL, as they need to consider hardware specific 
behavior. The requirements you encountered should definitely be 
considered in the AVR HAL design.

> You haven't provided documentation on just what the HIL and HAL 
> interfaces require for binding so I can't comment on this.

 From what I can tell, MSP430ADCSingle has a bind command, which looks 
like it configures the ADC port with MSP specific parameters. It makes 
sense to me that ADC configuration be part of the HAL and hidden in the 

> Because, as TEP-2 says:
>> For optimal integration with the rest of the architecture, each /HPL/ 
>> component SHOULD have:
>>     * commands for initialization, starting, and stopping of the
>>       hardware module that are necessary for effective power
>>       management policy
>>     * "get" and "set" commands for the register(s) that control the
>>       operation of the hardware
>>     * separate commands with descriptive names for the most frequently
>>       used flag-setting/testing operations
>>     * commands for enabling and disabling of the interrupts generated
>>       by the hardware module
>>     * service routines for the interrupts that are generated by the
>>       hardware module
> The current HPLADC interface doesn't come close to meeting this. If it 
> did, then this wouldn't be an issue. (Though I might have to write my 
> own HAL implementation.)

Good point.



"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot,  'Little Gidding'

More information about the Tinyos-devel mailing list