Name
On-chip Subsystems and Peripherals — Hardware Support
Hardware support
On-chip memory
The Freescale Kinetis parts include on-chip SRAM, and on-chip FLASH. The SRAM and FLASH can vary in size depending on the model. There is also support in some models for external memory, 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 Kinetis on-chip FLASH 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 device 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.
On-chip FLASH
The package CYGPKG_DEVS_FLASH_KINETIS
(“Kinetis
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 drivers”
(CYGPKG_IO_FLASH
) package is included in the eCos
configuration. The driver will configure itself automatically for the
size and parameters of the specific Kinetis variant which has been
selected in the eCos configuration.
Cache Handling
The variant HAL supplies
the cyg/hal/hal_cache.h
header
file to describe cache support to the generic eCos code. Some Kinetis
K series parts have access to a Cortex-M4 core cache
(the CYGINT_HAL_CACHE
will be defined by the
platform if appropriate). If the configured part does not provide a
cache then the header will supply null macros for the required
functions.
When a cache is available the HAL currently supports a 16KiB cache, split into a 8KiB data cache and a 8KiB instruction cache.
The architecture HAL also defines a macro HAL_MEMORY_BARRIER()
which acts to synchronize the pipeline, delaying execution until all
previous operations, including all pending writes, are complete. This
will usually be necessary when interacting with devices that access
memory directly.
Note | |
---|---|
The use of the default Cortex-M
architecture |
Serial I/O
The Kinetis 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_FREESCALE_UART
which
provides all support for the Kinetis 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 instead.
The HAL defines CDL
interfaces, CYGINT_HAL_FREESCALE_UART0
to CYGINT_HAL_FREESCALE_UART5
for each of the
available UARTs. 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.
The Kinetis UARTs provide TX
and RX
data lines plus hardware flow control
using RTS
/CTS
for those UARTs
that have the signals available on the platform hardware.
Note | |
---|---|
The |
Interrupts
The Kinetis 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
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. This is useful to drivers and other packages that need to configure and use different I/O lines for different devices.
A descriptor is created with
the CYGHWR_HAL_KINETIS_PIN(port,bit,mux,cnf)
macro, where the parameters required are:
-
port
-
This identifies the GPIO port to which the pin is attached. Ports are
identified by the letters from
A
toF
. -
bit
-
This gives the bit or pin number within the port. These are numbered
from
0
to31
. -
mux
-
This paramater specifies how the pin should be used, and should be in
the range
0
to7
. The value0
corresponds to the pin being disabled (Analog), with1
used to specify GPIO control. The other values2
to7
are used to indicate alternative function mappings as defined by the CPU variant. -
cnf
-
This option allows explicit Port Control register configuration
settings to be specified. The bits as held in
the
cnf
value are defined as per the relevant Kinetis Reference Manual.
The macro CYGHWR_HAL_KINETIS_PIN_NONE
may be used
in place of a pin descriptor and has a value that no valid descriptor
can take. It may therefore be used as a placeholder where no GPIO pin
is present or to be used. This can be useful when defining pin
configurations for a series of instances of a peripheral (e.g. UART
ports), but where not all instances support all the same pins
(e.g. hardware flow control lines).
The function hal_set_pin_function(pin)
configures
the pin according to the descriptor and must be called before other
GPIO operations are performed on the pin.
The macros to manipulate GPIO state all take a suitably constructed
GPIO pin descriptor as an argument.
It is recommended to consult the header
file <cyg/hal/var_io_gpio.h>
(also present in the include
subdirectory of the Kinetis variant HAL package within the eCos source
repository), for the complete list if needed.
RTC/Wallclock
eCos includes a RTC (known in eCos as a wallclock) device driver for
the on-chip RTC in the Kinetis family. This is located in the
package CYGPKG_DEVICES_WALLCLOCK_KINETIS_RTC
(“Real-time clock”).
Profiling Support
The Kinetis HAL contains support for gprof-based
profiling using a sampling timer. The default timer used
is PIT0
, which is one of the basic periodic
interrupt timers, leaving the more complex timers for application
code. The timer used is selected by
the CYGHWR_HAL_CORTEXM_KINETIS_PROFILE_PIT_CHANNEL
configuration option. 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.
Clock Control
The CDL section CYGHWR_HAL_CORTEXM_KINETIS_CLOCKING
contains many options to configure the various Kinetis on-chip clocks,
based on platform supplied default values. The CDL will calculate the
main CYGNUM_HAL_CORTEXM_KINETIS_MCGOUT_FREQ
frequency value, which in turn is used in conjunction with the
configured clock divider values to set the frequencies of the relevant
subsystems.
The actual calculated values of the main clocks, in Hz, are stored in
the global variables hal_kinetis_sysclk
and hal_kinetis_busclk
. The clock supplied to the
Cortex-M SysTick timer, HCLK/8
, is also assigned to
the global
variable hal_cortexm_systick_clock
. These variables
are used, rather than configuration options, in anticipation of future
support for power management by varying the system clock rate.
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.
2024-12-10 | eCosPro Non-Commercial Public License |