Microcomputer Systems 1Interaction of ADSP-BF533 Ez-Kit Lite with the outside worldLAB2 Example

Veton Kpuska

*Veton Kpuska*BF533 EZ-Kit LiteThe EZ-KIT Lite provides four (4) push buttons and six (6) LEDs for general-purpose IO.

4 SW push-button switchesThe four general-purpose push button switches are labeled SW4 through SW7. A status of each individual button can be read through programmable flag (PF) inputs:PF8 through PF11. A PF reads 1 when a corresponding switch is being pressed-on. When the switch is released, the PF reads 0. A connection between the push button and PF input is established through the SW9 DIP switch.

6 LEDsThe six LEDs, labeled LED4 through LED9, are accessed via some of the general-purpose IO pins of the flash memory interface.

Veton Kpuska

*Veton Kpuska*BF533 EZ-Kit Lite

Veton Kpuska

*Veton Kpuska*SW9 SwitchFor more information see ADSP-BF533 EZ-KIT Lite Evaluation System Manual: ADSP_BF533_EZ_KIT_Lite_Manual_Rev_3.0.pdf

Veton Kpuska

*Veton Kpuska*Push Button Enable Switch (SW9)Positions: 1 through 4 : disconnect the drivers associated with the push buttons from the PF pins of the processor.5 and 6 : are used to connect the transmit and receive frame syncs and clocks of SPORT0. This is important when the AD1836 video decoder and the processor are communicating in I2S mode. Table 2-6 shows which PF is driven when the switch is in the default (ON) position.

Veton Kpuska

*Veton Kpuska*BF533 EZ-Kit Lite Circuit Schematics

Veton Kpuska

*Veton Kpuska*Lab 1 DetailsSource code directory contains an example ADSP-BF533 project that shows howProgrammable Flag pins (FIO),Interrupts, and Timer can be configured in C. It also demonstrates the access to the LEDs on the EZ-KIT Lite, which are connected to the on-board Flash.

Files contained in this directory:

BF533 Flags C.dpjVisualDSP++ project filemain.cC file containing the main program and variable declarationInitialisation.cC file containing all initialization routinesISRs.cC file containing the interrupt service routines for Timer and FIOBF533 Flags.hC header file containing prototypes and macrosreadme.txtthis project description file

Veton Kpuska

*Veton Kpuska*Lab 1: Functional DescriptionThis example demonstrates the initialization of the External Bus Interface Unit - EBIU (asynchronous access), Timer 0, FIO pins,Interrupts and the on-board Flash, which allows access to the six LEDs on the EZ-KIT.The program simply turns on one LED and rotates the pattern left or right, depending on the state of an internal flag. The switch connected to PF8 (SW4) can be used to toggle the state of this flag, which results in a change of direction of the moving light.

Veton Kpuska

*Veton Kpuska*Lab 1: Implementation DescriptionThe main file calls:FIO setupTimer setup EBIU setup Flash setupInterrupt configurationEndless loop waiting for Timer interrupt or Flag interrupt

Veton Kpuska

*Veton Kpuska*Lab 1. Code Walk Through#include "BF533 Flags.h"#include "ccblkfn.h"#include "sysreg.h"

//--------------------------------------------------------------------------//// Variables ////--------------------------------------------------------------------------//// flag indicating direction of moving light (toggled in FlagA ISR)short sLight_Move_Direction = 0;

//--------------------------------------------------------------------------//// Function:main ////--------------------------------------------------------------------------//void main(void){sysreg_write(reg_SYSCFG, 0x32);//Initialize System Configuration RegisterInit_Flags();Init_Timers();Init_EBIU();Init_Flash();Init_Interrupts();

while(1);}

Veton Kpuska

*Veton Kpuska*BF533 Flags.h#ifndef __BF533_FLAGS_DEFINED#define __BF533_FLAGS_DEFINED

//--------------------------------------------------------------------------//// Header files ////--------------------------------------------------------------------------//#include #include

//--------------------------------------------------------------------------//// Symbolic constants ////--------------------------------------------------------------------------//// addresses for Port B in Flash A#define pFlashA_PortB_Dir (volatile unsigned char *)0x20270007#define pFlashA_PortB_Data (volatile unsigned char *)0x20270005

//--------------------------------------------------------------------------//// Global variables ////--------------------------------------------------------------------------//extern short sLight_Move_Direction;

//--------------------------------------------------------------------------//// Prototypes ////--------------------------------------------------------------------------//// in file Initialization.cvoid Init_Flags(void);void Init_Timers(void);void Init_EBIU(void);void Init_Flash(void);void Init_Interrupts(void);// in file ISRs.cEX_INTERRUPT_HANDLER(Timer0_ISR);EX_INTERRUPT_HANDLER(FlagA_ISR);

#endif //__BF533_FLAGS_DEFINED

See Table 1-5. Flash A Configuration Registers for Ports A and B in slide 14

Veton Kpuska

*Veton Kpuska*Lab 1: NoteMake sure that switch SW9 pin1 is turned on (connects switch SW7 to pin PF8)123456

Veton Kpuska

LED Interface

Veton Kpuska

*Veton Kpuska*How to configure the flash memory to control the LEDsParallel interfaces present on the FLASH memory chips

Veton Kpuska

*Veton Kpuska*Flash General-Purpose IOGeneral-purpose IO signals are controlled by means of setting appropriate registers of the flash A or flash B. These registers are mapped into the processors address space, as shown in the Table below (ADSP-BF533 EZ-KIT Lite Evaluation System Manual Flash Memory)

Veton Kpuska

*Veton Kpuska*Flash General-Purpose IOFlash device IO pins are arranged as 8-bit ports labeled A through G. There is a set of 8-bit registers associated with each port. These registers are used for: Direction, Data In, and Data Out. Note that the Direction and Data Out registers are cleared to all zeros at power-up or hardware reset.The Direction register controls IO pins direction. This is a 8-bit read-write register.When a bit is 0, a corresponding pin functions as an input. When the bit is 1, a corresponding pin is an output. The Data In register allows reading the status of ports pins. This is a 8-bit read-only register.The Data Out register allows clearing an output pin to 0 or setting it to 1. This is a 8-bit read-write register.The ADSP-BF533 EZ-KIT Lite board employs only flash A and flash B ports A and B. Table 1-5 and Table 1-6 provide configuration register addresses for flash A and flash B, respectively (only ports A and B are listed in the next slide). The following bits connect to the expansion board connector.Flash A: port A bits 7 and 6, as well as port B bits 7 and 6Flash B: port A bits 70

Veton Kpuska

*Veton Kpuska*Flash A & B Configuration Registers for Ports A and B.Table 1-5. Flash A Configuration Registers for Ports A and B

Table 1-6. Flash B Configuration Registers for Ports A and B

Register NamePort A AddressPort B AddressData In (read-only)0x2027 00000x2027 0001Data Out (read-write)0x2027 00040x2027 0005Direction (read-write)0x2027 00060x2027 0007

Register NamePort A AddressPort B AddressData In (read-only)0x202E 00000x202E 0001Data Out (read-write)0x202E 00040x202E 0005Direction (read-write)0x202E 00060x202E 0007

Veton Kpuska

*Veton Kpuska*IO Assignments for Port A and Port BTable 1-7 Flash A Port A Controls.

