MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Rssi_Demo",
        "continue": "gapcontinue||"
    },
    "query": {
        "pages": {
            "310": {
                "pageid": 310,
                "ns": 0,
                "title": "Reference, TEPs, Papers, and User Notes",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "== Reference == \n\n; <big>TinyOS Programming Manual [http://www.tinyos.net/tinyos-2.x/doc/pdf/tinyos-programming.pdf]</big>: A detailed (139 page) book on programming TinyOS 2.0.\n; <big>nesC Reference [http://nescc.sourceforge.net/papers/nesc-ref.pdf]</big>: Old reference to version 1.1.  The nesC 1.3 release includes a more up to date version (denoted 1.2) located in doc/ref.pdf.   Current nesC 1.3 tar ball is available from http://downloads.sourceforge.net/nescc/nesc-1.3.0.tar.gz?modtime=1218019072&big_mirror=0\n; <big>[[TEPs]]</big>: TinyOS Enhancement Proposals\n; <big>[http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip blip]</big>: Berkeley IP implementation for low-power networks (b6loWPAN)\n; <big>[[Source Code Documentation]]</big>: HTML documentation of TinyOS source code\n; <big>[[Platform Hardware]]</big>: layouts, chips, and other details\n; <big>[[Other]]</big>: Other documentation\n\n== Other Sites ==\n* [http://www.cse.wustl.edu/wsn/index.php?title=WU_WSN_Research_Lab Washington University @ St. Louis: WU WSN Research Lab]\n* [http://compilers.cs.ucla.edu/avrora/ Avora AVR H/W simulator]\n\n<br/>\n\n== Papers ==\n* <big>[http://www.tinyos.net/papers/nesc.pdf NESC overview]: </big> The nesC Language: A Holistic Approach to Networked Embedded Systems\n\n\n== User Contributed Notes ==\n<big>[[Cygwin User Notes]]</big>\n\n\n== Internals ==\n\n* <big>nesC implementation overview [[nesc-internals]]</big>\n<br/>\n* <big>[[Complex Arbritration Example]]</big>\n<br/>"
                    }
                ]
            },
            "14": {
                "pageid": 14,
                "ns": 0,
                "title": "Resource Arbitration and Power Management",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "=Introduction=\n\nTinyOS distinguishes between three kinds of resource abstractions: '''dedicated''', '''virtualized''', and '''shared'''. \n\nTwo fundamental questions must be asked about each type of abstraction.\n\n# How can a client gain access to the resource provided through this abstraction?\n# How can the power state of that resource be controlled?\n\nComponents offer resource sharing mechanisms and power mangement capabilites according to the goals and level of abstraction required by their clients.\n\n----\n\nAn abstraction is dedicated if it represents a resource which a subsystem needs exclusive access to at all times. In this class of resources, no sharing policy is needed since only a single component ever requires use of the resource. Resource clients simply call commands from the interfaces provided by the resource just as they would with any other TinyOS component. Resources of this type provide either an <tt>AsyncStdControl</tt>, <tt>StdControl</tt>, or <tt>SplitControl</tt> interface for controlling their power states. The definition of each of these interfaces can be found in <tt>tinyos-2.x/tos/interfaces</tt>.\n interface AsyncStdControl {\n   async command error_t start();\n   async command error_t stop();\n }\n\n interface StdControl {\n   command error_t start();\n   command error_t stop();\n }\n \n interface SplitControl {\n   command error_t start();\n   command void startDone(error_t error);\n   command error_t stop();\n   command void stopDone(error_t error);\n }\nCurrently, the power states of all dedicated resources are controlled by one of these three interfaces. They are only allowed to enter one of two logical power states (on/off), regardless of the number of physical power states provided by the hardware on top of which their resource abstraction has been built. Which of these interfaces is provided by a particular resource depends on the timing requirements for physically powering it on or off.\n\n----\n\nVirtual abstractions hide multiple clients from each other through software virtualization. Every client of a virtualized resource interacts with it as if it were a dedicated resource, with all virtualized instances being multiplexed on top of a single underlying resource. Because the virtualization is done in software, there is no upper bound on the number of clients using the abstraction, barring memory or efficiency constraints. The power states of a virtualized resource are handled automatically, and no interface is provided to the user for explicity controlling its power state. As they are built on top of shared resources, the reason their power states can be automatically controlled will become clearer after reading the following section.\n\n----\n\nDedicated abstractions are useful when a resource is always controlled by a single component. Virtualized abstractions are useful when clients are willing to pay a bit of overhead and sacrifice control in order to share a resource in a simple way. There are situations, however, when many clients need precise control of a resource. Clearly, they can't all have such control at the same time: some degree of multiplexing is needed.\n\nA motivating example of a shared resource is a bus. The bus may have multiple peripherals on it, corresponding to different subsystems. For example, on the Telos platform the flash chip (storage) and the radio (network) share a bus. The storage and network stacks need exclusive access to the bus when using it, but they also need to share it with the other subsystem. In this case, virtualization is problematic, as the radio stack needs to be able to perform a series of operations in quick succession without having to reacquire the bus in each case. Having the bus be a shared resource allows the radio stack to send a series of operations to the radio atomically, without having to buffer them all up in memory beforehand (introducing memory pressure in the process).\n\nIn TinyOS, a resource '''arbiter''' is responsible for multiplexing between the different clients of a shared resource. It determines which client has access to the resource at which time. While a client holds a resource, it has complete and unfettered control. Arbiters assume that clients are cooperative, only acquiring the resource when needed and holding on to it no longer than necessary. Clients explicitly release resources: there is no way for an arbiter to forcibly reclaim it.\n\nShared resources are essentially built on top of dedicated resources, with access to them being controlled by an arbiter component. In this way, '''power managers''' can be used to automatically control the power state of these resources through their <tt>AsyncStdControl</tt>, <tt>StdControl</tt>, or <tt>SplitControl</tt> interfaces. They communicate with the arbiter (through the use of a <tt>ResourceDefaultOwner</tt> interface), monitoring whether the resource is being used by any of its clients and powering it on/off accordingly. The figure below shows how an arbiter component and a power manager can be wired together to provide arbitration and automatic power management for a shared resource.\n\n<center>[[Image:arbiter_pm_graph.png|225px|This is a picture of how an arbiter and power manager work together]]<br /> Figure 1: Arbiters and Power Managers </center>\n\nThe arbiter component provides the <tt>Resource</tt>, <tt>ArbiterInfo</tt>, <tt>ResourceRequested</tt>, and <tt>ResourceDefaultOwner</tt> interfaces and uses the <tt>ResourceConfigure</tt> interface. The power manager doesn't provide any interfaces, but uses one of either the <tt>AsyncStdControl</tt>, <tt>StdControl</tt>, or <tt>SplitControl</tt> interfaces from the underlying resource, as well as the <tt>ResourceDefaultOwner</tt> interface provided by the arbiter. The figure below shows how these interface are then wired together with the implementation of a shared resource. Please refer to TEP 108 for more information on arbiters and TEP 115 for more information on Power Managers.\n\n<center>[[Image:shared_resource_graph.png|450px|This is a picture of how a shared resource works together with an arbiter and a power manager]]<br /> Figure 2: Shared Resource Configuration </center>\n\nFrom this figure, we see that the only interfaces exposed to a client through the shared resource abstraction are the <tt>Resource</tt> and <tt>ResourceRequested</tt> interfaces provided by the arbiter as well as any resource specific interfaces provided by the resource itself. It also uses a <tt>ResourceConfigure</tt> interface, expecting it to be implemented on a client by client basis depending on their requirements. A client requests access to a shared resource through the <tt>Resource</tt> interface and runs operations on it using whatever resource specific interfaces are provided. A client may choose to wire itself to the <tt>ResourceRequested</tt> interface if it wishes to hold onto a resource indefinitely and be informed whenever other clients request its use.\n\nThe rest of this tutorial is dedicated to teaching users how to use shared resources and show them how wiring is done between all components that make them up.\n\nSpecifically, this tutorial will teach users how to:\n\n# Wire in a shared resource for use by a client.\n# Use the <tt>Resource</tt> interface to gain access to a shared resource.\n# Change the arbitration policy used by a particular shared resource.\n# Wire up a power manager for use by a shared resource.\n\n=Working with Shared Resources=\n\nThis section shows you how to gain access to and use shared resources in TinyOS. It walks through the process of making a request through the <code>Resource</code> interface and handling the <tt>granted</tt> event that is signaled back. We will connect multiple clients to a single shared resources and see how access to each of them gets arbitrated. We also show how to hold onto a resource until another client has requested it by implementing the <tt>ResourceRequested</tt> interface.\n\nTo begin, go to the <tt>tinyos-2.x/apps/tutorials/SharedResourceDemo</tt> directory and install this application on a mote. After installing the application you should see three leds flashing in sequence.\n\nLet's take a look at the different components contained in this directory to see whats going on. Start with the top level application component: <code>SharedResourceDemoAppC</code> \n configuration SharedResourceDemoAppC{\n }\n implementation {\n   components MainC,LedsC, SharedResourceDemoC as App,\n   new TimerMilliC() as Timer0,\n   new TimerMilliC() as Timer1,\n   new TimerMilliC() as Timer2;\n   App -> MainC.Boot;\n   App.Leds -> LedsC;\n   App.Timer0 -> Timer0;\n   App.Timer1 -> Timer1;\n   App.Timer2 -> Timer2;\n   \n   components\n   new SharedResourceC() as SharedResource0,\n   new SharedResourceC() as SharedResource1, \n   new SharedResourceC() as SharedResource2;\n   App.Resource0 -> SharedResource0;\n   App.Resource1 -> SharedResource1;\n   App.Resource2 -> SharedResource2;\n   App.ResourceOperations0 -> SharedResource0;\n   App.ResourceOperations1 -> SharedResource1;\n   App.ResourceOperations2 -> SharedResource2;\n }\nOther than the instantiation and wiring of the interfaces provided by the <code>SharedResourceC</code> component, this configuration is identical to the one presented in Lesson 1 for the Blink Application.\n\nAll shared resources in TinyOS are provided through a generic component similar to the <code>SharedResourceC</code> component. A resource client simply instantiates a new instance of this component and wires to the interfaces it provides. In this application, three instances of the <code>SharedResourceC</code> component are instantiated and wired to three different clients from the <code>SharedResourceDemoC</code> component. Each instantiation provides a <tt>Resource</tt>, <tt>ResourceOperations</tt>, and <tt>ResourceRequested</tt> interface, and uses a <tt>ResourceConfgigure</tt> interface. In this example, no wiring is done to the <tt>ResourceConfigure</tt> or <tt>ResourceRequested</tt> interface as wiring to to these interfaces is optional. The <tt>ResourceOperations</tt> interface is an '''EXAMPLE''' of a resource specific interface that a resource may provide to perform operations on it. Calls to commands through this interface will only succeed if the client calling them happens to have access to the resource when they are called.\n\nLet's take a look at the <code>SharedResourceDemoC</code> to see how access is actually granted to a Resource. \n module SharedResourceDemoC {\n   uses {\n     interface Boot;  \n     interface Leds;\n     interface Timer as Timer0;\n     interface Timer as Timer1;\n     interface Timer as Timer2;\n     \n     interface Resource as Resource0;\n     interface ResourceOperations as ResourceOperations0;\n     \n     interface Resource as Resource1;\n     interface ResourceOperations as ResourceOperations1;\n     \n     interface Resource as Resource2;\n     interface ResourceOperations as ResourceOperations2;\n   }\n }\nEach pair of <code>Resource/ResourceOperations</code> interfaces reperesents a different client of the shared resource used by this application. At boot time, we put in a request for the shared resource through each of these clients in the order (0,2,1). \n event void Boot.booted() {\n   call Resource0.request();\n   call Resource2.request();\n   call Resource1.request();\n }\nEach of these requests is serviced in the order of the arbitration policy used by the shared resource. In the case of <code>SharedResourceC</code>, a Round-Robin policy is used, so these requests are serviced in the order (0,1,2). If a first-come-first-serve policy were in use, they would we be serviced in the order the were put in, i.e. (0,2,1).\n\nWhenever a client's request for a resource has been granted, the <code>Resource.granted()</code> event for that client gets signaled. In this application, the body of the granted event for each client simply performs an operation on the resource as provided through the <code>ResourceOperations</code> interface. \n event void Resource0.granted() {\n   call ResourceOperations0.operation();   \n }  \n event void Resource1.granted() {\n   call ResourceOperations1.operation();\n }  \n event void Resource2.granted() {\n   call ResourceOperations2.operation();\n } \nWhenever one of these operations completes, a <code>ResourceOperations.operationDone()</code> event is signaled. Once this event is received by each client, a timer is started to hold onto the resource for 250 (binary) ms and an LED corresponding to that client is toggled.\n <nowiki>\n #define HOLD_PERIOD 250\n \n event void ResourceOperations0.operationDone(error_t error) {\n   call Timer0.startOneShot(HOLD_PERIOD);  \n   call Leds.led0Toggle();\n }\n event void ResourceOperations1.operationDone(error_t error) {\n   call Timer1.startOneShot(HOLD_PERIOD);  \n   call Leds.led1Toggle();\n }\n event void ResourceOperations2.operationDone(error_t error) {\n   call Timer2.startOneShot(HOLD_PERIOD);  \n   call Leds.led2Toggle();\n }\n </nowiki>\nWhenever one of these timers goes off, the client that started it releases the resource and immediately puts in a request for it again. \n event void Timer0.fired() {\n   call Resource0.release();\n   call Resource0.request();\n }\n event void Timer1.fired() {\n   call Resource1.release();\n   call Resource1.request();\n }\n event void Timer2.fired() {\n   call Resource2.release();\n   call Resource2.request();\n }\nIn this way, requests are continuously put in by each client, allowing the application to continuously flash the LEDs in the order in which requests are being serviced. As stated before, the <code>SharedResourceC</code> component services these requests in a round-robin fashion. If you would like to see the requests serviced in the order they are received (and see the LEDs flash accordingly), you can open up the <code>SharedResourceP</code> component in the <tt>apps/tutorials/SharedResourceDemo</tt> directory and replace the <code>RoundRobinArbiter</code> component with the <code>FcfsArbiter</code> component.\n{|\n| '''RoundRobinArbiter'''\n| '''FcfsArbiter'''\n|-\n|\n \n configuration SharedResourceP {\n \tprovides interface Resource[uint8_t id];\n \tprovides interface ResourceRequested[uint8_t id];\n \tprovides interface ResourceOperations[uint8_t id];\n \tuses interface ResourceConfigure[uint8_t id];\n }\n implementation {\n   components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\n   ...\n   ...\n }\n|\n \n configuration SharedResourceP {\n \tprovides interface Resource[uint8_t id];\n \tprovides interface ResourceRequested[uint8_t id];\n \tprovides interface ResourceOperations[uint8_t id];\n \tuses interface ResourceConfigure[uint8_t id];\n }\n implementation {\n   components new FcfsArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\n   ...\n   ...\n }\n|}\nLooking through the rest of this component, you can see how its wiring matches the connections shown in Figure 2.\n <nowiki>\n #define UQ_SHARED_RESOURCE   \"Shared.Resource\"\n configuration SharedResourceP {\n \tprovides interface Resource[uint8_t id];\n \tprovides interface ResourceRequested[uint8_t id];\n \tprovides interface ResourceOperations[uint8_t id];\n \tuses interface ResourceConfigure[uint8_t id];\n }\n implementation {\n   components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\n   components new SplitControlPowerManagerC() as PowerManager;\n   components ResourceP;\n   components SharedResourceImplP;\n \n   ResourceOperations = SharedResourceImplP;\n   Resource = Arbiter;\n   ResourceRequested = Arbiter;\n   ResourceConfigure = Arbiter;\n   SharedResourceImplP.ArbiterInfo -> Arbiter;\n   PowerManager.ResourceDefaultOwner -> Arbiter;\n   \n   PowerManager.SplitControl -> ResourceP;\n   SharedResourceImplP.ResourceOperations -> ResourceP;\n }\n </nowiki>\nFour different components are instantiated by this configuration: \n components new RoundRobinArbiterC(UQ_SHARED_RESOURCE) as Arbiter;\n components new SplitControlPowerManagerC() as PowerManager;\n components ResourceP;\n components SharedResourceImplP;\nAs we've already seen, the <tt>RoundRobinArbiterC</tt> component is used to provide arbitration between clients using <tt>SharedResourceC</tt>. The <tt>SplitControlPowerManagerC</tt> component is used to perform automatic power management of the resource to turn it on whenever a new client requests its use and shut it down whenever it goes idle. The <tt>ResourceP</tt> component is the implementation of a dedicated resource which provides a <tt>SplitControl</tt> interface and a <tt>ResourceOperations</tt> interface. This dedicated resource is wrapped by the <tt>SharedResourceImplP</tt> component in order to provide protected shared access to it. <tt>SharedResourceImplP</tt> wraps all the commands provided by the dedicated resource, and uses the <tt>ArbiterInfo</tt> interface to keep clients from calling them without first being granted access to the resource.\n\nIf you would like to see more examples of how to use the different arbiters and power managers provided in the default TinyOS distribution, please refer to the test applications located in <tt>tinyos-2.x/apps/tests/TestArbiter</tt> and <tt>tinyos-2.x/apps/tests/TestPowerManager</tt>. This tutorial has provided enough background information on how to use these components in order for you to sift through these applications on your own.\n\n=Conclusion=\n\nThis tutorial has given an overview of how resource arbitration and mechanisms for performing power management on those resources is provided in TinyOS. It walked us through the steps necessary for:\n\n# Wiring in a shared resource for use by a client.\n# Using the <tt>Resource</tt> interface to gain access to a shared resource.\n# Changing the arbitration policy used by a particular shared resource.\n# Wrapping a dedicated resource and wiring in a power manager in order to create a shared resource.\n\nWhile the power managers presented in this tutorial are powerful components for providing power management of shared resources, they are not the only power management mechanisms provided by TinyOS. Microcontroller power management is also preformed as outlined in TEP115. Whenever the task queue empties, the lowest power state that the microcontroller is capable of dropping to is automatically calculated and then switched to. In this way, the user is not burdened with explicity controlling these power states. The cc1000 and cc2420 radio implementations also provide \"Low Power Listening\" (LPL) interfaces for controlling their duty cycles. The LPL implementation for the cc2420 can be found under <tt>tinyos-2.x/tos/chips/cc2420</tt> and the LPL implementation for the cc1000 can be found under <tt>tinyos-2.x/tos/chips/cc1000</tt>. Take a look at [[Writing Low-Power Applications| lesson 16]] to see how this interface is used.\n\n=Related Documentation=\n\n* [http://csl.stanford.edu/~pal/pubs/tinyos-programming-1-0.pdf TinyOS Programming Guide ''Sections 6.2 and 7.4'']\n* [http://www.tinyos.net/tinyos-2.x/doc/html/tep108.html TEP 108: Resource Arbitration]\n* [http://www.tinyos.net/tinyos-2.x/doc/html/tep112.html TEP 112: Microcontroller Power Management]\n* [http://www.tinyos.net/tinyos-2.x/doc/html/tep115.html TEP 115: Power Management of Non-Virtualized Devices]\n\n----\n\n<br />\n\n----\n<center>\n\n< '''[[Storage| Previous Lesson]]''' | '''[[#Introduction| Top]]''' | '''[[Concurrency| Next Lesson]] >'''\n\n</center>\n[[Category:Tutorials]]"
                    }
                ]
            }
        }
    }
}