Microprocessor Programming and Application

1. Microprocessor Programming and Application Input/Output

2. Input/Output Problems • Wide variety of peripherals • Delivering different amounts of data • At different speeds • In different formats • All slower than CPU and RAM • Need I/O modules

3. Input/Output Module • Interface to CPU and Memory • Interface to one or more peripherals

4. External Devices • Human readable • Screen, printer, keyboard • Machine readable • Monitoring and control • Communication • Modem • Network Interface Card (NIC)

5. I/O Module Function • Control & Timing • CPU Communication • Device Communication • Data Buffering • Error Detection

6. I/O Steps • CPU checks I/O module device status • I/O module returns status • If ready, CPU requests data transfer • I/O module gets data from device • I/O module transfers data to CPU • Variations for output, DMA, etc.

7. I/O Module Diagram (c.f. Memory) Systems Bus Interface External Device Interface External Device Interface Logic Data Data Register Data Lines Status Status/Control Register Control Address Lines Input Output Logic External Device Interface Logic Data Data Lines Status Control

8. I/O Module Decisions • Hide or reveal device properties to CPU • Support multiple or single device • Control device functions or leave for CPU • Also O/S decisions • e.g. Unix treats everything it can as a file !

9. Input Output Techniques • Programmed • Interrupt driven • Direct Memory Access (DMA)

10. Programmed I/O (a.k.a. polling, busy wait) • CPU has direct control over I/O • Sensing status • Read/write commands • Transferring data • CPU waits for I/O module to complete operation(busy waiting, that is, CPU does nothing really) • Wastes CPU time

11. Programmed I/O - detail • CPU requests I/O operation • I/O module performs operation • I/O module sets status bits • CPU checks status bits periodically • I/O module does not inform CPU directly • I/O module does not interrupt CPU • CPU may wait or come back later

12. Programmed I/O - detail • i = num_of_words_to_send;   while ( i != 0) {    repeat     status = read (status_reg);    until (status == 1); /* busy waiting */    i = i - 1;    send (word[i]);   }

13. Solutions • We can employ DMA (direct memory access) • DMA controller performs faster I/O operations (synchronous) upon a request from CPU • However, what if the I/O wants to initiate I/O instead of the CPU (e.g. events, exception, traps ...) ? • We already learned that polling is wasteful (e.g. periodically checking the devices to see if they want to send data to the CPU) • Polling will not even work properly if the events must be processed right away (e.g. can not wait until the CPU checks what the device wants to do)  Allow I/O devices to issue desire to I/O ! (interrupts)

14. I/O Commands (1) • CPU issues address • Identifies module (& device if >1 per module) • CPU issues command • Control - telling module what to do • e.g. spin up disk • Test - check status • e.g. power? Error? • Read/Write • Module transfers data via buffer from/to device

15. I/O Commands (2) • Special Instructions (now rare) • Input_ch R1 ; like get character • print_ch • …

16. Addressing I/O Devices • Under programmed I/O data transfer is very like memory access (CPU viewpoint) • Each device given unique identifier • CPU commands contain identifier (address)

17. I/O Mapping • Memory mapped I/O • Devices and memory share an address space • I/O looks just like memory read/write • No special commands for I/O • Large selection of memory access commands available • Isolated I/O • Separate address spaces • Need I/O or memory select lines • Special commands for I/O • Limited set

18. Interrupt Driven I/O • Overcomes CPU waiting • No repeated CPU checking of device • I/O module interrupts when ready • A way of I/O devices to alert the CPU by activating one of the control lines (Interrupt Request) of the CPU • Then, CPU "services" the interrupt and returns to its normal processing state. CPU does not poll on anything because the devices can raise interrupt any time they want (Asynchronous) similar to procedure call ! (think of the exam problem)

20. Interrupt Driven I/OBasic Operation • CPU issues read command • I/O module gets data from peripheral whilst CPU does other work • I/O module interrupts CPU • CPU requests data • I/O module transfers data  a bit more efficient also (aside from the advantage of allowing I/O device to request I/O operations)

