m68k-mcfxxxx.html

ecos3.0 beta 的官方文档,html格式

><A
NAME="M68K-MCFXXXX-PORT-CONTEXT"
></A
><H3
>Thread Contexts and Setjmp/Longjmp</H3
><P
>All MCFxxxx processors support interrupts and exceptions in a uniform
way. When an interrupt or exception occurs the hardware pushes the
current program counter, the status register, and an additional 16-bit
word containing information about the interrupt source, for a total of
64 bits. Hence the PCSR part of a thread context consists of two
32-bit integers, and the variant HAL provides appropriate C and
assembler macros to examine and manipulate these.
      </P
><P
>Not all MCFxxxx processors have hardware floating point, so support
for this is left to the processor HAL package. Some MCFxxxx processors
have additional hardware units such as a multiply-accumulator, but
these are not currently supported by eCos.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-DIAG"
></A
><H3
>HAL Diagnostics</H3
><P
>The various MCFxxxx processors usually have one or more UARTs based on
very similar hardware. The variant HAL package can provide HAL
diagnostic support using such a UART. There are some minor differences
such as fifo sizes, and the UARTs will be accessed at different memory
locations. These differences are handled by a small number of macros
provided by the processor and platform HAL.
      </P
><P
>The MCFxxxx variant HAL only provides HAL diagnostic support via a
UART if the processor or platform HAL does not provide an alternative
implementation. That copes with situations where the on-chip UARTs are
not actually accessible on the target board and an alternative
communication channel must be used.
      </P
><P
>If the variant HAL should implement HAL diagnostics then the processor
or platform HAL should implement the CDL interface
<CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_MCFxxxx_DIAGNOSTICS_USE_DEFAULT</CODE
>. It
should also define one or more of
<CODE
CLASS="VARNAME"
>CYGHWR_HAL_M68K_MCFxxxx_UART0</CODE
>,
<CODE
CLASS="VARNAME"
>CYGHWR_HAL_M68K_MCFxxxx_UART1</CODE
> and
<CODE
CLASS="VARNAME"
>CYGHWR_HAL_M68K_MCFxxxx_UART2</CODE
>, and ensure that any
multi-purpose GPIO pins are set correctly. The variant HAL will take
care of the rest.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-CACHE"
></A
><H3
>Cache Handling</H3
><P
>The various MCFxxxx processors all have very different caches, so
support for these is deferred to the processor HAL.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-EXCEPTIONS"
></A
><H3
>Exceptions</H3
><P
>All MCFxxxx processors support synchronous exceptions in a uniform
way, with the hardware pushing sufficient information on to the stack
to identify the nature of the exception. This means that the architectural
entry point <CODE
CLASS="FUNCTION"
>hal_m68k_exception_vsr</CODE
> can be used as
the default VSR for all exceptions, with no need for separate
trampoline functions.
      </P
><P
>The variant HAL does not provide any special support for recovering
from exceptions.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-INTERRUPTS"
></A
><H3
>Interrupts</H3
><P
>All MCFxxxx processors supports interrupts in a uniform way. When an
interrupt occurs the hardware pushes sufficient information on to the
stack to identify the interrupt. Therefore the architectural entry
point <CODE
CLASS="FUNCTION"
>hal_m68k_interrupt_vsr</CODE
> can be used as the
default VSR for all interrupts, with the variant just supplying a
small number of macros that allow the generic code to extract details of
the interrupt source. There is no need for separate trampoline
functions for every interrupt source.
      </P
><P
>On processors which have MCF5282-compatible interrupt and edge port
modules the variant HAL can provide the
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_MASK</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_UNMASK</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_SET_LEVEL</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_ACKNOWLEDGE</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_CONFIGURE</CODE
> macros. There is support
for processors with a single interrupt controller or with two separate
interrupt controllers. Otherwise these macros are left to the
processor HAL. The allocation of interrupt vectors to the various
on-chip devices is also a characteristic of the processor HAL.
<TT
CLASS="FILENAME"
>proc_intr.h</TT
> should be
consulted for appropriate definitions, for example
<CODE
CLASS="VARNAME"
>CYGNUM_HAL_ISR_UART0</CODE
>.
      </P
><P
>The mask and umask operations are straightforward: if the interrupt
controller has the <TT
CLASS="LITERAL"
>SIMR</TT
> and <TT
CLASS="LITERAL"
>CIMR</TT
>
registers those will be used; otherwise the <TT
CLASS="LITERAL"
>IRM</TT
>
registers will be updated by a read-modify-write cycle. The
acknowledge macro is only relevant for external interrupts coming in
via the edge port module and will clear the interrupt by writing to
the <TT
CLASS="LITERAL"
>EPIER</TT
> register. There is no simple way to clear
interrupts generated by the on-chip peripherals, so that is the
responsibility of the various device drivers or of application code.
The configure macro is only relevant for external interrupts and
involves manipulating the edge port module.
      </P
><P
>The <CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_SET_LEVEL</CODE
> macro is used
implicitly by higher level code such as
<CODE
CLASS="FUNCTION"
>cyg_interrupt_create</CODE
>. With MCF5282-compatible
interrupt controllers the priority level corresponds to
the <TT
CLASS="LITERAL"
>ICRxx</TT
> register. The exact format depends on the
processor. Interrupt priorities corresponding to IPL level 7 are
non-maskable. Such interrupts cannot be managed safely by the usual
eCos ISR and DSR mechanisms. Instead application code will have to
install a custom VSR and manage the entire interrupt.
      </P
><P
>Some MCF5282-compatible interrupt controllers have a major
restriction: all interrupt priorities within each controller must be
unique. If two interrupts go off at the same time and have exactly the
same priority then the controllers' behaviour is undefined. In a
typical application some of the interrupts will be handled by eCos
device drivers while others will be handled directly by application
code. Since eCos cannot know which interrupts may get used, it cannot
allocate unique priorities. Instead this has to be left to the
application developer. eCos does provide configuration options such as
<CODE
CLASS="VARNAME"
>CYGNUM_KERNEL_COUNTERS_CLOCK_ISR_PRIORITY</CODE
> and
<CODE
CLASS="VARNAME"
>CYGNUM_DEVS_SERIAL_MCFxxxx_SERIAL0_ISR_PRIORITY</CODE
> to
provide control over the eCos-managed interrupts, and provides default
values for these which are unique.
      </P
><DIV
CLASS="CAUTION"
><P
></P
><TABLE
CLASS="CAUTION"
BORDER="1"
WIDTH="100%"
><TR
><TD
ALIGN="CENTER"
><B
>Caution</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
>Non-unique interrupt priorities can lead to very confusing system
behaviour. For example on an MCF5282, if the PIT3 system clock
(interrupt 0x3a) and ethernet RX frame (interrupt 0x1b) are
accidentally given the same priority and go off at the same time, the
interrupt controller may actually issue an interrupt 0x3b, the bitwise
or of the two interrupt numbers. That interrupt belongs to the on-chip
flash module. There may not be an installed handler for that interrupt
at all, and even if there is a handler it will only manipulate the
flash hardware and not clear the system clock and ethernet interrupts.
Hence the system is likely to go into a spin, continually trying to
service the wrong interrupt. To track down such problems during
debugging it may prove useful to install a breakpoint on the
<CODE
CLASS="FUNCTION"
>hal_arch_default_isr</CODE
> function.
      </P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-CLOCK"
></A
><H3
>Clock Support</H3
><P
>On processors with an MCF5282-compatible programmable interrupt timer
module or PIT, the variant HAL can provide the
<CODE
CLASS="FUNCTION"
>HAL_CLOCK_INITIALIZE</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_CLOCK_RESET</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_CLOCK_READ</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_CLOCK_LATENCY</CODE
> macros. These macros are used
by the eCos kernel to implement the system clock and may be used for
other purposes in non-kernel configurations. When multiple timers are
available it is up to the processor or platform HAL to select which
one gets used for the system clock. It is also up to the processor or
platform HAL to provide various clock-related configuration options
such as <CODE
CLASS="VARNAME"
>CYGNUM_HAL_RTC_PERIOD</CODE
>. Those options need
to take into account the processor clock speed, which is usually a
characteristic of the platform and hence not known to the variant HAL.
      </P
><P
>When porting to a new Coldfire processor, the processor or platform
HAL should define the symbols
<CODE
CLASS="VARNAME"
>CYGNUM_HAL_INTERRUPT_RTC</CODE
>,
<CODE
CLASS="VARNAME"
>_HAL_MCFxxxx_CLOCK_PIT_BASE_</CODE
>, and
<CODE
CLASS="VARNAME"
>_HAL_MCFxxxx_CLOCK_PIT_PRE_</CODE
>. Existing ports can be
examined for more details.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-RESET"
></A
><H3
>Reset</H3
><P
>On processors with an MCF5282-compatible reset module or RST, the
variant HAL can provide the <CODE
CLASS="FUNCTION"
>HAL_PLATFORM_RESET</CODE
>
macro. That macro is typically used by the gdb stubs support inside
RedBoot to reset the hardware between debug sessions, ensuring that
each session runs in as close to pristine hardware as possible. The
macro uses the <TT
CLASS="LITERAL"
>SOFTRST</TT
> bit of the
<CODE
CLASS="VARNAME"
>RCR</CODE
> register.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-BITINDEX"
></A
><H3
>Bit Indexing</H3
><P
>By default the variant HAL will provide versions of
<CODE
CLASS="FUNCTION"
>HAL_LSBIT_INDEX</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_MSBIT_INDEX</CODE
> which are more efficient than the
default ones in the architectural HAL. The implementation uses the
<B
CLASS="COMMAND"
>ff1.l</B
> and <B
CLASS="COMMAND"
>bitrev.l</B
> instructions.
If the Coldfire processor does not support these instructions then
the processor HAL should define
<CODE
CLASS="VARNAME"
>_HAL_M68K_MCFxxxx_NO_FF1_</CODE
>.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-OTHER-HAL"
></A
><H3
>Other Issues</H3
><P
>The MCFxxxx variant HAL does not affect the implementation of data
types, stack size definitions, idle thread processing, linker scripts,
SMP support, system startup, or debug support.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-OTHER"
></A
><H3
>Other Functionality</H3
><P
>The MCFxxxx variant HAL only implements functionality defined in the
eCos HAL specification and does not export any additional functions.
      </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-m68k-mcfxxxx.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-m68k-mcf5272.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Freescale MCFxxxx Variant Support</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="hal-m68k-mcfxxxx.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Freescale MCF5272 Processor Support</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>