You can think of an interface in TinyOS as containing two types of function calls: commands and events. Whenever a component 'provides' an interface it must implement all of the commands defined within it. Whenever a component 'uses' an interface, it must implement any events that it defines.
Components 'providing' an interface can rely on the fact that any events defined by that interface will be implemented by some other component and wired together with it via a configuration. Similarly, components 'using' an interface can also rely on the fact that any commands defined by that interface will be implemented by some other component. In this way, two components can exist in isolation, complementing one another via the contract defined through the common interface that they share. The distinction comes from whether they 'provide' or 'use' that interface. For components using an interface, commands provided by other components are called using the 'call' keyword For components providing an interface, events implemented by another component are signaled vie the "signal" keyword. In most common situations, commands and events within a single interface complement one another in a split-phase manner. That is to say, one component will perform some operation by calling a command and will then wait for an event to be signaled before continuing execution. The command will be provided by some other component, who is in charge of signaling the event once the operation is complete. Since the original component 'uses' the shared interface, it will be in charge of implementing the body of the signaled event however it chooses. In this way, one can think of "calling" commands from the top down, and "signaling" events from the bottom up. In the end though, they are both really just function calls to other components. The ' call' and 'signal' keywords are there to make it clear in which direction they are moving. Kevin On Nov 15, 2007 9:18 AM, Michael Schippling <[EMAIL PROTECTED]> wrote: > Yes that makes a lost of sense, logically. It just seems odd, to me, > to have a bunch of redundant keywords cluttering up my code when the > intent is (almost?) always implicit in the usage... > > Now, if "signal" actually fired off code in a different interrupt-like > context...that would be both logical and reasonable. > > thx > MS > > > Jeongyeup Paek wrote: > > > > I see 'call' and 'signal' as a type-checking mechanism with 'noop', > > where 'command' and 'event' can be regarded as > > 'INPUT' and 'OUTPUT' tags is VHDL language. > > Type checking (and a word of memo for the programmer) > > helps you to use INPUT and OUTPUT properly. > > They tell you the 'direction' in which you should call a function. > > > > In fact, although some people say 'nesC is dialect of 'C' with > > notoriously strange add-ons such as command/event/component/modules, > > I see it more close to VHDL, with the internals written in C. > > You must wire an input pin with an output pin, and vice versa, > > for an interface between components. You must output a value on > > an output pin, and you must read a value on an input pin. > > Thus, compile-time type-checking mechanisms such as > > 'call' & 'signal' are very useful. > > > > And... 'async' is just another type-checking, > > that let's you distinguish sequences of function calls > > that came/didn't come from a hardware interrupt. > > > > This is how I understood it through couple years of playing around.. > > > > Thanks > > > > - jpaek > > > > > > Michael Schippling wrote: > >> OK, so I found > >> nesC 1.1 Language Reference Manual (2003) > >> and > >> The nesC Language:... (2003) > >> > >> but in a quick search I don't find _what_ is the meaning of "signal", > >> except that it seems to be prefixed to calling functions labeled "event". > >> Do I need to really read the whole thing to get the idea, or is there > >> some summary that explains the hierarchy and impetus behind these > >> keywords? > >> Or do I have to re-remember BNF? > >> > >> thx > >> MS > >> > >> Philip Levis wrote: > >>> > >>> On Nov 14, 2007, at 10:05 AM, Michael Schippling wrote: > >>> > >>>> I guess if I took the time to read and understand all the NESCC > >>>> design/doc, > >>>> rather than wasting it on trying to make my own projects work, I > >>>> wouldn't > >>>> be asking so many seemingly redundant questions. I expect the whole > >>>> thing > >>>> has to do with using "async" as a flag to force race-condition > >>>> evaluation, > >>>> which then blossomed into a chain of fix-the-boundary-cases keywords. > >>> > >>> Not at all. The async keyword wasn't introduced until TinyOS 1.1. > >>> > >>> Phil > >> _______________________________________________ > >> Tinyos-help mailing list > >> [email protected] > >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- ~Kevin _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