PPI Parallel Peripheral Interface & Associated Configuration Registers.

Bit NumberUser IOBit Value7Not definedAny6Not definedAny5PPI clock select bit 100=local OSC (27MHz)4PPI clock select bit 001=video decoder pixel clock1x=expansion board PPI clock3Video decoder reset0=reset ON; 1=reset OFF2Video encoder reset0=reset ON; 1=reset OFF1ReservedAny0Codec reset0=reset ON; 1=reset OFF

Veton Kpuska

*Veton Kpuska*IO Assignments for Port A and Port BTable 1-8 Flash A Port B Controls.

Bit NumberUser IOBit Value7Not usedAny6Not usedAny5LED90=LED OFF; 1=LED ON4LED80=LED OFF; 1=LED ON3LED70=LED OFF; 1=LED ON2LED60=LED OFF; 1=LED ON1LED50=LED OFF; 1=LED ON0LED40=LED OFF; 1=LED ON

Veton Kpuska

*Veton Kpuska*User LEDs (LED4-9)Six LEDs connect to six general-purpose IO pins of the flash memory (U5). The LEDs are active high and are lit by writing a 1 to the correct memory address in the flash memory.

Veton Kpuska

*Veton Kpuska*BF533 Interface to PFI/PFsPFI/PFsEBIULED(6)

Veton Kpuska

FIO SetupFIO setupTimer setup EBIU setup Flash setupInterrupt configurationEndless loop waiting for Timer interrupt or Flag interrupt

Veton Kpuska

*Veton Kpuska*Initialization.c#include "BF533 Flags.h"

//--------------------------------------------------------------------------//// Function:Init_Flags //// //// Parameters:None //// //// Return:None //// //// Description: This function configures PF8 as input for edge sensitive ////interrupt generation. ////The switch connected to PF8 (SW4) can be used to change the////direction of the moving light. ////--------------------------------------------------------------------------//void Init_Flags(void){*pFIO_INEN= 0x0100;*pFIO_DIR= 0x0000;*pFIO_EDGE= 0x0100;*pFIO_MASKA_D= 0x0100;} This value programs PF8 pin. See BF533 HRM or slide 25for additional information.This reset value makes all pins as inputs. See BF533 HRM or slide 26for additional informationThis value sets PF8 pin to be EDGE sensitive See BF533 HRM or slide 28for additional informationThis value enables PF8 pin to accepts interrupts. See BF533 HRM or slide 30 for additional information

Veton Kpuska

*Veton Kpuska*Programmable Flags PFI/PFsThe processor supports 16 bidirectional programmable flags (PFx) or general-purpose I/O pins, PF[15:0]. Each pin can be individually configured as either an input or an output by using the Flag Direction register (FIO_DIR). When configured as output:the Flag Data register (FIO_FLAG_D) can be directly written to specify the state of all PFx pins.the state written to the Flag Set (FIO_FLAG_S), Flag Clear (FIO_FLAG_C), and Flag Toggle (FIO_FLAG_T) registersdetermines the state driven by the output PFx pin. Regardless of how the pins are configured, as an input or an output, reading any of these registers:FIO_FLAG_D, FIO_FLAG_S, FIO_FLAG_C, or FIO_FLAG_T returns the state of each pin.They can be enabled via bits in Flag Input Enable register (FIO_INEN)Input buffer associated with the PF flags is disabled by default. The Flag Input Enable register (FIO_INEN) is used to enable them.

Veton Kpuska

*Veton Kpuska*Flag Input Enable RegisterADSP-BF533 Blackfin Processor Hardware Reference*pFIO_INEN = 0x0100 0000 0001 0000 0000

Veton Kpuska

*Veton Kpuska*FIO_DIR RegisterEach pin, PF[15:0], can be individually configured as either an input or an output by using the Flag Direction register (FIO_DIR)The Flag Direction register (FIO_DIR) is a read-write register. Each bit position corresponds to a PFx pin. A logic 1 configures a PFx pin as an output, driving the state contained in the FIO_FLAG_D register. A logic 0 configures a PFx pin as an input. The reset value of this register is 0x0000, making all PF pins inputs upon reset. Note when using the PFx pin as an input, the corresponding bit should also be set in the Flag Input Enable register.

*pFIO_DIR = 0x0000 0000 0000 0000 0000

Veton Kpuska

*Veton Kpuska*Programming PFx to generate an interruptEach PFx pin can be configured to generate an interrupt. When a PFx pin is configured as an input, an interrupt can be generated according to the state of the pin, either high or lowan edge transition (low to high or high to low), or on both edge transitions (low to high and high to low).Input sensitivity is defined on a per-bit basis by the Flag Polarity register (FIO_POLAR), the Flag Interrupt Sensitivity register (FIO_EDGE) and The Flag Set on Both Edges register (FIO_BOTH). Input polarity is defined on a per-bit basis by the Flag Polarity register. When the PFx inputs are enabled and a PFx pin is configured as an output, enabling interrupts for the pin allows an interrupt to be generated by setting the PFx pin.

Veton Kpuska

*Veton Kpuska*FIO_EDGE: Flag Interrupt Sensitivity Register*pFIO_EDGE = 0x0100 0000 0001 0000 0000

Veton Kpuska

*Veton Kpuska*FIO_MASKx_D, FIO_MASKx_C,FIO_MASKx_S, FIO_MASKx_T, Both Flag Interrupt A and Flag Interrupt B are supported by a set of four dedicated registers:Flag Mask Interrupt Data registerFlag Mask Interrupt Set registerFlag Mask Interrupt Clear registerFlag Interrupt Toggle register

The Flag Mask Interrupt registers:FIO_MASKA_D, FIO_MASKA_S, FIO_MASKA_C, FIO_MASKA_T, andFIO_MASKB_D, FIO_MASKB_S, FIO_MASKB_C, FIO_MASKB_T are implemented as complementary pairs of:Data D, write-1-to-set S, write-1-to-clear C, and write-1-to-toggle T registers. This implementation provides the ability to:enable or disable a PFx pin to act as a processor interrupt without requiring read-modify-write accessesor todirectly specify the mask value with the data register.

Veton Kpuska

*Veton Kpuska*FIO_MASKA_D Register to Enable Interrupt*pFIO_MASKA_D = 0x0100 0000 0001 0000 0000

Veton Kpuska

*Veton Kpuska*Initialization.c#include "BF533 Flags.h"

//--------------------------------------------------------------------------//// Function:Init_Flags //// //// Parameters:None //// //// Return:None //// //// Description: This function configures PF8 as input for edge sensitive ////interrupt generation. ////The switch connected to PF8 (SW4) can be used to change the////direction of the moving light. ////--------------------------------------------------------------------------//void Init_Flags(void){*pFIO_INEN= 0x0100;*pFIO_DIR= 0x0000;*pFIO_EDGE= 0x0100;*pFIO_MASKA_D= 0x0100;} This value programs PF8 pin. See BF533 HRM or slide 25for additional information.This reset value makes all pins as inputs. See BF533 HRM or slide 26for additional informationThis value sets PF8 pin to be EDGE sensitive See BF533 HRM or slide 28for additional informationThis value enables PF8 pin to accepts interrupts. See BF533 HRM or slide 30 for additional information

Veton Kpuska

Timer Set UpFIO setupTimer setup EBIU setup Flash setupInterrupt configurationEndless loop waiting for Timer interrupt or Flag interrupt

Veton Kpuska

*Veton Kpuska*Timer SetupThe processor features three identical 32-bit general-purpose timers, acore timer, and a watchdog timer.

The general-purpose timers can be individually configured in any of three modes:Pulse Width Modulation (PWM_OUT) modePulse Width Count and Capture (WDTH_CAP) modeExternal Event (EXT_CLK) mode

The core timer is available to generate periodic interrupts for a variety of system timing functions.

The watchdog timer can be used to implement a software watchdog function. A software watchdog can improve system availability by generating an event to the Blackfin processor core if the timer expires before being updated by software.

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Timers //// //// Parameters:None //// //// Return:None //// //// Description:This function initialises Timer0 for PWM mode. ////It is used as reference for the 'shift-clock'. ////--------------------------------------------------------------------------//void Init_Timers(void){*pTIMER0_CONFIG= 0x0019;*pTIMER0_PERIOD= 0x00800000;*pTIMER0_WIDTH= 0x00400000;*pTIMER_ENABLE= 0x0001;}

Veton Kpuska

*Veton Kpuska*General-Purpose TimerEach general-purpose timer has one dedicated bidirectional chip pin, TMRx. This pin functions as:an output pin in the PWM_OUT mode and as an input pin in the WDTH_CAP and EXT_CLK modes.

To provide these functions, each timer has (4) four 32 bit registers. Timer Configuration (TIMERx_CONFIG) registersTimer Counter (TIMERx_COUNTER) registersTimer Period (TIMERx_PERIOD) registersTimer Pulse Width (TIMERx_WIDTH) registers

Veton Kpuska

*Veton Kpuska*Timer Block DiagramWhen clocked internally, the clock source is the processors peripheral clock (SCLK). Assuming the peripheral clock is running at 133 MHz, the maximum period for the timer count is ((232-1) / 133 MHz) = 32.2 seconds.Default SCLK clock rate is 54 MHz.For more info see: PLL_CTL & PLL_DIV registers.

Veton Kpuska

*Veton Kpuska*Timer Control TIMER_ENABLE & TIMER_DISABLEThe Timer Enable (TIMER_ENABLE) register can be used to enable all three timers simultaneously. The register contains three write-1-to-set control bits, one for each timer. Correspondingly, the Timer Disable (TIMER_DISABLE) register contains three write-1-to-clear control bits to allow simultaneous or independent disabling of the three timers. Either the Timer Enable or the Timer Disable register can be read back to check the enable status of the timers. A 1 indicates that the corresponding timer is enabled. The timer starts counting three SCLK cycles after the TIMENx bit is set.

Veton Kpuska

*Veton Kpuska*Timer Control: TIMER_STATUSThe Timer Status (TIMER_STATUS) register contains an Interrupt Latch bit (TIMILx) and an Overflow/Error Indicator bit (TOVF_ERRx) for each timer.These sticky bits are set by the timer hardware and may be polled by software.They need to be cleared by software explicitly, by writing a 1 to the corresponding bit.

Veton Kpuska

*Veton Kpuska*Timer Configuration: TIMERx_CONFIGTo enable a timers interrupts, Set the IRQ_ENA bit in the timers Configuration (TIMERx_CONFIG) register, and With the IRQ_ENA bit cleared, the timer does not set its Timer Interrupt latch (TIMILx) bits. Unmask the timers interrupt by setting the corresponding bits of the IMASK and SIC_IMASK registers.To poll the TIMILx bits without permitting a timer interrupt, programs can set the IRQ_ENA bit while leaving the timers interrupt masked.

Veton Kpuska

*Veton Kpuska*Timer ConfigurationWith interrupts enabled, Make sure that the interrupt service routine (ISR) clears the TIMILx latch before the RTI instruction, to ensure that the interrupt is not reissued.

To make sure that no timer event is missed, the latch should be reset at the very beginning of the interrupt routine when in External Clock (EXT_CLK) mode.

Veton Kpuska

*Veton Kpuska*Timer RegistersEach timer provides four registers:TIMERx_CONFIG[15:0] Timer Configuration registerTIMERx_WIDTH[31:0] Timer Pulse Width registerTIMERx_PERIOD[31:0] Timer Period registerTIMERx_COUNTER[31:0] Timer Counter registerThree registers are shared between the three timers:TIMER_ENABLE[15:0] Timer Enable registerTIMER_DISABLE[15:0] Timer Disable registerTIMER_STATUS[15:0] Timer Status register

The size of accesses is enforced. A 32-bit access to a Timer Configuration register (16-bit register) or a 16-bit access to a Timer Pulse Width, Timer Period, or Timer Counter registers (32-bit registers) results in a Memory-Mapped Register (MMR) error.Both 16- and 32-bit accesses (reads) are allowed for the Timer Enable, Timer Disable, and Timer Status registers. On a 32-bit read, the upper word returns all 0s.

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Timers //// //// Parameters:None //// //// Return:None //// //// Description:This function initialises Timer0 for PWM mode. ////It is used as reference for the 'shift-clock'. ////--------------------------------------------------------------------------//void Init_Timers(void){*pTIMER0_CONFIG= 0x0019;*pTIMER0_PERIOD= 0x00800000;*pTIMER0_WIDTH= 0x00400000;*pTIMER_ENABLE= 0x0001;}TIMER0_CONFIG REGISTER INFO

Veton Kpuska

*Veton Kpuska*Timer Configuration Registers0x0019 = 0000 0000 0001 1001PWM_OUTPERIOD_CNTIRQ_ENAGO BACK

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Timers //// //// Parameters:None //// //// Return:None //// //// Description:This function initialises Timer0 for PWM mode. ////It is used as reference for the 'shift-clock'. ////--------------------------------------------------------------------------//void Init_Timers(void){*pTIMER0_CONFIG= 0x0019;*pTIMER0_PERIOD= 0x00800000;*pTIMER0_WIDTH= 0x00400000;*pTIMER_ENABLE= 0x0001;}TIMER0_PERIOD REGISTER INFO

Veton Kpuska

*Veton Kpuska*TIMERx_PERIOD and TIMERx_WIDTH RegistersUsage of the Timer Period register (TIMERx_PERIOD) and the Timer Pulse Width register (TIMERx_WIDTH) varies depending on the mode of the timer:In Pulse Width Modulation mode (PWM_OUT), both the Timer Period and Timer Pulse Width register values can be updated on-the-fly since the Timer Period and Timer Pulse Width (duty cycle) register values change simultaneously.In Pulse Width and Period Capture mode (WDTH_CAP), the Timer Period and Timer Pulse Width buffer values are captured at the appropriate time. The Timer Period and Timer Pulse Width registers are then updated simultaneously from their respective buffers.Both registers are read-only in this mode.In External Event Capture mode (EXT_CLK), the Timer Period register is writable and can be updated on-the-fly. The Timer Pulse Width register is not used.

Veton Kpuska

*Veton Kpuska*Timer Period Registers0x00800000 = 0000 0000 1000 0000 0000 0000 0000 0000 = 223 = 83688608If fSCLK = 133 MHz N/fSCLK = 223 / 133 MHz 0.06 sec Default fSCLK = 56 MHz 223 / 56 MHz 0.15 sec

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Timers //// //// Parameters:None //// //// Return:None //// //// Description:This function initialises Timer0 for PWM mode. ////It is used as reference for the 'shift-clock'. ////--------------------------------------------------------------------------//void Init_Timers(void){*pTIMER0_CONFIG= 0x0019;*pTIMER0_PERIOD= 0x00800000;*pTIMER0_WIDTH= 0x00400000;*pTIMER_ENABLE= 0x0001;}TIMER0_WIDTH REGISTER INFO

Veton Kpuska

*Veton Kpuska*Timer-Width RegistersTimer Width Register specifies the duty cycle of the cycle. When Timer Width register is set to Timer Period/2 value the duty cycle is 50%.0x00400000 = 0000 0000 0100 0000 0000 0000 0000 0000 = 222 = 4194304

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Timers //// //// Parameters:None //// //// Return:None //// //// Description:This function initialises Timer0 for PWM mode. ////It is used as reference for the 'shift-clock'. ////--------------------------------------------------------------------------//void Init_Timers(void){*pTIMER0_CONFIG= 0x0019;*pTIMER0_PERIOD= 0x00800000;*pTIMER0_WIDTH= 0x00400000;*pTIMER_ENABLE= 0x0001;}TIMER_ENABLE

Veton Kpuska

*Veton Kpuska*Timer EnableEnabling Timer00x0001 = 0000 0000 0000 0001

Veton Kpuska

External Bus Interface Unit (EBIU) SetupFIO setupTimer setup EBIU setup Flash setupInterrupt configurationEndless loop waiting f or Timer interrupt or Flag interrupt

Veton Kpuska

*Veton Kpuska*External Bus Interface UnitThe EBIU services requests for external memory from theCore or from a DMA channel.

The priority of the requests is determined by the External Bus Controller. The address of the request determines whether the request is serviced by the EBIU SDRAM (synchronous dynamic random access memory) Controller or the EBIU Asynchronous Memory Controller.

The EBIU is clocked by the system clock (SCLK). All synchronous memories interfaced to the processor operate at the SCLK frequency. The ratio between core frequency and SCLK frequency is programmable using a phase-locked loop (PLL) system memory-mapped registers (MMR).

Veton Kpuska

*Veton Kpuska*EBIU Programming ModelThis model is based on system memory-mapped registers used to program the EBIU.

There are six control registers and one status register in the EBIU. They are:

Asynchronous Memory Global Control register (EBIU_AMGCTL)Asynchronous Memory Bank Control 0 register (EBIU_AMBCTL0)Asynchronous Memory Bank Control 1 register (EBIU_AMBCTL1)

SDRAM Memory Global Control register (EBIU_SDGCTL)SDRAM Memory Bank Control register (EBIU_SDBCTL)SDRAM Refresh Rate Control register (EBIU_SDRRC)

SDRAM Control Status register (EBIU_SDSTAT)

Veton Kpuska

*Veton Kpuska*The Asynchronous Memory Interface The asynchronous memory interface allows a glueless interface to a variety of memory and peripheral types. These include SRAM, ROM, EPROM,flash memory, and FPGA/ASIC designs.

Four asynchronous memory regions are supported. Each has a unique memory select associated with it, shown in Table 17-3.

Veton Kpuska

*Veton Kpuska*Asynchronous Memory Bank Address Range

Veton Kpuska

*Veton Kpuska*EBIU_AMGCTL RegisterThe Asynchronous Memory Global Control register (EBIU_AMGCTL) configures global aspects of the controller.

The EBIU_AMGCTL register should be the last control register written to when configuring the processor to access external memory-mapped asynchronous devices.

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_EBIU //// //// Parameters:None //// //// Return:None //// //// Description:This function initializes and enables the asynchronous ////memory banks for the External Bus Interface Unit (EBIU), so ////that access to Flash A is possible. ////--------------------------------------------------------------------------//void Init_EBIU(void){*pEBIU_AMBCTL0= 0x7bb07bb0;*pEBIU_AMBCTL1= 0x7bb07bb0;*pEBIU_AMGCTL= 0x000f;}Asynchronous Memory Global Control Register

Veton Kpuska

*Veton Kpuska*Asynchronous Memory Global Control Register EBIU_AMGCTL0x000f = 0000 0000 0000 1111

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_EBIU //// //// Parameters:None //// //// Return:None //// //// Description:This function initializes and enables the asynchronous ////memory banks for the External Bus Interface Unit (EBIU), so ////that access to Flash A is possible. ////--------------------------------------------------------------------------//void Init_EBIU(void){*pEBIU_AMBCTL0= 0x7bb07bb0;*pEBIU_AMBCTL1= 0x7bb07bb0;*pEBIU_AMGCTL= 0x000f;}Asynchronous Memory Control Register

Veton Kpuska

*Veton Kpuska*EBIU_AMBCTL0 and EBIU_AMBCTL1 RegistersThe EBIU asynchronous memory controller has two Asynchronous Memory Bank Control registers:EBIU_AMBCTL0 and EBIU_AMBCTL1. They contain bits for counters for:setup, strobe, and hold time; bits to determine memory type and size; andbits to configure use of ARDY (Asynchronous Memory Ready Response) bit.

Veton Kpuska

*Veton Kpuska*Asynchronous Memory Bank Control 0 Register0x7bb07bb0 = 0111 1011 1011 0000 0111 1011 1011 0000

Veton Kpuska

*Veton Kpuska*External Memory MapThe three SDRAM control registers must be initialized in order to use theMT48LC32M16 64 MB (32M x 16 bits) SDRAM memory of EZ-Kit Lite:EBIU_SDGCTL: SDRAM Memory Global Control register EBIU_SDBCTL: SDRAM Memory Bank Control register EBIU_SDRRC: SDRAM Refresh Rate Control register

The External Memory Map supported by BF533 is provided in the Figure 17-1.

Veton Kpuska

*Veton Kpuska*EBIU_SDGCTL RegisterThe SDRAM Memory Global Control register (EBIU_SDGCTL) includes all programmable parameters associated with the SDRAM access timing and configuration. Figure 17-10 shows the EBIU_SDGCTL register bit definitions.

Veton Kpuska

*Veton Kpuska*SDRAM Memory Global Control register: EBIU_SDGCTL

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_EBIU //// //// Parameters:None //// //// Return:None //// //// Description:This function initializes and enables the asynchronous ////memory banks for the External Bus Interface Unit (EBIU), so ////that access to Flash A is possible. ////--------------------------------------------------------------------------//void Init_EBIU(void){*pEBIU_AMBCTL0= 0x7bb07bb0;*pEBIU_AMBCTL1= 0x7bb07bb0;*pEBIU_AMGCTL= 0x000f;}

Veton Kpuska

Flash SetupFIO setupTimer setup EBIU setup Flash setupInterrupt configurationEndless loop waiting for Timer interrupt or Flag interrupt

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Flash //// //// Parameters:None //// //// Return:None //// //// Description:This function sets the pin direction of Port B in Flash A ////to output. ////The LEDs on the ADSP-BF533 EZ-KIT are connected to Port B. ////--------------------------------------------------------------------------//void Init_Flash(void){*pFlashA_PortB_Dir = 0x3f;}

0x3f = 0011 1111The Direction register controls IO pins direction. This is a 8-bit read-write register.When a bit is 0, a corresponding pin functions as an input. When the bit is 1, a corresponding pin is an output. See Slide #16 for details or EZ-Kit Lite HRM.Direction Configuration

Veton Kpuska

Interrupt ConfigurationFIO setupTimer setup EBIU setup Flash setupInterrupt configurationEndless loop waiting for Timer interrupt or Flag interrupt

Veton Kpuska

Program Sequencer

Veton Kpuska

*Veton Kpuska*Program SequencerControls all program flow

Maintains loopsIncludes zero-overhead loop registersNo cost for wrapping from loop bottom to loop top

Maintains in-program branchingSubroutinesJumpsInterrupts and Exceptions

Veton Kpuska

*Veton Kpuska*Sequencer Related Registers

Veton Kpuska

Event Controller for Interrupts and Exceptions

Veton Kpuska

*Veton Kpuska*Event ControllerThe Event Controller of the processor manages five types of activities or events:EmulationResetNonmaskable interrupts (NMI)ExceptionsInterrupts (11)

Note the word event describes all five types of activities. The Event Controller manages fifteen different events in all: Emulation, Reset, NMI, Exception, and eleven Interrupts.

Veton Kpuska

*Veton Kpuska*Interrupts vs. ExceptionsAn interrupt is an event that changes normal processor instruction flow and is asynchronous to program flow.

In contrast, an exception is a software initiated event whose effects are synchronous to program flow.

The event system is nested and prioritized. Consequently, several service routines may be active at any time, and a low priority event may be pre-empted by one of higher priority.

Veton Kpuska

*Veton Kpuska*Event ControllerThe processor employs a two-level event control mechanism. The processor System Interrupt Controller (SIC) works with The Core Event Controller (CEC) to prioritize and control all system interrupts. The SIC provides mapping between the many peripheral interrupt sources and the prioritized general-purpose interrupt inputs of the core. This mapping is programmable, and individual interrupt sources can be masked in the SIC.

The CEC supports nine (9) general-purpose interrupts (IVG7 IVG15) in addition to the dedicated interrupt and exception events that are described in Table 4-6. It is recommended that the two lowest priority interrupts (IVG14 and IVG15) be reserved for software interrupt handlers, leaving seven prioritized interrupt inputs (IVG7 IVG13) to support the system. Refer to Table 4-6 for details.

Veton Kpuska

*Veton Kpuska*Core Event Mapping

Veton Kpuska

*Veton Kpuska*System Event Mapping

Veton Kpuska

*Veton Kpuska*Processor Event ControllerProcessor Event Controller Consists of 2 stages:The Core Event Controller (CEC)System Interrupt Controller (SIC)

Conceptually:Interrupts from the peripherals arrive at SICSIC routes interrupts directly to general-purpose interrupts of the CEC.

Veton Kpuska

*Veton Kpuska*Core Event Controller (CEC)CEC supports 9 general-purpose interrupts: IVG15-7IVG15-14 (2) lowest priority interrupts for software handlers.IRVG13-7 (7) highest to support peripherals.Additional dedicated interrupt and exception events.

Veton Kpuska

*Veton Kpuska*System Interrupt Controller (SIC)SIC provides mapping and routing of events:From: Peripheral interrupt sourcesTo: Prioritized general-purpose interrupt inputs of the CEC.Note: Processor default mapping can be altered by the user via Interrupt Assignment Register (IAR).

Veton Kpuska

*Veton Kpuska*BF533 System & Core Interrupt ControllersEvent SourceIVG #Core Event NameSystem Interrupt SourceIVG # 1 P r i o r i t yHighestLowest

Emulator0EMUReset1RSTNon Maskable Interrupt2NMIExceptions3EVSWReserved4-Hardware Error5IVHWCore Timer6IVTMRGeneral Purpose 77IVG7General Purpose 88IVG8General Purpose 99IVG9General Purpose 1010IVG10General Purpose 1111IVG11General Purpose 1212IVG12General Purpose 1313IVG13General Purpose 1414IVG14General Purpose 1515IVG15

PLL Wakeup interruptIVG7DMA error (generic)IVG7PPI error interruptIVG7SPORT0 error interruptIVG7SPORT1 error interruptIVG7SPI error interruptIVG7UART error interruptIVG7RTC interruptIVG8DMA 0 interrupt (PPI)IVG8DMA 1 interrupt (SPORT0 RX)IVG9DMA 2 interrupt (SPORT0 TX)IVG9DMA 3 interrupt (SPORT1 RX)IVG9DMA 4 interrupt (SPORT1 TX)IVG9DMA 5 interrupt (SPI)IVG10DMA 6 interrupt (UART RX)IVG10DMA 7 interrupt (UART TX)IVG10Timer0 interruptIVG11Timer1 interruptIVG11Timer2 interruptIVG11PF interrupt AIVG12PF interrupt BIVG12DMA 8/9 interrupt (MemDMA0)IVG13DMA 10/11 interrupt (MemDMA1)IVG13Watchdog Timer InterruptIVG13

Veton Kpuska

*Veton Kpuska*System Interrupt ProcessingReferring to Figure 4-5, note when an interrupt (Interrupt A) is generated by an interrupt-enabled peripheral:

SIC_ISR logs the request and keeps track of system interrupts that are asserted but not yet serviced (that is, an interrupt service routine hasnt yet cleared the interrupt).

SIC_IWR checks to see if it should wake up the core from an idled state based on this interrupt request.

SIC_IMASK masks off or enables interrupts from peripherals at the system level. If Interrupt A is not masked, the request proceeds to Step 4.

The SIC_IARx registers, which map the peripheral interrupts to a smaller set of general-purpose core interrupts (IVG7 IVG15), determine the core priority of Interrupt A.

Veton Kpuska

*Veton Kpuska*System Interrupt Processing (cont.)ILAT adds Interrupt A to its log of interrupts latched by the core but not yet actively being serviced.

IMASK masks off or enables events of different core priorities. If the IVGx event corresponding to Interrupt A is not masked, the process proceeds to Step 7.

The Event Vector Table (EVT) is accessed to look up the appropriate vector for Interrupt As interrupt service routine (ISR).

When the event vector for Interrupt A has entered the core pipeline, the appropriate IPEND bit is set, which clears the respective ILAT bit. Thus, IPEND tracks all pending interrupts, as well as those being presently serviced.

When the interrupt service routine (ISR) for Interrupt A has been executed, the RTI instruction clears the appropriate IPEND bit. However, the relevant SIC_ISR bit is not cleared unless the interrupt service routine clears the mechanism that generated Interrupt A, or if the process of servicing the interrupt clears this bit.

Veton Kpuska

