Embedded System and Embedded Controllers.pptx

ES

1. Current Challenges in Embedded Systems,RTOS AND ARM7 REAL TIME APPLICATIONS

2. DEFINITION OF EMBEDDED SYSTEMS AND DIMENSIONS Over the history, many definitions for embedded systems have been given, however, they are all somewhat different. First study some of the existing definitions. Then we briefly look at the evolution of embedded systems from the introduction of first microprocessors to the future distributed networked embedded systems. Based on earlier definitions and short historical analysis define and characterize modern embedded systems in general. The historical classification of processor architecture generations, or computer generations, is a topic that scientists and researchers easily debate on. Stallings (1996) suggests that there have been five generations of computers.

3. The first three generations of these (vacuum tube computers 1946-1957, transistor circuit computers 1958-1964, integrated circuit (IC) computers 1965-1971) are agreed. According to Stallings, the division between the fourth and fifth generation is not clear, although the generation is suggested to have changed with the shift from large scale Integration (LSI) based circuit technology (1972-1977) to very large scale integration (VLSI) based circuit technology (1978 onwards). Tanenbaum (1999) more or less agrees with the first three generations mentioned above, although he defines the third generation to be the combination of Stallings’ generations 3 and 4 (IC and LSI). Tanenbaum defines the fourth generation to have begun in 1980 in the form of VLSI based computers. In addition, he defines an additional generation, called the zeroth generation for mechanical computers (1642-1945).

4. EVOLUTION OF EMBEDDED SYSTEMS Throughout the history, embedded systems have been designed around a central master processing element. Representing one of the aforementioned generations of computer architecture: starting from microcontrollers in the early age of embedded systems and Reaching multi-processor systems-on-chip (MPSoC) of the current implementations, and in the near future networked MPSoCs as seen in Figure 1. In the 1980s, microcontrollers gained popularity as programmable single-chip and stand-alone systems with very versatile built-in peripherals that provided an integrated solution for many simple controlling tasks. Besides these controlling tasks, during the 1990’s there was an increasing need for much heavier processing.

5. For example, in cellular phones many algorithms were implemented using embedded signal processor cores. Embedded systems were no longer individual microprocessor or microcontroller chips, but merely cheap low-power embedded processor cores that could be integrated into the same chip or package during the end-product manufacturing.

6. In the 2000’s, the emphasis started to move towards much heavier processing with multicore processors and complex field-programmable gate arrays. Incorporating embedded core processors and memories in addition to reconfigurable logic facilities. These platforms accelerated the change from Single Processor System-on-Chips ( SPSoC ) to Multi-Processor System-on-Chips (MPSoC). Mobile systems using MPSoC solutions as the processing platform, and the highly improved communication capacity and access of today are paving the way towards the next step in the evolution of embedded systems: network-connected and network-distributed co-operative embedded systems based on MPSoC processing technology.

7. “An embedded system has one or more programmable processing engines. The engines operate as an independent stand-alone system either in the role of a master or a slave and interact with their environment”. DERIVATION OF CHALLENGES IN EMBEDDED SYSTEMS

8. The implementations of future nanoscale electronic systems can be based either on advanced CMOS-style technologies ranging between 0.1 – 0.05 µm, or completely new, emerging technology approaches. In either case, the strategic issue is scalability towards and beyond gigascale integration in three domains: Architectural and system scalability with respect to complexity, Performance scalability with respect to geometrical scaling in underlying device and circuit structures, and Design effort scalability with respect to increased functionality. Very high-speed access networks approaching gigabit speeds and providing continuous network access provide also a new dimension to system scalability.

9. CHALLENGES The new challenges faced by developers of future complex converged wireless systems can only be met by Adventurous development of technologies and Technological exploration and Experimentation of systems and system design methodologies. Research results from the areas of embedded system design, communication system design, system-wide security and hardware-software co-design need to be brought together to produce multidisciplinary results that converge into novel technologies usable in future secure embedded communication systems.

10. The new challenges of device interoperability, self-awareness and embedded security are a well advised starting point for studying and analysing the changes happening in the design process of embedded systems. Device Interoperability The device interoperability problem can be seen as a very simple and straightforward issue: a system is composed of several subcomponents and they all should work on several platforms. However, it has been a very complicated problem for system designers in embedded and electronic system design already for two decades. HDL based macro libraries and synthesis tools made technology independence a very important topic in hardware design in the early 1990’s.

11. In networked embedded systems the components can be distributed to separate nodes (independent networked devices) within a multi-standard communication infrastructure. Self-Aware Autonomous Agent Based Systems A self-aware system is monitoring its environment and its own state in order to optimize and match its functions to each situation. The key aspects of a self-aware system are presented in Figure 2.

12. A system needs to monitor the state and the operation of its neighbouring systems, the condition of its own hardware and the applications running on it. Based on monitored information and objective functions given, it supervises the processing and the execution of the application. Key objective functions for today’s embedded systems can be seen as dependability, ecology and scalability. Dependability means that the system should work in a robust manner under possible hardware or software errors before, during and after reconfiguration, system and platform changes. Ecology means concepts like power consumption, product life-time and R&D costs. Power consumption minimization is mostly finding the most power efficient implementation for each particular phase of operation, dynamic system or subsystem shutdowns and dynamically optimized communication patterns.

13. EMBEDDED SECURITY System and communication security is in the heart of the trends of having the ability to connect a single device to multiple networks. That differ significantly from each other and on the other hand having small hand-held devices that automatically try to establish network connections whenever they detect a network service is available. The third dimension to embedded security challenges for future devices is protection of the on-board data transfer system from attacks. VERIFICATION AND MODELING In order to match the challenges described in the previous sections it is essential to study them in more detail in relation to practical system design aspects. The target in self-awareness design is to build into the system the ability to optimize and match its functionality dynamically to each situation. In practice this means that self-design principles need to be adopted. The self-design approach is presented in Figure 3.

14. Verification of modern embedded communication systems is a tedious task. The verification gap, i.e. the gap between design capacity (functional complexity) and ability to verify, is getting larger and larger. The more parallel and heterogeneous the system is the more difficult the verification process becomes. Traditional simulation based verification methods rely on stimulus sets which exercise the functionality of a system model at different abstraction levels of interest.

15. To reach an acceptable simulation (or test) coverage for a complex embedded system with a very large number of possible behavioural scenarios. A vast number of possible individual system states is a cumbersome process, taking much more time than the actual design phases. Physical analysis of mutual effects

16. Physical design issues, like cross-talk noise in communication links, clocking structures, power distribution networks and Their noise, and technological variations in wires and components have been thoroughly studied during the last twenty years ( Bakoglu , 1990; Zheng et al. 2001). The vital issues are their mutual and accumulated effects, which are still mostly unknown issues (Figure 4). Only some preliminary studies have been published so far (for example Tuuna , Nigussie et al., 2008; Tuuna , Zheng et al., 2008). As the number of critical parameters needed in physical analyses is increasing heavily, the models are changing towards analytical and system level models. As technological tolerances and their impact on system functionality and performance seem to increase, the self-design approach is almost a necessity to make systems function as specified from the very beginning. This includes moving from the fully synchronous domain towards asynchronous, self-timed operations, which makes system testing and verification a more time-consuming task. In the link level, adjustable drivers and techniques need to be used.

17. SYSTEM IMPLEMENTATION PLATFORM In embedded system design, the second key area to be dealt with is the system implementation platform including the firmware controlling the hardware. There the focus is the firmware layer added above the current embedded networks-on-chip (NoC) platform layer as presented in Figure 5.

18. AN AGENT ABSTRACTION WITHIN A PLATFORM

19. In general, an agent function together with an application function forms the component abstraction that interacts with the underlying IC environment through simple diagnostic and control devices and circuits. Self-awareness and the related models and monitoring techniques are the most critical issue in the process. In our case, this model includes a mechanism for adding dynamic reconfigurability properties to application abstraction, and further includes technology platform-level information for the physical refinement process. After initial design of the system, reconfiguration is needed for three purposes: capacity enhancement of system, fault-tolerance and possible online changes (system upgrades) in specification. Autonomous behaviour will be created by combining the control abstraction and reconfigurability capacity to handle the dynamic behaviour (for example, robustness towards faults) and performance optimization (for example, load balancing).

20. BASIC REAL-TIME CONCEPTS TERMINOLOGY The fundamental definitions of real-time systems engineering can vary depending on the resource consulted. The following definitions have been collected and refined to the smallest common subset of agreement to form the vocabulary of this text. Moreover, these definitions are presented in a form that is intended to be most useful to the practicing engineer, as opposed to the theorist Systems Concepts The hardware of the general-purpose computer solves problems by repeated execution of macroinstructions, collectively known as software. Software is traditionally divided into system programs and application programs

21. Application programs are programs written to solve specific problems, such as payroll preparation, inventory, and navigation. Certain design considerations play a role in the design of certain systems programs and application software intended to run in real-time environments. The notion of a “system” is central to software engineering, and indeed to all engineering, and warrants formalization

22. TypicalReal-timecontrolsystemincludinginputsfromsensorsandimagingdevices and producing control signals and display information.

23. A classic representation of a real-time system as a sequence of jobs to be scheduled. Definition: The time between the presentation of a set of inputs to a system (stimulus) and the realization of the required behavior (response), including the availability of all associated outputs, is called the response time of the system.

24. Real-Time Definitions The previous definitions set the stage for a formal definition of a real-time system. Definition: A real-time system is a system that must satisfy explicit (bounded) response-time constraints or risk severe consequences, including failure Definition: A failed system is a system that cannot satisfy one or more of the requirements stipulated in the formal system specification. Definition: A real-time system is one whose logical correctness is based on both the correctness of the outputs and their timeliness .

25. REAL-TIME SYSTEM DESIGN ISSUES Real-time systems are a complex subdiscipline of computer systems engineering that is strongly influenced by control theory, software engineering, and operations research (via scheduling theory). Figure 1 depicts just some of the disciplines of computer science and electrical engineering that affect the design and analysis of real-time systems. Thus, because real-time systems engineering is so multidisciplinary, it stands out as a highly specialized area. The design and implementation of real-time systems requires attention to numerous problems. These include: The selection of hardware and software, and evaluation of the trade-off needed for a cost-effective solution, including dealing with distributed computing systems and the issues of parallelism and synchronization

26. . Disciplines that impact on real-time systems engineering

27. EXAMPLE REAL-TIME SYSTEMS

28. COMMON MISCONCEPTIONS As a part of truly understanding the nature of real-time systems, it is important to address a number of frequently cited misconceptions. These are summarized as follows: Real-time systems are synonymous with “fast” systems. Rate-monotonic analysis has solved “the real-time problem.” 3. There are universal, widely accepted methodologies for real-time systems specification and design. 4. There is never a need to build a real-time operating system, because many commercial products exist. 5. The study of real-time systems is mostly about scheduling theory.

29. Commercial Operating System Support The first commercial operating systems were designed for mainframe computers. IBM developed the first real-time executive. its Basic Executive in 1962, which provided diverse real-time scheduling. By 1963, its Basic Executive II had disk resident user/systems programs. By the mid 1970s more affordable minicomputer systems could be found in many engineering environments. In response, a number of important real-time operating systems were developed by the minicomputer manufacturers. Notable among these were the Digital Equipment Corporation (DEC) family of real-time multitasking executives (RSX) for the PDP-11 and Hewlett-Packard’s Real-Time Executive (RTE) series of operating systems for its HP 2000 series.

30. By the late 1970s and early 1980s, the first operating systems for microprocessor-based systems appeared. These included RMX-80, MROS 68K, VRTX, and several others. Over the last 20 years many real-time operating systems have appeared and many have disappeared. A summary of some of the landmark events in the field of real-time systems in the United States is given in Table

31. ARM7 REAL TIME APPLICATIONS AT91 ARM® Thumb®-based Microcontrollers AT91SAM7S256 Atmel’s AT91SAM7S256 is a member of a series of low pincount Flash microcontrollers based on the 32-bit ARM RISC processor. It features a 256 Kbyte high-speed Flash and a 64 Kbyte SRAM, a large set of peripherals, including a USB 2.0 device. A complete set of system functions minimizing the number of external components. The device is an ideal migration path for 8-bit microcontroller users looking for additional performance and extended memory. The embedded Flash memory can be programmed in-system via the JTAG-ICE interface or via a parallel interface on a production programmer prior to mounting.

32. Built-in lock bits and a security bit protect the firmware from accidental overwrite and preserves its confidentiality. The AT91SAM7S256 system controller includes a reset controller capable of managing the power-on sequence of the microcontroller and the complete system. Correct device operation can be monitored by a built-in brownout detector and a watchdog running off an integrated RC oscillator. The AT91SAM7S256 is a general-purpose microcontroller. Its integrated USB Device port makes it an ideal device for peripheral applications requiring connectivity to a PC or cellular phone. Its aggressive price point and high level of integration pushes its scope of use far into the cost-sensitive, high-volume consumer market.

33. FEATURES • Incorporates the ARM7TDMI® ARM® Thumb® Processor – High-performance 32-bit RISC Architecture – High-density 16-bit Instruction Set – Leader in MIPS/Watt – Embedded ICE In-circuit Emulation, Debug Communication Channel Support • 256 Kbytes of Internal High-speed Flash, Organized in 1024 Pages of 256 Bytes – Single Cycle Access at Up to 30 MHz in Worst Case Conditions – Prefetch Buffer Optimizing Thumb Instruction Execution at Maximum Speed – Page Programming Time: 4 ms, Including Page Auto-erase, Full Erase Time: 10 ms – 10,000 Write Cycles, 10-year Data Retention Capability, Sector Lock Capabilities, Flash Security Bit – Fast Flash Programming Interface for High Volume

34. Production • 64 Kbytes of Internal High-speed SRAM, Single-cycle Access at Maximum Speed • Memory Controller (MC) – Embedded Flash Controller, Abort Status and Misalignment Detection • Reset Controller (RSTC) – Based on Power-on Reset and Low-power Factory-calibrated Brown-out Detector – Provides External Reset Signal Shaping and Reset Source Status • Clock Generator (CKGR) – Low-power RC Oscillator, 3 to 20 MHz On-chip Oscillator and one PLL • Power Management Controller (PMC) – Software Power Optimization Capabilities, Including Slow Clock Mode (Down to 500 Hz) and Idle Mode – Three Programmable External Clock Signals • Advanced Interrupt Controller (AIC) – Individually Maskable , Eight-level Priority, Vectored Interrupt Sources – Two External Interrupt Sources and One Fast Interrupt Source, Spurious Interrupt Protected • Debug Unit (DBGU) – 2-wire UART and Support for Debug Communication Channel interrupt,

35. Programmable ICE Access Prevention • Periodic Interval Timer (PIT) – 20-bit Programmable Counter plus 12-bit Interval Counter • Windowed Watchdog (WDT) – 12-bit key-protected Programmable Counter – Provides Reset or Interrupt Signals to the System – Counter May Be Stopped While the Processor is in Debug State or in Idle Mode • Real-time Timer (RTT) – 32-bit Free-running Counter with Alarm – Runs Off the Internal RC Oscillator • One Parallel Input/Output Controller (PIOA) – Thirty-two Programmable I/O Lines Multiplexed with up to Two Peripheral I/Os – Input Change Interrupt Capability on Each I/O Line – Individually Programmable Open-drain, Pull-up resistor and Synchronous Output • Eleven Peripheral DMA Controller (PDC) Channels • One USB 2.0 Full Speed (12 Mbits per second) Device Port – On-chip Transceiver, 328-byte Configurable Integrated FIFOs

36. Processor and Architecture ARM7TDMI Processor • RISC processor based on ARMv4T Von Neumann architecture – Runs at up to 55 MHz, providing 0.9 MIPS/MHz • Two instruction sets – ARM® high-performance 32-bit instruction set – Thumb® high code density 16-bit instruction set • Three-stage pipeline architecture – Instruction Fetch (F) – Instruction Decode (D) – Execute (E) Debug and Test Features • Integrated embedded in-circuit emulator – Two watchpoint units – Test access port accessible through a JTAG protocol – Debug communication channel • Debug Unit – Two-pin UART

37. – Debug communication channel interrupt handling – Chip ID Register • IEEE1149.1 JTAG Boundary-scan on all digital pins Memory Controller • Bus Arbiter – Handles requests from the ARM7TDMI and the Peripheral DMA Controller • Address decoder provides selection signals for – Three internal 1 Mbyte memory areas – One 256 Mbyte embedded peripheral area • Abort Status Registers – Source, Type and all parameters of the access leading to an abort are saved – Facilitates debug by detection of bad pointers • Misalignment Detector – Alignment checking of all data accesses – Abort generation in case of misalignment

38. • Remap Command – Remaps the SRAM in place of the embedded non-volatile memory – Allows handling of dynamic exception vectors • Embedded Flash Controller – Embedded Flash interface, up to three programmable wait states – Prefetch buffer, bufferizing and anticipating the 16-bit requests, reducing the required wait states – Key-protected program, erase and lock/unlock sequencer – Single command for erasing, programming and locking operations – Interrupt generation in case of forbidden operation

39. Peripheral DMA Controller • Handles data transfer between peripherals and memories • Eleven channels – Two for each USART – Two for the Debug Unit – Two for the Serial Synchronous Controller – Two for the Serial Peripheral Interface – One for the Analog-to-digital Converter • Low bus arbitration overhead – One Master Clock cycle needed for a transfer from memory to peripheral – Two Master Clock cycles needed for a transfer from peripheral to memory • Next Pointer management for reducing interrupt latency requirements

40. Memory • 256 Kbytes of Flash Memory – 1024 pages of 256 bytes – Fast access time, 30 MHz single-cycle access in worst case conditions – Page programming time: 4 ms, including page auto-erase – Page programming without auto-erase: 2 ms – Full chip erase time: 10 ms – 10,000 write cycles, 10-year data retention capability – 16 lock bits, each protecting 16 sectors of 64 pages – Protection Mode to secure contents of the Flash • 64 Kbytes of Fast SRAM – Single-cycle access at full speed

41. Introduction to ARM7 Programming

42. ABITEC’s APPLICATIONS BOARD Is designed to provide the student with a vehicle to attain the skills required to develop systems which respond to ‘real time’ events. This is achieved by providing a cross section of input /output devices on a single compact board that can be interfaced to various controlling systems via a single 40 pin IDC connector. System Facilities The applications board has the following facilities: • Eight large LED array. • Eight-slider switch array. • Two Dual seven segment displays. • DC Motor & control. The motor is equipped with a three-blade propeller which interrupts an IR LED and sensor, the output of which is converted to a digital signal and is readable on one of the outputs from the applications board. • Semiconductor temperature sensor.

43. • Heater control circuit. The heater is in contact with the temperature sensor and the motor propeller can be made to pass air over them causing a cooling effect. • A standard telephone type 3 x 4 matrix keypad. • Fibre Optic transmitter and receiver. • An 8-bit Digital to Analogue Converter (DAC) and comparator to enable the programming of Analogue to Digital Converter (ADC) functions Slider potentiometer providing a variable analogue voltage. • Speaker driven either form a digital signal or from the output of the DAC. The following options are also available: • LCD interface circuit & LCD Display. • Stepper motor control circuit.

44. SYSTEM OPERATION The Applications Board is controlled by two eight bit ports, port 1 and port 2, via the 40 pin IDC connector P2. The microprocessor/microcontroller system controlling the applications board must configure its ports (sometimes dynamically) in order to perform various operations. Some of the board functions are enabled/disabled using the Control Switches SW1 - SW9. SW1 to SW8 are grouped in the centre of the applications board whilst SW9 is situated in the Fibre Optic Link area. POWER REQUIREMENT Power (8V to 20V DC unregulated up to 1 Amp) is applied to connector P1, this is then regulated to 5V DC by REG1 providing power for the whole board.

45. System Connection ABITEC products 8086-DATS, 8051-DATS, 877-DATS, PLDATS, DIO-ADP1, Z80-DATS, ARM7S-TB and ARM3S-TB, MC11-DATS (with CAB-MC11), & KAYCOMPII (68000). systems are pin compatible with the Applications Board but it can be controlled from any microprocessor or microcontroller system equipped with two programmable eight bit ports. The applications board is connected to the controlling system via a 40 way IDC connector, pin function details can be seen in section 3. All connections to both the applications board and the controlling system should be made BEFORE power is applied to either unit. An overview of the application boards facilities is shown in figure 1.1.

46. CIRCUIT FEATURES This section gives details of each functional part of the applications board in turn, providing the user with all the information required to use that part of the board. In order to include numerous I/O devices on the applications board sharing two eight bit ports a number circuits must ‘share’ bits. Bit functions have been allocated to allow the most flexible operation of both the individual circuits and combination of circuits. The various bit functions are shown in table 2.1.

47. SWITCH ARRAY General input in provided by an array of eight slide switches connected to Port 1. When in an open position, a logic 1 is read, when closed a logic 0 is read. The switch arrangement and circuit diagram are shown in figures 2.1 and 2.2 respectively. Note: Since port 1 is ‘shared’ with other application circuits, the switches should be left in the OFF (UP) position when not used. This leaves each bit of port 1 free for other functions.

48. LED Array Port 2 provides a general output facility driving an array of eight large ‘tombstone’ LED’s. These are colour coded to allow simulation of traffic lights and a pedestrian crossing. Each LED is driven via an inverter. Outputting a logic 1 lights the LED whilst outputting a logic 0 turns the LED off. Note that when driving other circuits on port 2 the LED’s remain connected and therefore will still turn on and off. The LED array layout and circuit diagram is shown if figures 2.3 and 2.4 respectively

49. SEVEN SEGMENT DISPLAY The Applications Board provides four seven segment displays. The segments are driven form port 1 whilst each digit is enabled by bits D0 to D3 of port 2. The segments are illuminated by applying a logic 1 and each digit is enabled by outputting a logic 1. The segments of all four displays are connected, hence to display data the user must multiplex the display in software. The whole display is enabled or disabled with control switch SW8, down for on and up for off. The layout and circuit diagram are shown in figures 2.5 and 2.6 receptively

50. SEVEN SEGMENT DISPLAY   // Initial CPP Source File #include “ xstdsys.h ”   main() { unsigned int data_in , output; static const unsigned int PATTERN[10]={0x3f00, 0x3000, 0x5b00, 0x4f00, 0x6600, 0x6d00, 0x7d00, 0x0700, 0x7f00, 0x6700}; //patterns for seven segment const unsigned int SWTS=0xff; const unsigned int LEDS=0xff00; //switches const unsigned int DIGITS=0x0f; //digit enable bits g_pPMC ->PCER = PID2; g_pPIOA ->PER = 0xffff; //enable PIO g_pPIOA ->OER = LEDS | DIGITS; //enable output to LEDS g_pPIOA ->OWER = LEDS | DIGITS; //mask for synchronous write out to LEDS

51. while(1) { data_in =( g_pPIOA ->PDSR & SWTS)>>4; //read switches and shift right data_in =( data_in & 0x0f); //mask 4 bits required if( data_in >9) data_in =9; //max digit 9 output=(PATTERN[ data_in ]); //get pattern g_pPIOA ->ODSR = output; //write to LEDS g_pPIOA ->SODR = 1; //enable digit } }  

52. CONTROLLING THE DC MOTOR // Initial CPP Source File #include “ xstdsys.h ” void delay(unsigned int count); void delay(unsigned int count) { unsigned int i , j; for( i =0; i <count; i ++) for(j=0; j<300; j++ ) } main() { const unsigned int MOTOR_ON=0x20; const unsigned int MOTOR_OFF=0; g_pPIOA ->PER = 0xffff; //enable PIO g_pPIOA ->OER = 0x60; //enable outputs to motor control bits g_pPIOA ->OWER = 0x60; //mask for synchronous motor control bits while(1) { g_pPIOA ->ODSR = MOTOR_ON; delay(500); g_pPIOA ->ODSR = MOTOR_OFF; delay(1000); } }

53. // Initial CPP Source File #include “ xstdsys.h ” void delay(unsigned int count); void delay(unsigned int count) { unsigned inti, j; for( i =0; i <count; i ++) for(j=0; j<300; j++ ) } main() { const unsigned int MOTOR_ON=0x20; const unsigned int MOTOR_OFF=0; const unsigned int IRSENSOR_BIT=0x10; g_pPIOA ->PER = 0xffff; //enable PIO g_pPIOA ->OER = 0x60; //enable outputs to motor control bits g_pPIOA ->OWER = 0x60; //mask for synchronous motor control bits

54. while(1) { do { g_pPIOA ->ODSR = MOTOR_ON; //motor ON } while ( g_pPIOA ->PDSR & IRSENSOR_BIT);// until sensor=0 g_pPIOA ->ODSR = MOTOR_OFF; //motor OFF delay(100); //speed control do { g_pPIOA ->ODSR = MOTOR_ON; //motor ON } while (! g_pPIOA ->PDSR & IRSENSOR_BIT);// until sensor=1 g_pPIOA ->ODSR = MOTOR_OFF; //motor OFF } }      

55. FIBRE OPTIC RECEIVER & TRANSMITTER The Fibre optic section of the Applications Board consists of a transmitter and receiver which may be linked together or with another system. The transmitter is switched on by applying a logic one to port 2 bit 0, the receiver is read by examining port 1 bit 6. The circuit diagram is shown in figure

56. // Initial CPP Source File #include “ xstdsys.h ” void delay(unsigned int count); void delay(unsigned int count) { unsigned inti, j; for( i =0; i <count; i ++) for(j=0; j<300; j++ ) } void set_led (unsigned int value) { if(value == 1) { g_pPIOA ->SODR = 0x8000;} output logic 1 on LED else { g_pPIOA ->CODR = 0x8000;} output logic 0 on LED }

57. main() { const unsigned int RECEIVER=0x40; const unsigned int TRANSMITTER=0x8100; g_pPIOA ->PER = 0xffff; //enable PIO g_pPIOA ->OER = TRANSMITTER; //enable outputs to LEDS g_pPIOA ->OWER = TRANSMITTER; //mask for sync. write to LEDS while(1) { g_pPIOA ->SODR = 0x100; //output logic 1 on transmitter delay(1000); //wait if( g_pPIOA ->PDSR & RECEIVER) { set_led (1);} else set_led (0); g_pPIOA ->CODR = 0x100; //output logic 0 on transmitter delay(1000); //wait if( g_pPIOA ->PDSR & RECEIVER) { set_led (1);} else set_led (0); } }  

58. STEPPER MOTOR INTERFACE (OPTIONAL) The Stepper Motor Interface is designed round the motor drive and interface i.c . M5804. Four bits, D4 - D7 on port 1 control the stepper motor as shown in table 2.3. The condition of the drive circuit is indicated by four LED’s D8 - D11. The stepper motor is connected to the applications board via connector P3.

59. THE FUNCTION OF EACH BIT IS AS FOLLOWS: • One-Phase (D7) When this bit is set to a logical one the I.C. is set to One Phase stepping mode. • Half-Step (D6) When a logical one is applied to this bit, the I.C. is set to Half Step mode. Note that if bits 6 & 7 are both set to a logical zero, the I.C. is set to Full Step mode. When bits 6 & 7 are both set to a logical one, the I.C. is set to Inhibit mode and incoming step pulses are ignored. Table 2.4 summarises these operations. • Step (D5) When this bit changes from a logical one to a logical zero the motor executes one step dependant on the step mode selected. • Direction (D4) This bit sets the direction of rotation of the motor. The actual direction will depend on the winding orientation of the stepper motor connected to the applications board

60. // Initial CPP Source File #include “ xstdsys.h ” void delay(unsigned int count); void delay(unsigned int count) { unsigned inti, j; for( i =0; i <count; i ++) for(j=0; j<30000; j++ ); } main() { int j; const unsigned int STEPPER=0xf0; g_pPIOA ->PER = 0xffff; //enable PIO g_pPIOA ->OER = STEPPER; //enable output to STEPPER g_pPIOA ->OWER = STEPPER; //mask for sync. write to STEPPER g_pPIOA ->ODSR = 0x90; //set up stepper bits while(1) { g_pPIOA ->CODR = 0x20; //clear step bit delay(25); g_pPIOA ->SODR = 0x20; //set step bit } }