eCos® and eCosPro® Reference Manual
Prev		Next

Configuration

Name

Configuration -- Platform-specific Configuration Options

Overview

The M5282LITE platform HAL package is loaded automatically when eCos is configured for an M5282LITE target. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

Startup

The M5282LITE platform HAL package supports three separate startup types: RAM, DBUG and ROM. The configuration option CYG_HAL_STARTUP: controls which startup type is being used. For typical application development RAM startup should be used, and the application will be run via m68k-elf-gdb interacting with RedBoot using either serial or ethernet. It is assumed that the low-level hardware initialization, including setting up the memory map, has already been performed by RedBoot. By default the application will use certain services provided by RedBoot via the virtual vector mechanism, including diagnostic output, but that can be disabled via CYGSEM_HAL_USE_ROM_MONITOR.

ROM startup can be used for applications which boot directly from flash. All the hardware will be initialized, and the application is self-contained. This startup type is used by the flash-resident version of RedBoot, and can also be used for finished applications.

DBUG startup can be used for applications which will be loaded via the DBUG ROM monitor rather than RedBoot. As with RAM startup it is assumed that the memory map has already been set up, but the application will not use any services provided by the ROM monitor.

RedBoot and Virtual Vectors

If the application is intended to act as a ROM monitor, providing services for other applications, then the configuration option CYGSEM_HAL_ROM_MONITOR should be set. Typically this option is set only when building RedBoot.

If the application is supposed to make use of services provided by a ROM monitor, via the eCos virtual vector mechanism, then the configuration option CYGSEM_HAL_USE_ROM_MONITOR should be set. By default this option is enabled when building for a RAM startup, disabled otherwise. It can be manually disabled for a RAM startup, making the application self-contained. That is useful as a testing step before switching to ROM startup. It also allows applications to be run and debugged via BDM.

If the application does not rely on a ROM monitor for diagnostic services then one of the serial ports will be claimed for HAL diagnostics. By default eCos will use UART0 since on the standard board that is the only uart with a suitable connector. If the board has been extended with additional transceiver chips and connectors for UART1 or UART2 then one of those can be selected via the CYGHWR_HAL_M68K_MCFxxxx_DIAGNOSTICS_PORT. The baud rate for the selected port is controlled by CYGNUM_HAL_M68K_M5282LITE_DIAG_BAUD.

Optional Hardware

The M5282LITE board can be customized in a number of ways, primarily by connecting additional hardware to the MCU port. There are a number of configuration options which allow the platform HAL to adapt to minor changes to the hardware:

CYGHWR_HAL_M68K_M5282LITE_UART0_RTS: On the default hardware UART0 RTS and CTS are not connected. If the uart will only be used for interacting with RedBoot and debugging, that should be fine. If the uart will be used for another purpose, for example PPP, then it will usually be desirable to support RTS/CTS hardware handshaking. The board has an option pad to allow the serial connector's RTS pin to be wired to the processor's DTOUT3 pin. Alternatively any of the DTIN3, DTOUT1 or DTIN1 signals on the MCU port could be wired instead. This configuration option can be used to specify how the board has been wired. Note that CTS would have to be wired as well as RTS.
CYGHWR_HAL_M68K_M5282LITE_UART0_CTS: As with RTS, CTS is not wired on the default board. Although there is an option pad this is not usable: the option pad would wire the serial connector's CTS pin to the processor's DTIN3 pin, but DTIN3 cannot be configured to carry the uart CTS signal. Instead one of the DTOUT2, DTIN2, DTOUT0, or DTIN0 signals on the MCU port should be used.
CYGHWR_HAL_M68K_M5282LITE_UART1_CONNECTED, CYGHWR_HAL_M68K_M5282LITE_UART1_RTS, CYGHWR_HAL_M68K_M5282LITE_UART1_RTS_RS485, CYGHWR_HAL_M68K_M5282LITE_UART1_CTS: The default board has no connector for the on-chip UART1. However all the signals are accessible on the MCU port so it is possible to wire up a suitable transceiver chip and connector. Enabling CYGHWR_HAL_M68K_M5282LITE_UART1_CONNECTED specifies that the RX and TX signals are connected. RTS is optional and can come from any of DTOUT3, DTIN3, DTOUT1 or DTIN1, although obviously the same signal cannot be used for both UART0 and UART1. RTS may be used either to tristate an RS485 transceiver in which case CTS should be left disconnected, or it can be used for RS232 hardware handshaking in which case CTS must also be connected. The CTS signal can come from any of DTOUT2, DTIN2, DTOUT0 or DTIN0.
CYGHWR_HAL_M68K_M5282LITE_UART2_CONNECTED: The on-chip UART2 is not connected on the standard board. However if this uart is needed then it can be accessed via the MCU port, using either the A1A0 SCL/SDA signals normally used for I2C, or the A3A2 CANTX/CANRX signals normally used for CAN communication. This UART does not support RTS or CTS.

Flash Driver

The platform HAL package contains flash driver support for the external flash device. By default this is inactive, and it can be made active by loading the generic flash package CYGPKG_IO_FLASH.

Special Registers

The MCF5282 processor has a number of special registers controlling the cache, on-chip RAM and flash, and so on. The platform HAL provides a number of configuration options for setting these, for example CYGNUM_HAL_M68K_M5282LITE_RAMBAR controls the initial value of the RAMBAR register.

System Clock

By default the system clock interrupts once every 10ms, corresponding to a 100Hz clock. This can be changed by the configuration option CYGNUM_HAL_RTC_PERIOD, the number of microseconds between clock ticks. Other clock-related settings are recalculated automatically if the period is changed.

Compiler Flags

The platform HAL defines the default compiler and linker flags for all packages, although it is possible to override these on a per-package basis. Most of the flags used are the same as for other architectures supported by eCos. There are three flags specific to this port:

-m5200: The m68k-elf-gcc compiler supports many variants of the M68K architecture, from the original 68000 onwards. A -m option should be used to select the specific variant in use, and with current tools -m5200 is the closest match for an MCF5282 processor.
-malign-int: This option forces m68k-elf-gcc to align integer and floating point data to a 32-bit boundary rather than a 16-bit boundary. It should improve performance. However the resulting code is incompatible with most published application binary interface specifications for M68K processors, so it is possible that this option causes problems with existing third-party object code.
-fomit-frame-pointer: Traditionally the %A6 register was used as a dedicated frame pointer, and the compiler was expected to generate link and unlink instructions on procedure entry and exit. These days the compiler is perfectly capable of generating working code without a frame pointer, so omitting the frame pointer often saves some work during procedure entry and exit and makes another register available for optimization. However without a frame pointer register the m68k-elf-gdb debugger is not always able to interpret a thread stack, so it cannot reliably give a backtrace. Removing -fomit-frame-pointer from the default flags will make debugging easier, but the generated code may be worse.

Prev	Home	Next
Setup	Up	The HAL Port

Documentation license for this page: eCosPro License

Privacy & Legal Statements