📄 m68k-mcfxxxx.html
字号:
<!-- Copyright (C) 2009 Free Software Foundation, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/). -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission is obtained from the copyright holder. -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>MCFxxxx ColdFire Processors</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="eCos Reference Manual"
HREF="ecos-ref.html"><LINK
REL="UP"
TITLE="Freescale MCFxxxx Variant Support"
HREF="hal-m68k-mcfxxxx.html"><LINK
REL="PREVIOUS"
TITLE="Freescale MCFxxxx Variant Support"
HREF="hal-m68k-mcfxxxx.html"><LINK
REL="NEXT"
TITLE="Freescale MCF5272 Processor Support"
HREF="hal-m68k-mcf5272.html"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>eCos Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="hal-m68k-mcfxxxx.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="hal-m68k-mcf5272.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="M68K-MCFXXXX"
></A
>MCFxxxx ColdFire Processors</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN19142"
></A
><H2
>Name</H2
><CODE
CLASS="VARNAME"
>CYGPKG_HAL_M68K_MCFxxxx</CODE
> -- eCos Support for Freescale MCFxxxx Processors</DIV
><DIV
CLASS="REFSECT1"
><A
NAME="M68K-MCFXXXX-DESCRIPTION"
></A
><H2
>Description</H2
><P
>The Freescale ColdFire family is a range of processors including the
MCF5206 and the MCF5282. From a programmer's perspective these
processors all share basically the same processor core, albeit with
minor differences in the instruction set. They differ in areas like
performance, on-chip peripherals and caches. Even when it comes to
peripherals there is a lot of commonality. For example many but not
all Coldfire processors use the same basic interrupt controller(s) as
the MCF5282. Similarly the on-chip UARTs tend to use the same basic
design although there are variations in the number of UARTs, the fifo
sizes, and in certain details.
</P
><P
> The MCFxxxx variant HAL package
<CODE
CLASS="VARNAME"
>CYGPKG_HAL_M68K_MCFxxxx</CODE
> provides support for
various features that are common to many but not all Coldfire
processors. This includes HAL diagnostics via an on-chip UART and
interrupt controller management for those processors which have
MCF5282-compatible controllers. The variant HAL complements the M68K
architectural HAL package. An eCos configuration should also include a
processor-specific HAL package such as
<CODE
CLASS="VARNAME"
>CYGPKG_HAL_M68K_MCF5272</CODE
> to support the
chip-specific peripherals and cache details, and a platform HAL
package such as <CODE
CLASS="VARNAME"
>CYGPKG_HAL_M68K_M5272C3</CODE
> to support
board-level details like external memory chips. The processor or
platform HAL can override the functionality provided by the variant
HAL.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="M68K-MCFXXXX-CONFIG"
></A
><H2
>Configuration</H2
><P
>The MCFxxxx variant HAL package should be loaded automatically when
eCos is configured for appropriate target hardware. It should never be
necessary to load this package explicitly. Unloading the package
should only happen as a side effect of switching target hardware.
</P
><P
>On most ColdFire platforms the variant HAL will provide the HAL
diagnostics support via one of the UARTs. Some platforms may provide
their own HAL diagnostics facility, for example output via an LCD. The
variant HAL diagnostics support is active if the processor or platform
implements the
<CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_MCFxxxx_DIAGNOSTICS_USE_DEFAULT</CODE
>
interface. It is also active only in configurations which do not rely
on an underlying rom monitor such as RedBoot:
if <CODE
CLASS="VARNAME"
>CYGSEM_HAL_USE_ROM_MONITOR</CODE
> is enabled then the
default diagnostics channel will automatically be inherited from
RedBoot. The variant HAL then provides a number of configuration
options related to diagnostics:
</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><CODE
CLASS="VARNAME"
>CYGHWR_HAL_M68K_MCFxxxx_DIAGNOSTICS_PORT</CODE
></DT
><DD
><P
>This selects the destination for HAL diagnostics. The number of UARTs
available depends on the processor, and on any given board some of the
UARTs may not be connected. Hence the variant HAL looks for
configuration options
<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
> to see which on-chip
UARTs are actually available on the processor and target hardware, and
uses this information to let the user select a UART.
</P
><P
>When a UART is in use as the HAL diagnostics channel, that UART
should not be used for any other purpose. In particular application
code should avoid using it for I/O via the serial driver.
</P
></DD
><DT
><CODE
CLASS="VARNAME"
>CYGNUM_HAL_M68K_MCFxxxx_DIAGNOSTICS_BAUD</CODE
></DT
><DD
><P
>When a UART is selected for HAL diagnostics this option specifies the
default baud rate. The most common setting is 38400. That provides a
compromise between performance and reliability, especially in
electrically noisy environments such as an industrial environment or a
test farm. Some platforms may define
<CODE
CLASS="VARNAME"
>CYGNUM_HAL_M68K_MCFxxxx_DIAGNOSTICS_DEFAULT_BAUD</CODE
>
to handle scenarios where another default baud rate is preferable,
typically for compatibility with existing software.
</P
></DD
><DT
><CODE
CLASS="VARNAME"
>CYGNUM_HAL_M68K_MCFxxxx_DIAGNOSTICS_ISRPRI</CODE
></DT
><DD
><P
>Usually the HAL diagnostics channel is driven in polled mode but in
some scenarios interrupts are required. For example, when debugging an
application over a serial line on top of the gdb stubs provided by
RedBoot, the user should be able to interrupt the application with a
control-C. The application will not be polling the HAL diagnostics
UART at this point so instead the eCos interrupt management code
interacts with the gdb stubs to do the right thing. This configuration
option selects the interrupt priority. It should be noted that on some
processors with MCF5282-compatible interrupt controllers all
priorities for enabled interrupts should be unique, and it is the
responsibility of application developers to ensure this condition is
satisfied.
</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="M68K-MCFXXXX-PORT"
></A
><H2
>The HAL Port</H2
><P
>This section describes how the MCFxxxx variant HAL package implements
parts of the eCos HAL specification. It should be read in conjunction
with similar sections from the architectural and processor HAL
documentation.
</P
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-MCFXXXX-PORT-IO"
></A
><H3
>HAL I/O</H3
><P
>The <TT
CLASS="FILENAME"
>cyg/hal/var_io.h</TT
> header
provides various definitions for on-chip peripherals, where the
current processor has peripherals compatible with the MCF5282's.
This header is automatically included by the architectural
<TT
CLASS="FILENAME"
>cyg/hal/hal_io.h</TT
> so other
packages and application code will usually only include the latter.
</P
><P
>It is up to the processor HAL to specify exactly what <TT
CLASS="FILENAME"
>var_io.h</TT
> should export. For example the
MCF5213's <TT
CLASS="FILENAME"
>proc_io.h</TT
> header
contains the following:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># define HAL_MCFxxxx_HAS_MCF5282_INTC 1
# define HAL_MCFxxxx_INTC0_BASE (HAL_MCF521x_IPSBAR + 0x00000C00)
</PRE
></TD
></TR
></TABLE
><P
>This enables support within the variant HAL for a single
MCF5282-compatible interrupt controller, and cases <TT
CLASS="FILENAME"
>var_io.h</TT
> to export symbols such as:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>#ifdef HAL_MCFxxxx_HAS_MCF5282_INTC
// Two 32-bit interrupt mask registers
# define HAL_MCFxxxx_INTCx_IMRH 0x0008
# define HAL_MCFxxxx_INTCx_IMRL 0x000C
…
# define HAL_MCFxxxx_INTCx_ICRxx_IL_MASK (0x07 << 3)
# define HAL_MCFxxxx_INTCx_ICRxx_IL_SHIFT 3
</PRE
></TD
></TR
></TABLE
><P
>Symbols such as <CODE
CLASS="VARNAME"
>HAL_MCFxxxx_INTCx_IMRH</CODE
> can be used
to access the relevant hardware registers via
<CODE
CLASS="FUNCTION"
>HAL_READ_UINT32</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_WRITE_UINT32</CODE
>. Symbols like
<CODE
CLASS="VARNAME"
>HAL_MCFxxxx_INTCx_ICRxx_IL_MASK</CODE
> can be used to
generate or decode the contents of the hardware registers.
</P
><P
>The header file does mostly use a naming convention, but is not
guaranteed to be totally consistent. There may also be discrepancies
with the documentation because the manuals for the various Coldfire
processors are not always consistent about their naming schemes.
All I/O definitions provided by the variant HAL will start with
<TT
CLASS="LITERAL"
>HAL_MCFxxxx_</TT
>, followed by the name of the
peripheral. If a peripheral is likely to be a singleton, for example
an on-chip flash unit, then the name is unadorned. If there may be
several instances of the peripheral then the name will be followed by
a lower case x. For example:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># define HAL_MCFxxxx_CFM_CR 0x0000
…
# define HAL_MCFxxxx_UARTx_UMR 0x00
</PRE
></TD
></TR
></TABLE
><P
>Register names will be relative to some base address such as
<CODE
CLASS="VARNAME"
>HAL_MCFxxxx_CFM_BASE</CODE
> or
<CODE
CLASS="VARNAME"
>HAL_MCFxxxx_UART0_BASE</CODE
>, so code accessing a
register would look like:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
> HAL_READ_UINT32(HAL_MCFxxxx_CFM_BASE + HAL_MCFxxxx_CFM_PROT, reg);
…
HAL_WRITE_UINT8(base + HAL_MCFxxxx_UARTx_UTB, '*');
</PRE
></TD
></TR
></TABLE
><P
>Usually the register names are singletons, but in some cases such as
the interrupt controller priority registers there may be multiple
instances of the register and the names will be suffixed
appropriately. For example
<CODE
CLASS="VARNAME"
>HAL_MCFxxxx_INTCx_ICRxx_IL_MASK</CODE
> indicates the field
<TT
CLASS="LITERAL"
>IL</TT
> within one of the <TT
CLASS="LITERAL"
>ICR</TT
>
registers within one of the interrupt controllers.
</P
><P
>As mentioned earlier the processor HAL's <TT
CLASS="FILENAME"
>proc_io.h</TT
> will control which definitions
are exported by <TT
CLASS="FILENAME"
>var_io.h</TT
>.
Sometimes the processor HAL will then go on to undefine or redefine
some of the symbols, to reflect incompatibilities between the
processor's devices and the equivalent devices on the MCF5282. There
may also be additional symbols for the devices, and there will be
additional definitions for any processor-specific hardware. In
particular GPIO pin handling is handled by the processor HAL, not by
the variant HAL. Application developers should examine <TT
CLASS="FILENAME"
>proc_io.h</TT
> as well as
<TT
CLASS="FILENAME"
>var_io.h</TT
> and the
processor-specific documentation to see exactly what I/O definitions
are provided. When porting to a new Coldfire processor it is best to
start with an existing processor HAL and copy
code as appropriate. A search for <TT
CLASS="LITERAL"
>_HAS_</TT
> in
<TT
CLASS="FILENAME"
>var_io.h</TT
> will also be
informative.
</P
></DIV
><DIV
CLASS="REFSECT2"
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -