power-intro.html

有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等

CLASS="VARNAME"
>power_controller_cpu</TT
> is not yet provided, and if
full power management functionality is desired then the appropriate
HAL package would have to be extended first. System developers should
examine the relevant HAL documentation and sources to determine what
is actually available.</P
></LI
><LI
><P
>Some or all of the device drivers will supply their own power
controllers, as part of the device driver package. It is not required
that all device drivers provide power controllers. In some cases,
especially for devices that are integrated with the processor,
<TT
CLASS="VARNAME"
>power_controller_cpu</TT
> will take care of the
integrated devices as a side effect. In other cases the hardware may
not provide any functionality that allows power consumption to be
controlled. For any given device driver it is also possible that no
power controller exists either because it was not required when the
driver was written, or because the driver predates the availability of
power management. Again the relevant documentation and sources should
be consulted for further information.</P
></LI
><LI
><P
>There may be power controllers which are not associated directly with
any specific hardware. For example a TCP/IP stack could provide a
power controller so that it gets informed when the system has been
reactivated: by looking at the system clock it can determine for how
long the system has been switched off; using this information it can
then recover from expired dhcp leases, or even to shut down any stream
connections that may have become invalid (although arguably the stack
should have refused to go to <SPAN
CLASS="TYPE"
>off</SPAN
> mode while there were
open connections).</P
></LI
></OL
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="POWER-INTRO-OPERATION"
></A
><H2
>Basic Operation</H2
><P
>By default the Power Management package creates a thread during
initialization. It is also possible for the package to be used without
such a thread, for example in configurations which do not include a
full kernel, and this alternative is described below. When a separate
thread is used the stacksize and priority for this thread can be
controlled by configuration options
<TT
CLASS="VARNAME"
>CYGNUM_POWER_THREAD_STACKSIZE</TT
> and
<TT
CLASS="VARNAME"
>CYGNUM_POWER_THREAD_PRIORITY</TT
>. Typically the thread
will just wait on a semaphore internal to the package, and will do
nothing until some other part of the system requests a change to the
power mode.</P
><P
>At some point the policy module will decide that the system should
move into a lower-power mode, for example from active to idle. This is
achieved by calling the function <TT
CLASS="FUNCTION"
>power_set_mode</TT
>,
provided by the power management package and declared in <TT
CLASS="FILENAME"
>cyg/power/power.h</TT
>, with a single
argument, <TT
CLASS="LITERAL"
>PowerMode_Idle</TT
>. This function manipulates
some internal state and posts the semaphore, thus waking up the power
management thread. Note that the function returns before the mode
change has completed, and in fact depending on thread priorities this
return may happen before any power controller has been invoked.</P
><P
>When the power management thread wakes up it examines the internal
state to figure out what it should be doing. In this case it is
supposed to change the global power mode, so it will iterate over all
the power controllers requesting each one to switch to the
<SPAN
CLASS="TYPE"
>idle</SPAN
> mode. It is up to each power controller to handle
this request appropriately. Optionally the thread will invoke a
callback function after processing each power controller, so that
higher-level code such as the policy module can more easily keep
track of the actual state of each controller. Once the thread has
iterated through all the power controllers it will again wait on the
internal semaphore for the next request to arrive.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>At present the power management thread always runs at a single
priority, which defaults to a low priority. A possible future
enhancement would be to support two separate priorities. When
switching to a lower-powered mode the thread would run at a low
priority as before, thus allowing other threads to run and get a
chance to cancel this mode change. When switching to a higher-powered
mode the thread would run at a high priority. This could be especially
important when moving out of the <SPAN
CLASS="TYPE"
>off</SPAN
> state: for example
it would ensure that all device drivers get a chance to wake up before
ordinary application threads get to run again and possibly attempt I/O
operations.</P
></BLOCKQUOTE
></DIV
><P
>Although usually calls to <TT
CLASS="FUNCTION"
>power_set_mode</TT
> will
come from just one place in the policy module, this is not a hard
requirement. It is possible for multiple threads to call this
function, with no need for any synchronization. If the power
management thread is in the middle of performing a mode change and a
new request comes in, the thread will detect this, abort the current
operation, and start iterating through the power controllers again
with the new mode. This check happens between every power controller
invocation. Usefully this makes it possible for power controllers
themselves to manipulate power modes: a power controller is invoked to
change mode; for some reason it determines that the new mode is
inappropriate; it calls <TT
CLASS="FUNCTION"
>power_set_mode</TT
> to move
the system back to another mode; when the power controller returns
this event will be detected; the power management thread will abort
the current mode change, and start the new one.</P
><P
>In addition to changing the power mode for the system as a whole,
individual controllers can be manipulated using the function
<TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
>. For example, while the
system as a whole might be in <SPAN
CLASS="TYPE"
>active</SPAN
> mode certain devices
might be kept in <SPAN
CLASS="TYPE"
>sleep</SPAN
> mode until they are explicitly
activated. It is possible to mix concurrent calls to
<TT
CLASS="FUNCTION"
>power_set_mode</TT
> and
<TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
>, and when a power
controller is invoked it may use
<TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
> to request further
changes to its own or to another controller's mode as required.</P
><P
>There are some scenarios where the power management package should not
use its own thread. One scenario is if the configuration is
specifically for a single-threaded application such as RedBoot.
Another scenario is if the policy module already involves a separate
thread: it may make more sense if the various power management
operations are synchronous with respect to the calling thread. The use
of a separate thread inside the power management package is controlled
by the configuration option <TT
CLASS="VARNAME"
>CYGPKG_POWER_THREAD</TT
>,
which is active only if the kernel package is present and enabled by
default.</P
><P
>If no separate power management thread is used then obviously the
implementations of <TT
CLASS="FUNCTION"
>power_set_mode</TT
> and
<TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
> will be somewhat
different: instead of waking up a separate thread to do the work,
these functions will now manipulate the power controllers directly. If
the system does still involve multiple threads then only one thread
may call <TT
CLASS="FUNCTION"
>power_set_mode</TT
> or
<TT
CLASS="FUNCTION"
>power_set_controller_mode</TT
> at a time: the power
management package will not provide any synchronization, that must
happen at a higher level. However when a power controller is invoked
it can still call these functions as required.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="services-power.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="power-info.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>eCos Power Management Support</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="services-power.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Power Management Information</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>