HAL I/O

The header file cyg/hal/proc_io.h specifies which generic MCFxxxx devices are present, and provides details of MCF5272-specific devices. This header file is automatically included by the architectural header cyg/hal/hal_io.h, so typically application code and other packages will just include the latter.

It should be noted that the Freescale documentation is occasionally confusing when it comes to numbering devices. For example the four on-chip timers are numbered TMR0 to TMR3, but in the interrupt controller the corresponding interrupts are numbered TMR1 to TMR4. The eCos port consistently starts numbering at 0, so these interrupts have been renamed TMR0 to TMR3.

Interrupt Handling

The header file cyg/hal/proc_intr.h provides VSR and ISR vector numbers for all interrupt sources. The VSR vector number, for example CYGNUM_HAL_VECTOR_TMR0, should be used for calls like cyg_interrupt_get_vsr. It corresponds directly to the M68K exception number. The ISR vector number, for example CYGNUM_HAL_ISR_TMR0, should be used for calls like cyg_interrupt_create. This header file is automatically included by the architectural header cyg/hal/hal_intr.h, and other packages and application code will normally just include the latter.

The eCos HAL macros HAL_INTERRUPT_MASK, HAL_INTERRUPT_UNMASK, HAL_INTERRUPT_SET_LEVEL, HAL_INTERRUPT_ACKNOWLEDGE, and HAL_INTERRUPT_CONFIGURE are implemented by the processor HAL. The mask and unmask operations are straightforward, simply manipulating the on-chip interrupt controller. The acknowledge and configure macros are only relevant for external interrupts: internal interrupts generated by on-chip devices do not need to be acknowledged. The set-level operation, used implicitly by higher level code such as cyg_interrupt_create, is mapped on to M68K IPL levels so interrupts can be given a priority between 1 and 7. Priority 7 corresponds to non-maskable interrupts and must be used with care: such interrupts cannot be managed safely by the usual eCos ISR and DSR mechanisms; instead application code will have to install a custom VSR and manage the entire interrupt.

Clock Support

The processor HAL provides support for the eCos system clock. This always uses hardware timer 3, which should not be used directly by application code. If gprof-based profiling is in use then that will use hardware timer 2. Timers 0 and 1 are never used by eCos so application code is free to manipulate these as required.

Some of the configuration options related to the system clock, for example CYGNUM_HAL_RTC_PERIOD, are actually contained in the platform HAL rather than the processor HAL. These options need to take into account the processor clock speed, a characteristic of the platform rather than the processor.

Cache Handling

The MCF5272 has a small instruction cache of 1024 bytes. This is fully supported by the processor HAL. There is no data cache.

Idle Thread Support

The configuration option CYGIMP_HAL_M68K_MCF5272_IDLE controls what happens when the kernel idle thread runs. The default behaviour is to put the processor to sleep until the next interrupt.

Profiling Support

The MCF5272 processor HAL provides a profiling timer for use with the gprof profiling package. This uses hardware timer 2, so application code should not manipulate this timer if profiling is enabled. The M68K architectural HAL implements the mcount function so profiling is fully supported on all MCF5272-based platforms.

Other Issues

The MCF5272 processor HAL does not affect the implementation of data types, stack size definitions, linker scripts, SMP support, system startup, or debug support. The architectural HAL's bit index instructions are used rather than the MCFxxxx variant HAL's versions since the MCF5272 does not implement the ff1 and bitrev instructions.

Other Functionality

The MCF5272 processor HAL only implements functionality defined in the eCos HAL specification and does not export any additional functions.