Configuration — Platform-specific Configuration Options
The AT91SAM7X-EK platform HAL package is loaded automatically when eCos is
configured for the
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.
The platform HAL package supports three separate startup types:
- This is the startup type which is normally used during application development. The board has GDB stubs programmed into flash and boots into that initially. arm-eabi-gdb is then used to load a RAM startup application into memory and debug it. It is assumed that the hardware has already been initialized by the stubs. By default the application will use the eCos virtual vectors mechanism to obtain certain services from the stubs, including diagnostic output.
- This startup type can be used for finished applications which will be programmed into flash at physical address 0x00100000. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization.
- This is an alternative development startup type. The application is loaded into RAM via a JTAG device and is run and debugged from there. The application will be self-contained with no dependencies on services provided by other software. It is expected that hardware setup will have been performed via the JTAG device prior to loading.
GDB Stubs 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 the GDB Stubs.
If the application is supposed to make use of services provided by a
ROM monitor, via the eCos virtual vector mechanism, then the
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, as a testing step
before switching to ROM startup.
If the application does not rely on a ROM monitor for diagnostic services then the serial port will be claimed for HAL diagnostics.
The AT91SAM7X-EK board contains a quantity of on-chip flash memory.
CYGPKG_DEVS_FLASH_AT91 package contains all the
code and data definitions necessary to support this part. This driver
is not active until the generic Flash support package,
CYGPKG_IO_FLASH, is included in the configuration.
The AT91SAM7X-EK board uses the AT91SAM7X's internal watchdog support. The
CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC package contains all the
code necessary to support this device. Within that package the
configuration option controls the watchdog timeout, and by default will
force a reset of the board upon timeout. This driver is not active until the
generic watchdog device support package,
CYGPKG_IO_WATCHDOG, is included in the configuration.
Note that on the AT91, the on-chip watchdog peripheral always starts running immediately, and so in configurations that do not include the watchdog driver, it is always disabled via its write-once register. In configurations which include the watchdog driver obviously the watchdog is not disabled otherwise it could not be subsequently re-enabled, and so the application must start and periodically reset the watchdog from the very beginning of execution.
USART Serial Driver
The AT91SAM7X-EK board use the AT91SAM7X's internal USART serial support
as described in the AT91 processor HAL documentation. Two serial ports are
available: the serial debug port which is mapped to virtual vector channel 0
in the HAL diagnostic driver or "
/dev/dbg" in the
interrupt-driven driver; and USART 0 which is mapped to virtual vector channel
1 and "
/dev/ser0". Only USART 0 supports modem control
signals such as those used for hardware flow control.
The AT91SAM7X-EK board can use the AT91SAM7X's internal ethernet MAC (EMAC)
support. The package
the necessary device driver support.
Due to the amount of RAM available, it is not possible to use the BSD-derived
TCP/IP stack. Instead either the lwIP TCP/IP stack (in
CYGPKG_NET_LWIP) should be used, or your application can
operate the driver directly in standalone mode. To enable the Ethernet driver
in your configuration, either include the “Common Ethernet Support”
CYGPKG_IO_ETH_DRIVERS) package in your configuration, or
base your configuration on an appropriate template, in particular the
Support for the Davicom DM9161A PHY (which comes from the
CYGPKG_DEVS_ETH_PHY package) is automatically configured
when ethernet support is enabled.
The AT91 ethernet device driver package in fact includes two separate driver implementations: one standard driver suitable for use in standalone mode, or with various TCP/IP stacks including at least RedBoot, BSD and lwIP; and one specific to lwIP. It is strongly recommended that the lwIP-specific driver is used with lwIP, given the low memory constraints. The lwIP-specific driver is a streamlined efficient version designed for very low RAM overhead. As a result it is implemented intentionally at the expense of features irrelevant to the AT91SAM7X, such as multiple network device support, and network debugging under RedBoot. Instead it has improvements such as zero-copy reception and transmission of data packets, leading to both faster operation, and smaller code and data memory footprint.
The choice between using the standard driver, or the lwIP-specific
driver is not made within this package, but is instead made in the
generic ethernet I/O package
using the options within the lwIP driver model component
standard driver is the default, and thus needs to be explicitly changed
to select the lwIP-specific driver model.
Careful selection and tuning of the configuration settings within the AT91 Ethernet package, and more especially, the lwIP stack, can result in realistic application use of TCP/IP at high speeds, despite the low RAM availability.
Note that a board design issue has required a workaround to be used in order to correctly initialize the PHY. This has two notable consequences: there is an extra delay of 700ms at startup time; and the programmatic use of the NRST line from the processor can confuse attached JTAG units into believing the processor has reset, which can in turn adversely affect debugging sessions. In the case of the Abatron BDI3000, it has been found that ensuring the last reset command was a "reset run", and then connecting via GDB immediately after target reset results in a stable debug session, albeit at the expense of the processor already having run some of the early HAL startup sequence.
The SAM7 variant 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 just three flags specific to this port:
The arm-eabi-gcc compiler supports many
variants of the ARM architecture.
-moption should be used to select the specific variant in use, and with current tools
-mcpu=arm7tdmiis the correct option for the ARM7TDMI processor in the SAM7X.
The arm-eabi-gcc compiler will compile
C and C++ files into the Thumb instruction set when this option is used.
The best way to build eCos in Thumb mode is to enable the configuration
This option allows programs to be created that mix ARM and Thumb instruction
sets. Without this option, some memory can be saved. This option should
be used if -mthumb is used. The best way to build eCos with Thumb interworking
is to enable the configuration option
|2019-03-19||eCosPro Non-Commercial Public License|