The SAM family contains many on-chip peripherals, many of which are compatible with devices on Atmel SAM3, SAM4, SAM7, SAM9 and SAMA5 parts. Where possible, the drivers are shared, and in places, package names and terminology show this.
The Atmel SAM parts include on-chip SRAM, and on-chip FLASH. The RAM can vary in size from as little as 4KiB to 128KiB. The FLASH can be up to 1024KiB in size depending on model. There is also support in some models for external SRAM and Flash, which eCos may use where available.
Typically, an eCos platform HAL port will expect a GDB stub ROM monitor or RedBoot image to be programmed into the SAM on-chip ROM memory for development, and the board would boot this image from reset. The stub ROM/RedBoot provides GDB stub functionality so it is then possible to download and debug stand-alone and eCos applications via the gdb debugger using serial interfaces or other debug channels. The JTAG interface may also be used for development if a suitable JTAG adaptor is available. If RedBoot is present it may also be used to manage the on-chip and external flash memory. For production purposes, applications are programmed into external or on-chip FLASH and will be self-booting.
The package CYGPKG_DEVS_FLASH_SAM ("SAM
Flash memory support") provides a driver for the on-chip
flash. This driver conforms to the Version 2 flash driver API,
and is automatically enabled if the generic "Flash device
CYGPKG_IO_FLASH) package is included
in the eCos configuration. The driver will configure itself
automatically for the size and parameters of the specific SAM
variant by querying the ChipID register.
The SAM contains a small unified cache controller, the variant HAL supplies the cyg/hal/hal_cache.h header to implement cache control. This header describes the cache size and provides macros for enabling and disabling the cache as well as syncing and invalidating cache lines. The cache controller has limited functionality, so not all cache operations are supported.
The SAM variant HAL supports basic polled HAL diagnostic I/O
over any of the on-chip serial devices. There is also a fully
interrupt-driven serial device driver suitable for eCos
applications for all on-chip serial devices. The serial driver
consists of an eCos package:
CYGPKG_IO_SERIAL_ARM_AT91 which provides
support for the SAM on-chip serial devices. Using the HAL
diagnostic I/O support, any of these devices can be used by the
ROM monitor or RedBoot for communication with GDB. If a device is
needed by the application, either directly or via the serial
driver, then it cannot also be used for GDB communication using
the HAL I/O support. An alternative serial port should be used
The HAL defines CDL interfaces, CYGINT_HAL_CORTEXM_SAM_UART0, CYGINT_HAL_CORTEXM_SAM_UART1 and CYGINT_HAL_CORTEXM_SAM_USART0 to CYGINT_HAL_CORTEXM_SAM_USART3 for each of the available UARTs and USARTs. The platform HAL CDL should contain an implements directive for each such UART that is available for use on the board. This will enable use of the UART for diagnostic use.
For historical compatibility with the shared device drivers, hardware UART0 is mapped to the driver DEBUG UART, hardware USARTs 0 to 3 are mapped to driver UARTs 0 to 3 and hardware UART1 is mapped to driver UART5.
The SAM UARTs provide only TX and RX data lines while the USARTs also implement hardware flow control using RTS/CTS for those USARTs that have them connected.
The SAM HAL relies on the architectural HAL to provide support for the interrupts directly routed to the NVIC. The cyg/hal/var_intr.h header defines the vector mapping for these.
GPIO interrupts are currently not fully decoded, so all interrupts originating from a particular GPIO controller are routed to the single interrupt vector for that controller.
Pin Multiplexing and GPIO
The variant HAL provides support for packaging the configuration of a GPIO line into a single 32-bit descriptor that can then be used with macros to configure the pin and set and read its value. Details are supplied later.
eCos includes RTC (known in eCos as a wallclock) device drivers
for the on-chip RTC in the SAM family. This is located in the
("AT91 wallclock driver").
The SAM HAL contains support for gprof-base profiling using a sampling timer. The default timer used is Timer Counter 0. The timer used is selected by a set of #defines in src/sam_misc.c which can be changed to refer to a different timer if required. This timer is only enabled when the gprof profiling package (CYGPKG_PROFILE_GPROF) is included and enabled in the eCos configuration, otherwise it remains available for application use.
The platform HAL must provide the input oscillator frequency
CYGHWR_HAL_CORTEXM_SAM_OSC_MAIN) in its
CDL file. This is then combined with the following options defined
in this package to define the default system clocks:
PLL input clock divider.
PLL input clock multiplier. The resulting PLL output clock will be the main oscillator frequency multiplied by this value and divided by CYGHWR_HAL_CORTEXM_SAM_CLOCK_PLL_DIVA.
This is an additional divide-by-two divider applied to the output from the PLL.
Master clock prescaler. The PLL output clock is divided by this value to give the frequency of the master clock that is then distributed to the CPU and peripherals.
This option defines the number of wait states applied to flash memory accesses. This will vary with the main clock frequency. The default is to set this to the maximum value.
The actual values of these clocks, in Hz, is stored in global
hal_sam_upllck. The clock supplied to the
SysTick timer, MCLK/8, is also assigned to
hal_cortexm_systick_clock. These variables are
set by examining the actual hardware register settings, rather
than from the CDL, so they reflect settings made by any bootloader
or JTAG adaptor.
Note that when changing or configuring any of these clock settings, you should consult the relevant processor datasheet as there may be both upper and lower constraints on the frequencies of some clock signals, including intermediate clocks. There are also some clocks where, while there is no strict constraint, clock stability is improved if values are chosen wisely. Finally, be aware that increasing clock speeds using this package may have an effect on platform specific properties, such as memory timings which may have to be adjusted accordingly.