*Veton Kpuska*Interrupt Processing Block DiagramSIC_ISR logs the request and keeps track of system interrupts that are asserted but not yet serviced (that is, an interrupt service routine hasnt yet cleared the interrupt).SIC_IWR checks to see if it should wake up the core from an idled state based on this interrupt request.SIC_IMASK masks off or enables interrupts from peripherals at the system level. If Interrupt A is not masked, the request proceeds to Step 4.The SIC_IARx registers, which map the peripheral interrupts to a smaller set of general-purpose core interrupts (IVG7 IVG15), determine the core priority of Interrupt A.ILAT adds Interrupt A to its log of interrupts latched by the core but not yet actively being serviced. IMASK masks off or enables events of different core priorities. If the IVGx event corresponding to Interrupt A is not masked, the process proceeds to Step 7.The Event Vector Table (EVT) is accessed to look up the appropriate vector for Interrupt As interrupt service routine (ISR).When the event vector for Interrupt A has entered the core pipeline, the appropriate IPEND bit is set, which clears the respective ILAT bit. Thus, IPEND tracks all pending interrupts, as well as those being presently serviced.When the interrupt service routine (ISR) for Interrupt A has been executed, the RTI instruction clears the appropriate IPEND bit. However, the relevant SIC_ISR bit is not cleared unless the interrupt service routine clears the mechanism that generated Interrupt A, or if the process of servicing the interrupt clears this bit.It should be noted that emulation, reset, NMI, and exception events, as well as hardware error (IVHW) and core timer (IVTMR) interrupt requests, enter the interrupt processing chain at the ILAT level and are not affected by the system-level interrupt registers (SIC_IWR, SIC_ISR, SIC_IMASK, SIC_IARx).

Veton Kpuska