21. Non-DMA interrupt driven I/O with interrupt where the CPU computes something to be printed out continuously • CPU computes few lines of output • PRINT sends few lines of text for output • CPU continues to compute • PRINT ready interrupts and CPU sends few more lines for output • CPU continues to compute

22. CPU Viewpoint • Issue read command • Do other work • Check for interrupt at end of each instruction cycle • Add this to fetch-decode-execute-store cycle) fetch – decode – execute – store – check interrupt (fast enough) • If interrupted:- • Save context (registers) • Process interrupt • Fetch data & store

23. Interrupt Service Routine:(similar to subroutine or procedure in terms of what is internally done) • load PC with address of interrupt service routine • save CPU state and etc. • execute service routine • return to the previous point and restore CPU state(the CPU may (semi) automatically save parts of the CPU state)Note: interrupt routines and CPU program designers are in many cases different, therefore, tobe safe, all registers are saved when saving state in response to interrupts ... (i.e. do not know which registers are affected)

24. Issues • How do you identify the module issuing the interrupt? • How do you deal with multiple/simultaneous interrupts? • i.e. an interrupt handler being interrupted

25. Arrival of interrupt • It can be any time, but there are cases that the CPU does not want to or can not handle the interrupt (when ?) • We need the capability to "enable" or "disable" incoming interrupts ... • Interrupt Masking: placing a user programmable interrupt mask register on interrupt request lines.   The interrupt request line is ANDed with contents of mask register ... • More generally, we need the capability to selectively "enable" or "disable" certain (not just all) interrupts ... • e.g. PRINT should interrupt CPU when CPU is ready only, so the CPU will disable the interrupt until it is ready to output something ... • Incoming interrupts may be served based on priority or completely be ignored ...

26. Identifying who interrupts (1) • Different hardware line for each module • Limits number of devices • Software poll • CPU asks each module in turn (interrupt controller in the middle) • Slow

27. Identifying who interrupts (2) • Daisy Chain or Hardware poll • Interrupt Acknowledge sent down a chain • Module responsible places vector on bus • CPU uses vector to identify handler routine • Bus Master • Module must claim the bus before it can raise interrupt • e.g. PCI & SCSI

28. Vectored interrupt • Associate unique starting address with each line or send special code overI/O bus (so that single request line is used) • This may be indirect (instead of using to code to figure out the service routine address, the address found by translating the code contains the service routine address) • When CPU receives a interrupt request, it may be in the midst of processing an atomic instruction or serving high priority job, so it acknowledges that it is ready to serve ...

29. Figuring out Interrupt Service Address • CPU gets the code or the vector • then applies some simple function to map this to a number that contains the address of service routine. • for example, in 8088, it can interface with 256 devices, and handing addresses are stored in a table at the top of the memory from 0 to 1016 (each entry needs 4 bytes). • so we can think device i has code i • if device 5 interrupts, it will send 5 as its vector, and we multiply it by 4 • address 20 will contain the address of service routine for device 5

30. Figuring out Interrupt Service Address • For each vector, the starting address is stored at the top of the memory (memory location 0 to 255*4) • For each vector, 4 bytes are needed, 2 for the segment address and 2 for the offset (IP)

31. Multiple Interrupts • Each interrupt line has a priority • Higher priority lines can interrupt lower priority lines

32. Interrupt Priorities (1) • For instance, a timer must have very high priority so that the time is kept right ... • If CPU polls on devices upon interrupt request, device that is polled first gets served first • In a daisy chain where interrupt request acknowledge line is chained among devices (the acknowledge passes through the devices until reaching the first device requesting the interrupt).  The first device electrically close to the CPU gets served first ... (Closer the device is chained, the higher its priority priority)

33. Interrupt Priorities (2) • A priority handling circuitry can be made to accept from multiple request lines (one request per device for example) and the priority handling circuit determines who to serve by sending the acknowledge signal to the device with highest priority.  This method is more flexible but requires more hardware • And, of course, the daisy chain and priority handling circuitry can be mixed ... (several devices daisy chained for one priority group) ...

34. Interrupt during Interrupt (1) • Ignore any interrupt during interrupt service, or • Allow higher priority to be served • Jump to higher priority interrupt service routine as usual • Save information about any incoming lower priority interrupt requests in a stack as pending so that these can be served after the high priority ones are served

35. Interrupt during Interrupt (2) e.g. 3 devices: printer (2), disk (4), serial device (5), numbers in bracket are prorities ... ---------------------------------------------------------------------------------------- time       |                         |          |         |           |                       |      A                       B        C      D          E                       F A: printer interrupts and CPU starts serving it B: serial device interrupts and since it has higher priority, printer service is stoppedand serial device is served C: disk interrupts but since it has lower than currently running service routine, it pends (information saved on stack, or …) D: serial device service ends, returns to it jumped from the printer service routine, checks for any pending interrupt, finds disk is pending and since it has higher priority than printer, starts service it E: disk service ends, printer service continues F: printer service ends, returns to normal CPU execution

36. Exception • Interrupts are generated internally by CPU) • When ?  Some undesirable CPU state (divide by zero, illegal memory access, etc)like external events, they must be servied by interrupt routines • Therefore, they too have vector numbers associated with types of exceptions which would be higher priority than user external interrupts, and their address table is located with the address table for the user external interrupts

37. Summary • CPU initiated (Programmed) I/O • Talk to device or I/O Module (for loops) • Device initiated I/O • Device send interrupt signal • CPU checks interrupt arrival very fast (F-D-E-(S)-CI) • If interrupted, send ack to requesting device • Note that CPU can ignore interrupt request by setting interrupt mast register • The requesting device place vector (id) on bus • CPU gets the id and apply some function to get address of table entry where subroutine address is stored • That vector-to-address table is called interrupt vector table and sits somewhere in memory (fixed) • Save CPU state and jump • If higher priority interrupt comes in nested jump

38. Interrupt interface (Daisy Chain) ~INTR CPU D1 D2 D3 ACK Vector Data bus

39. Interrupt interface (Priority CKT) INTR Priority Handling CKT ~INTR CPU D1 D2 D3 ACK ACK Mask Reg. Vector Data bus

40. Interrupt interface (mixed) Priority Arbitrated Daisy Chain Priority Handling CKT D1 D2 D3 D1 D2 D3

41. Example - PC Bus • 80x86 has one interrupt line • 8086 based systems use one 8259A interrupt controller • 8259A has 8 interrupt lines

42. Sequence of Events • 8259A accepts interrupts • 8259A determines priority • 8259A signals 8086 (raises INTR line) • CPU Acknowledges • 8259A puts correct vector on data bus • CPU processes interrupt

43. PC Interrupt Layout 8259A 8086 IRQ0 IRQ1 IRQ2 IRQ3 INTR IRQ4 IRQ5 IRQ6 IRQ7

44. ISA Bus Interrupt System • ISA bus chains two 8259As together • Link is via interrupt 2 • Gives 15 lines • 16 lines less one for link • IRQ 9 is used to re-route anything trying to use IRQ 2 • Backwards compatibility • Incorporated in chip set

45. ISA Interrupt Layout (IRQ 2) 8259A 80x86 8259A IRQ0 IRQ0 (8) IRQ1 IRQ1 (9) IRQ2 IRQ2 (10) IRQ3 INTR IRQ3 (11) IRQ4 IRQ4 (12) IRQ5 IRQ5 (13) IRQ6 IRQ6 (14) IRQ7 IRQ7 (15)

47. 잠깐 … • 8086/88 • First 640K for operating system and user program • Remaining • Used by system hardware like video display and disk controller or by ROM BIOS • Limited memory, of course, so as x86 family evolved, it tried to rectify this situation (like more address space, and virtual memory)

48. Memory Map 640K

49. Memory Map • Interrupt Vector Table • 1024 bytes (00000 – 003FF) • Software BIOS • Routines for managing keyboard, printer, console, time of day clocks … • Loaded from a hidden system file called io.sys • Kernel • Collection of subroutines (services) • Loaded from a file msdos.sys • File buffers, Device drivers • Loaded from a file called config.sys • Command.com • Loaded from command.com • Interprets commands typed at console and executes the command

50. Memory Map