hal-interrupt-handling.html

ecos 文档

> with the replacement supplied in
<TT
CLASS="PARAMETER"
><I
>vsr</I
></TT
>. The old VSR is returned in the location
pointed to by <TT
CLASS="PARAMETER"
><I
>pvsr</I
></TT
>.</P
><P
><TT
CLASS="FUNCTION"
>HAL_VSR_GET()</TT
> assigns
a copy of the VSR to the location pointed to by <TT
CLASS="PARAMETER"
><I
>pvsr</I
></TT
>.</P
><P
><TT
CLASS="FUNCTION"
>HAL_VSR_SET_TO_ECOS_HANDLER()</TT
> ensures that the
VSR for a specific exception is pointing at the eCos exception VSR and
not one for RedBoot or some other ROM monitor. The default when
running under RedBoot is for exceptions to be handled by RedBoot and
passed to GDB. This macro diverts the exception to eCos so that it may
be handled by application code. The arguments are the VSR vector to be
replaces, and a location in which to store the old VSR pointer, so
that it may be replaced at a later point.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN7982">Interrupt controller management</H2
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>HAL_INTERRUPT_MASK( vector )
HAL_INTERRUPT_UNMASK( vector )
HAL_INTERRUPT_ACKNOWLEDGE( vector )
HAL_INTERRUPT_CONFIGURE( vector, level, up )
HAL_INTERRUPT_SET_LEVEL( vector, level )</PRE
></TD
></TR
></TABLE
><P
>These macros exert control over any prioritized interrupt
controller that is present. If no priority controller exists, then
these macros should be empty.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>  These macros may not be reentrant, so care should be taken to
  prevent them being called while interrupts are enabled. This means
  that they can be safely used in initialization code before
  interrupts are enabled, and in ISRs. In DSRs, ASRs and thread code,
  however, interrupts must be disabled before these macros are
  called. Here is an example for use in a DSR where the interrupt
  source is unmasked after data processing:
  </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
> ...
 HAL_DISABLE_INTERRUPTS(old);
 HAL_INTERRUPT_UNMASK(CYGNUM_HAL_INTERRUPT_ETH);
 HAL_RESTORE_INTERRUPTS(old);
 ...</PRE
></TD
></TR
></TABLE
></BLOCKQUOTE
></DIV
><P
><TT
CLASS="FUNCTION"
>HAL_INTERRUPT_MASK()</TT
> causes the interrupt
associated with the given vector to be blocked.</P
><P
><TT
CLASS="FUNCTION"
>HAL_INTERRUPT_UNMASK()</TT
> causes the interrupt
associated with the given vector to be unblocked.</P
><P
><TT
CLASS="FUNCTION"
>HAL_INTERRUPT_ACKNOWLEDGE()</TT
> acknowledges the
current interrupt from the given vector. This is usually executed from
the ISR for this vector when it is prepared to allow further
interrupts.  Most interrupt controllers need some form of acknowledge
action before the next interrupt is allowed through. Executing this
macro may cause another interrupt to be delivered. Whether this
interrupts the current code depends on the state of the CPU interrupt
mask.</P
><P
><TT
CLASS="FUNCTION"
>HAL_INTERRUPT_CONFIGURE()</TT
> provides
control over how an interrupt signal is detected. The arguments
are:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>vector</DT
><DD
><P
>The interrupt vector to be configured.</P
></DD
><DT
>level</DT
><DD
><P
>      Set to <TT
CLASS="VARNAME"
>true</TT
> if the interrupt is detected by
      level, and <TT
CLASS="VARNAME"
>false</TT
> if it is edge triggered.
      </P
></DD
><DT
>up</DT
><DD
><P
>      If the interrupt is set to level detect, then if this is
      <TT
CLASS="VARNAME"
>true</TT
> it is detected by a high signal level,
      and if <TT
CLASS="VARNAME"
>false</TT
> by a low signal level. If the
      interrupt is set to edge triggered, then if this is
      <TT
CLASS="VARNAME"
>true</TT
> it is triggered by a rising edge and if
      <TT
CLASS="VARNAME"
>false</TT
> by a falling edge.
      </P
></DD
></DL
></DIV
><P
><TT
CLASS="FUNCTION"
>HAL_INTERRUPT_SET_LEVEL()</TT
> provides control over
the hardware priority of the interrupt. The arguments are:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>vector</DT
><DD
><P
>The interrupt whose level is to be set.</P
></DD
><DT
>level</DT
><DD
><P
>      The priority level to which the interrupt is to set. In some
      architectures the masking of an interrupt is achieved by
      changing its priority level. Hence this function,
      <TT
CLASS="FUNCTION"
>HAL_INTERRUPT_MASK()</TT
> and
      <TT
CLASS="FUNCTION"
>HAL_INTERRUPT_UNMASK()</TT
> may interfere with
      each other.
      </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN8029">Clock control</H2
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>HAL_CLOCK_INITIALIZE( period )
HAL_CLOCK_RESET( vector, period )
HAL_CLOCK_READ( pvalue )</PRE
></TD
></TR
></TABLE
><P
>These macros provide control over a clock or timer device that may be
used by the kernel to provide time-out, delay and scheduling
services. The clock is assumed to be implemented by some form of
counter that is incremented or decremented by some external source and
which raises an interrupt when it reaches a predetermined value.</P
><P
><TT
CLASS="FUNCTION"
>HAL_CLOCK_INITIALIZE()</TT
> initializes the timer
device to interrupt at the given period. The period is essentially the
value used to initialize the timer counter and must be calculated from
the timer frequency and the desired interrupt rate. The timer device
should generate an interrupt every <TT
CLASS="VARNAME"
>period</TT
> cycles.</P
><P
><TT
CLASS="FUNCTION"
>HAL_CLOCK_RESET()</TT
> re-initializes the timer to
provoke the next interrupt. This macro is only really necessary when
the timer device needs to be reset in some way after each interrupt.</P
><P
><TT
CLASS="FUNCTION"
>HAL_CLOCK_READ()</TT
> reads the current value of the
timer counter and puts the value in the location pointed to by
<TT
CLASS="PARAMETER"
><I
>pvalue</I
></TT
>. The value stored will always be the
number of timer cycles since the last interrupt, and hence ranges
between zero and the initial period value. If this is a count-down
cyclic timer, some arithmetic may be necessary to generate this value.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN8041">Microsecond Delay</H2
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>HAL_DELAY_US(us)</PRE
></TD
></TR
></TABLE
><P
>This is an optional definition. If defined the macro implements a busy
loop delay for the given number of microseconds. This is usually
implemented by waiting for the required number of hardware timer ticks
to pass. </P
><P
>This operation should normally be used when a very short delay is
needed when controlling hardware, programming FLASH devices and similar
situations where a wait/timeout loop would otherwise be used. Since it
may disable interrupts, and is implemented by busy waiting, it should
not be used in code that is sensitive to interrupt or context switch
latencies.</P
></DIV
></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="hal-architecture-characterization.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="hal-input-and-output.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Architecture Characterization</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="hal-interfaces.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>HAL I/O</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>