*Veton Kpuska*Interrupt Service RoutineISR address is stored in the Event Vector TableUsed as the next fetch address when the event occursProgram Counter (PC) address is saved to a registerRETI, RETX, RETN, RETE, based on eventISR always concludes with Return InstructionRTI, RTX, RTN, RTE (respectively)When executed, PC is loaded with address stored in RETI, RETX, RETN, or RETE to continue app code Optional nesting of higher-priority interrupts possibleSee app. note EE-192, which covers writing interrupt routines in C (http://www.analog.com/ee-notes)

Veton Kpuska

*Veton Kpuska*System Peripheral InterruptsThe processor system has numerous peripherals, which therefore require many supporting interrupts. Table 4-7 lists:The Peripheral Interrupt sourceThe Peripheral Interrupt ID used in the System Interrupt Assignment registers (SIC_IARx). See System Interrupt Assignment Registers (SIC_IARx) on page 4-30 of BF533 HRM.The general-purpose interrupt of the core to which the interrupt maps at resetThe Core Interrupt ID used in the System Interrupt Assignment registers (SIC_IARx). See System Interrupt Assignment Registers (SIC_IARx) on page 4-30 of BF533 HRM.

Veton Kpuska

*Veton Kpuska*Peripheral Interrupt Source at Reset State

Veton Kpuska

*Veton Kpuska*Peripheral Interrupt Source at Reset State

Veton Kpuska

*Veton Kpuska*Initialization of InterruptsIf the default assignments shown in Table 4-7 are acceptable, then interrupt initialization involves only:

Initialization of the core Event Vector Table (EVT) vector address entries. Why is this needed?Initialization of the IMASK registerUnmasking the specific peripheral interrupts in SIC_IMASK that the system requires

Veton Kpuska

*Veton Kpuska*Initialization of Core Vector TableThe Event Vector Table (EVT) is a hardware table with sixteen entries that are each 32 bits wide.

The EVT contains an entry for each possible core event. Entries are accessed as MMRs, and Each entry can be programmed at reset with the corresponding vector address for the interrupt service routine. When an event occurs, instruction fetch starts at the address location in the EVT entry for that event. The processor architecture allows unique addresses to be programmed into each of the interrupt vectors; that is, interrupt vectors are not determined by a fixed offset from an interrupt vector table base address. This approach minimizes latency by not requiring a long jump from the vector table to the actual ISR code.

Table 4-9 lists events by priority. Each event has a corresponding bit in the event state registers: ILAT, IMASK, and IPEND.

Veton Kpuska

*Veton Kpuska*Core Event Vector Table

Veton Kpuska

*Veton Kpuska*Core Event Vector Table

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Interrupts //// //// Parameters:None //// //// Return:None //// //// Description: This function initializes the interrupts for Timer0 and ////FlagA (PF8). ////--------------------------------------------------------------------------//void Init_Interrupts(void){// assign core IDs to interrupts*pSIC_IAR0 = 0xffffffff;*pSIC_IAR1 = 0xffffffff;*pSIC_IAR2 = 0xffff5ff4; // Timer0 -> ID4; FlagA -> ID5

// assign ISRs to interrupt vectorsregister_handler(ik_ivg11, Timer0_ISR); // Timer0 ISR -> IVG 11register_handler(ik_ivg12, FlagA_ISR); // FlagA ISR -> IVG 12

// enable Timer0 and FlagA interrupt*pSIC_IMASK = 0x00090000;}System Interrupt Assignment Register

Veton Kpuska

*Veton Kpuska*System Interrupt Assignment Registers (SIC_IARx)The relative priority of peripheral interrupts can be set by mapping the peripheral interrupt to the appropriate general-purpose interrupt level in the core. The mapping is controlled by the System Interrupt Assignment register settings, as detailed in Figure 4-9, Figure 4-10, and Figure 4-11. If more than one interrupt source is mapped to the same interrupt, they are logically OR-ed, with no hardware prioritization. Software can prioritize the interrupt processing as required for a particular system application.

Veton Kpuska

*Veton Kpuska*Mapping of Values in SIC_IARx Register to General Purpose InterruptTable 4-8 defines the value to write in SIC_IARx to configure a peripheral for a particular IVG priority.

Veton Kpuska

*Veton Kpuska*System Interrupt Assignment Register0xffffffff = 1111 1111 1111 1111 1111 1111 1111 1111

Veton Kpuska

*Veton Kpuska*System Interrupt Assignment Register0xffffffff = 1111 1111 1111 1111 1111 1111 1111 1111

Veton Kpuska

*Veton Kpuska*System Interrupt Assignment Register0xffff5ff4 = 1111 1111 1111 1111 0101 1111 1111 0100PF A InterruptTimer 0 Interrupt

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Interrupts //// //// Parameters:None //// //// Return:None //// //// Description: This function initializes the interrupts for Timer0 and ////FlagA (PF8). ////--------------------------------------------------------------------------//void Init_Interrupts(void){// assign core IDs to interrupts*pSIC_IAR0 = 0xffffffff;*pSIC_IAR1 = 0xffffffff;*pSIC_IAR2 = 0xffff5ff4; // Timer0 -> ID4; FlagA -> ID5

// assign ISRs to interrupt vectorsregister_handler(ik_ivg11, Timer0_ISR); // Timer0 ISR -> IVG 11register_handler(ik_ivg12, FlagA_ISR); // FlagA ISR -> IVG 12

// enable Timer0 and FlagA interrupt*pSIC_IMASK = 0x00090000;}See Table for Peripheral Interrupt Source at Reset

Veton Kpuska

*Veton Kpuska*Interrupt Handler SupportThe Blackfin C/C++ compiler provides support for interrupts and other events used by the Blackfin processor architecture (see Table 1-25 of VisualDSP++ 4.5 C/C++ Compiler and Library Manual for Blackfin Processors).

The Blackfin system has several different classes of events, not all of which are supported by the ccblkfn compiler. Handlers for these events are called Interrupt Service Routines (ISRs).

The compiler provides facilities for defining an ISR function, registering it as an event handler, and for obtaining the saved processor context.

Veton Kpuska

*Veton Kpuska*Defining an ISRTo define a function as an ISR, the sys/exception.h header must be included and the function must be declared and defined using macros defined within this header file. Where is this file included in the LED Lab #1 example?

There is a macro for each of the three kinds of events the compiler supports:EX_INTERRUPT_HANDLEREX_EXCEPTION_HANDLEREX_NMI_HANDLER Which macro was used in Lab #1 exercise?

By default, the ISRs generated by the compiler are not re-entrant; they disable the interrupt system on entry, and re-enable it on exit. You may also define ISRs for interrupts which are re-entrant, and which re-enable the interrupt system soon after entering the ISR.

Veton Kpuska

*Veton Kpuska*Example#include static int number_of_interrupts;EX_INTERRUPT_HANDLER(my_isr){number_of_interrupts++;}

This example declares and defines my_isr() as a handler for interrupt-type events.

The macro used for defining the ISR is also suitable for declaring it as a prototype:EX_INTERRUPT_HANDLER(my_isr);

Veton Kpuska

*Veton Kpuska*Registering an ISRISRs, once defined, can be registered in the Event Vector Table (EVT) using the register_handler_ex() function or the register_handler() function, both of which also update the IMASK register so that interrupt can take effect. Only the register_handler_ex() function will be discussed here, as it is an extended version of the register_handler() function. Refer to register_handler_ex on page 3-236 of VisualDSP++ 4.5 C/C++ Compiler and Library Manual for Blackfin Processors for more information about it.

The register_handler_ex() function takes three parameters, defining the event, the ISR, and whether the interrupt should be enabled, disabled, or left in its current state. It also returns the previously registered ISR (if any). The event is specified using the interrupt_kind enumeration from exception.h.

Veton Kpuska

*Veton Kpuska*Registering an ISRtypedef enum {ik_emulation, ik_reset, ik_nmi, ik_exception,ik_global_int_enable, ik_hardware_err, ik_timer,ik_ivg7,ik_ivg8,ik_ivg9, ik_ivg10, ik_ivg11, ik_ivg12, ik_ivg13,ik_ivg14, ik_ivg15} interrupt_kind;

ex_handler_fn register_handler_ex(interrupt_kind kind,ex_handler_fn fn, int enable);

Which enumeration types were used in the LAB # exercise?

Veton Kpuska

*Veton Kpuska*register_handlerRegister event handlers

Synopsis#include ex_handler_fn register_handler (interrupt_kind kind, ex_handler_fn fn);

Description

The register_handler function determines how the hardware event kind is handled. This is done by registering the function pointed to by fn as a handler for the event and updating the IMASK register so that interrupt can take effect.

The kind event is an enumeration identifying each of the hardware eventsinterrupts and exceptionsaccepted by the Blackfin processor.

Note: The register_handler_ex function provides an extended and more functional interface than register_handler.

For the values for kind, refer to Registering an ISR on page 1-251 of VisualDSP++ 4.5 C/C++ Compiler and Library Manual for Blackfin Processors presented also in the previous slide.

The fn must be one of the values are listed in the table in the next slide.

Veton Kpuska

*Veton Kpuska*Table of fn valuesWhich function value was used in the Lab #1 exercise?

Veton Kpuska

*Veton Kpuska*Initialization.c//--------------------------------------------------------------------------//// Function:Init_Interrupts //// //// Parameters:None //// //// Return:None //// //// Description: This function initializes the interrupts for Timer0 and ////FlagA (PF8). ////--------------------------------------------------------------------------//void Init_Interrupts(void){// assign core IDs to interrupts*pSIC_IAR0 = 0xffffffff;*pSIC_IAR1 = 0xffffffff;*pSIC_IAR2 = 0xffff5ff4; // Timer0 -> ID4; FlagA -> ID5

// assign ISRs to interrupt vectorsregister_handler(ik_ivg11, Timer0_ISR); // Timer0 ISR -> IVG 11register_handler(ik_ivg12, FlagA_ISR); // FlagA ISR -> IVG 12

// enable Timer0 and FlagA interrupt*pSIC_IMASK = 0x00090000;}Unmasking of the Interrupt by setting corresponding bits in SIC_IMASK register.

Veton Kpuska

*Veton Kpuska*SIC_IMASK RegisterThe System Interrupt Mask register (SIC_IMASK, shown in Figure 4-8 Blacfin BF533 HRM) allows masking of any peripheral interrupt source at the System Interrupt Controller (SIC), independently of whether it is enabled at the peripheral itself.

A reset forces the contents of SIC_IMASK to all 0s to mask off all peripheral interrupts. Writing a 1 to a bit location turns off the mask and enables the interrupt.

Although this register can be read from or written to at any time (in Supervisor mode), it should be configured in the reset initialization sequence before enabling interrupts.

Veton Kpuska

*Veton Kpuska*SIC_IMASK Register 0x00090000 = 0000 0000 0000 1001 0000 0000 0000 0000Timer 0 InterruptPF Interrupt A

Veton Kpuska

Servicing Interrupts

Veton Kpuska

*Veton Kpuska*ISR.c: ISR for Timer0#include "BF533 Flags.h"

//--------------------------------------------------------------------------//// Function:Timer0_I //// //// Parameters:None //// //// Return:None //// //// Description: This ISR is executed every time Timer0 expires. //// The old LED pattern is shifted by one; the direction //// depends on the state of sLight_Move_Direction, which is //// changed in FlagA_ISR. ////--------------------------------------------------------------------------//EX_INTERRUPT_HANDLER(Timer0_ISR){static unsigned char ucActive_LED = 0x01;

// confirm interrupt handling*pTIMER_STATUS = 0x0001;

// shift old LED pattern by oneif(sLight_Move_Direction){if((ucActive_LED = ucActive_LED >> 1) == 0x00) ucActive_LED = 0x20;}else{if((ucActive_LED = ucActive_LED

*Veton Kpuska*Timer Status RegisterIn the discussion about the BF533 Timers it was mentioned that the following three registers are shared between the three timers:TIMER_ENABLE[15:0] Timer Enable registerTIMER_DISABLE[15:0] Timer Disable registerTIMER_STATUS[15:0] Timer Status register

Veton Kpuska

*Veton Kpuska*Timer Status RegisterThe Timer Status register (TIMER_STATUS) indicates the status of all three timers and is used to check the status of all three timers with a single read. Status bits are sticky and write-1-to-clear (W1C). The TRUNx bits can clear themselves, which they do when a PWM_OUT mode timer stops at the end of a period.During a Status Register read access, all reserved or unused bits return a 0.

Each Timer generates a unique interrupt request signal, which is gated by the corresponding IRQ_ENA bit in the TIMERx_CONFIG register. The shared Timer Status register (TIMER_STATUS) latches these interrupts so the user can determine the interrupt source without reference to the unique interrupt signal (for example, in the case where all three timers have been assigned to the same interrupt priority). Interrupt bits are sticky and must be cleared by the interrupt service routine (ISR) to assure that the interrupt is not reissued.

The TIMILx bits work along with the IRQ_ENA bit of the Timer Configuration register to indicate interrupt requests. If an interrupt condition or error occurs and IRQ_ENA is set, then the TIMILx bit is set and the interrupt to the core is asserted. This interrupt may be masked by the system interrupt controller. If an interrupt condition or error occurs and IRQ_ENA is cleared, then the TIMILx bit is not set and the interrupt is not asserted. If TIMILx is already set and IRQ_ENA is written to 0, TIMILx stays set and the interrupt stays asserted. (See Figure 15-24 on page 15-39 of the manual).

(ADSP-BF533 Blackfin Processor Hardware Reference: 15-7 Timers)

Veton Kpuska

*Veton Kpuska*Timer Status RegisterThe read value of the TRUNx bits reflects the timer slave enable status in all modes:TRUNx set indicates running and TRUNx cleared indicates stopped.While reading the TIMENx or TIMDISx bits in the TIMER_ENABLE and TIMER_DISABLE registers will reflect whether a timer is enabled, the TRUNx bits indicate whether the timer is actually running. In WDTH_CAP and EXT_CLK modes, reads from TIMENx and TRUNx always return the same value.A write-1-to clear W1C operation to the TIMER_DISABLE register disables the corresponding timer in all modes. In PWM_OUT mode, a disabled timer continues running until the ongoing period (PERIOD_CNT = 1) or pulse (PERIOD_CNT = 0) completes. During this final period the TIMENx bit returns 0, but the TRUNx bit still reads as a 1. (See Figure 15-10 on page 15-14 of the manual). In this state only, TRUNx becomes a write-1-to clear W1C bit. During this final period with the timer disabled, writing a 1 to TRUNx clears TRUNx and stops the timer immediately without waiting for the timer counter to reach the end of its current cycle.Writing the TRUNx bits has no effect in other modes or when a timer has not been enabled. Writing the TRUNx bits to 1 in PWM_OUT mode has no effect on a timer that has not first been disabled.

Veton Kpuska

*Veton Kpuska*Timer Status Register (TIMER_STATUS)0x0001 = 0000 0000 0000 0001

Veton Kpuska

*Veton Kpuska*ISR.c: ISR for Timer0#include "BF533 Flags.h"

//--------------------------------------------------------------------------//// Function:Timer0_I //// //// Parameters:None //// //// Return:None //// //// Description: This ISR is executed every time Timer0 expires. //// The old LED pattern is shifted by one; the direction //// depends on the state of sLight_Move_Direction, which is //// changed in FlagA_ISR. ////--------------------------------------------------------------------------//EX_INTERRUPT_HANDLER(Timer0_ISR){static unsigned char ucActive_LED = 0x01;

// confirm interrupt handling*pTIMER_STATUS = 0x0001;

// shift old LED pattern by oneif(sLight_Move_Direction){if((ucActive_LED = ucActive_LED >> 1) == 0x00) ucActive_LED = 0x20;}else{if((ucActive_LED = ucActive_LED > 1 = 0000 0001 >> 1 0x00 = 0000 0000 0x20 = 0010 0000 0x01

*Veton Kpuska*ISR.c: ISR for Push-Buttons//--------------------------------------------------------------------------//// Function:FlagA_ISR //// //// Parameters:None //// //// Return:None //// //// Description: This ISR is called every time the button connected to PF8//// is pressed.//// The state of flag sLight_Move_Direction is changed, so the//// shift-direction for the LED pattern in Timer0_ISR changes.////--------------------------------------------------------------------------//EX_INTERRUPT_HANDLER(FlagA_ISR){// confirm interrupt handling*pFIO_FLAG_C = 0x0100;

// toggle direction of moving lightsLight_Move_Direction = ~sLight_Move_Direction;}

Veton Kpuska

*Veton Kpuska*FIO_FLAG_S, FIO_FLAG_C, and FIO_FLAG_T RegistersAs discussed in FIO Set-up section, the Flag Set register (FIO_FLAG_S), Flag Clear register (FIO_FLAG_C), and Flag Toggle register (FIO_FLAG_T) are used to:Set, clear or toggle the output state associated with each output PFx pinClear the latched interrupt state captured from each input PFx pin

Veton Kpuska

*Veton Kpuska*FIO_FLAG_C Register0x0100 = 0000 0001 0000 0000

Veton Kpuska

*Veton Kpuska*ISR.c: ISR for Push-Buttons//--------------------------------------------------------------------------//// Function:FlagA_ISR //// //// Parameters:None //// //// Return:None //// //// Description: This ISR is called every time the button connected to PF8//// is pressed.//// The state of flag sLight_Move_Direction is changed, so the//// shift-direction for the LED pattern in Timer0_ISR changes.////--------------------------------------------------------------------------//EX_INTERRUPT_HANDLER(FlagA_ISR){// confirm interrupt handling*pFIO_FLAG_C = 0x0100;

// toggle direction of moving lightsLight_Move_Direction = ~sLight_Move_Direction;}

0x0100 = 0000 0001 0000 0000Toggle direction flag.

Veton Kpuska

*Veton Kpuska*Blackfin Home Page:http://www.analog.com/processors/processors/blackfin/Blackfin Development Toolshttp://www.analog.com/processors/processors/blackfin/crosscore/index.htmlTechnical Libraryhttp://www.analog.com/processors/Resources/technicalLibrary/index.htmlBlackfin Code Examples http://www.analog.com/processors/processors/blackfin/technicalLibrary/manuals/codeExamples.htmlBlackfin ProcessorFamily Manuals http://www.analog.com/Processors/Processors/blackfin/technicalLibrary/manuals/blackfinIndex.htmlEvaluation Kits & Reference Boards http://www.analog.com/processors/productsDatasheets/evaluationKits.htmlBlackfin Online Learning & Development (BOLD) http://www.demosondemand.com/clients/analogdevices/001/page/uClinux Blackfin User's Communityhttp://www.analog.com/processors/communities/bflinux.htmlhttp://blackfin.uclinux.org/

Veton Kpuska

*Veton Kpuska*Blackfin DSP ManualsProcessor ManualsSoftware ManualsEvaluation Kit ManualsEmulator Manuals

Veton Kpuska

*Veton Kpuska*Core Event Controller RegistersThe Event Controller uses three MMRs to coordinate pending event requests. In each of these MMRs, the 16 lower bits correspond to the 16 event levels (for example, bit 0 corresponds to Emulator mode). The registers are:

IMASK - interrupt maskILAT - interrupt latchIPEND - interrupts pending

These three registers are accessible in Supervisor mode only.

Veton Kpuska

*Veton Kpuska*IMASK RegisterThe Core Interrupt Mask register (IMASK) indicates which interrupt levels are allowed to be taken. The IMASK register may be read and written in Supervisor mode. Bits [15:5] have significance; bits [4:0] are hard-coded to 1 and events of these levels are always enabled.

If IMASK[N] == 1 and ILAT[N] == 1, then interrupt N will be taken if a higher priority is not already recognized. If IMASK[N] == 0, and ILAT[N] gets set by interrupt N, the interrupt will not be taken, and ILAT[N] will remain set.

Veton Kpuska

*Veton Kpuska*Core Interrupt Mask Register

Veton Kpuska

Digital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit ProcessorDigital Systems: Hardware Organization and DesignDigital Systems: Hardware Organization and Design*Architecture of a Respresentative 32 Bit Processor*Architecture of a Respresentative 32 Bit Processor