[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Resource handles

[David Gay]

On 10/21/05, Joe Polastre <joe at polastre.com> wrote:
> > >   void doSomething() {
> > >     if( call Resource.immediateRequest() )
> > >       doSomethingGranted();
> > >     else
> > >       call Resource.request();
> > >   }
> > As far as I can tell, this issue has nothing to do with the rh
> > (resource handle) thing? You want an async request that immediately
> > signals granted if the resource is available? (your Urgent interface
> > proposal from the 1st mail? it would help to be more explicit...)
>
> No.  If you look at the code, if
>
> call Resource.immediateRequest() == SUCCESS
>
> then immediately the resource is used in the function
> "doSomethingGranted()".  Signalling an event is not only tedious, but
> causes a task to be posted and execution delayed (if no task is
> posted, the execution path looks screwy)

I think you missed my point (we're all lacking in clear explanations
it seems) - if Cory wants to simplify the above code it has to have a
separate request command and granted event (otherwise what happens in
the "it's busy now case"?). If you additionally want that to avoid
posting a task, then the code in request has to signal the event
immediately, leading to a deeper call stack and potential recursion.
If that's not what Cory wants, then I'm confused...

> Cory is also proposing nesting of resources using a resource handle.
> That is a separate discussion.  In that case, when a resource is
> granted, you are given a resource handle to use for subsequent
> accesses to the resource.

> Basically, we tried to get I2C, SPI, and UART on USART0 of the MSP430
> to work concurrently in both TinyOS 1.x (haha, yeah right, like that
> will work), and with the TinyOS 2.x TEP proposal.  I believe Cory is
> simply relaying why neither of those proposals actually allowed I2C,
> SPI, and UART requests to be submitted and run efficiently on a single
> underlying piece of hardware, especially in the face of time critical
> operations like SFD timestamping.  Of course, Cory will comment more
> on the intricacies if you want, but I think the initial email spelled
> out a lot of the concerns.

It would be easier to comment if we saw that code... And had some
discussion on the problems encountered.

David

_______________________________________________
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