I/O, Peripherals, HW/SW InterfaceI/O Device InterfaceI/O device: software sideI/O Device: hardware sideEfficient InterfacingProgrammed I/O ExampleBetter Programmed (scheduled) I/OInterrupt-Driven I/OHardware support for interruptsInterrupt Request (IRQ)Interrupt RoutinesDisabling InterruptsSlide 14Interrupt NestingInterrupt PrioritiesWorst-Case Interrupt ResponseInterrupt Handlers Code LocationSlide 19Slide 20Shared Data ProblemSlide 22Nuclear Reactor Monitoring SystemSlide 24Slide 25Slide 26Slide 27Slide 28Interrupt LatencySlide 35Interrupt Latency Example IISlide 38Slide 39Slide 40Slide 41Volatile VariablesSlide 43Slide 44Slide 45‘volatile’ KeywordInterrupts, Traps, and ExceptionsSlide 48Restarting After a Synchronous InterruptTraps - Implementing System CallsMicroBlaze Interrupt HandlersMicroBlaze InterruptsMB Interrupt flowMB Interrupt FlowInterrupt ConclusionsReactive System RepriseSparesBusesProgrammed (Polled) I/OInterrupt SignallingSlide 61Direct Memory AccessDMASlide 65DMA (Alternative Architecture)Sample I/O Devices: Programmable clocksTimeGoals of embedded clocksInterrupts and Interrupt HandlingI/O, Peripherals,HW/SW InterfaceForrest BrewerChandra KrintzI/O Device Interface•Interface is composed of:•Driver (SW), bus and HW peripheral, physical HW device•Overall, the interface introduces an abstraction layer (or several) simplifying the process of making use of the physical (or virtual) device.•File I/O in linux/windows looks like byte stream or record I/O•Network officially uses 7 layers of abstraction•Typically:•Driver implements:•Device Initialization and Reset•Initialization of Data Transfers and Management of Data Flow•Device Shutdown and Removal•Often two driver interfaces: data channel and device controlI/O device: software side•Memory Map•Hardware Glue is used to create a physical address space which is serviced by dedicated hardware as if it was memory•Conceptually Simple from program viewpoint•Potentially Breaks Memory Paradigm•Memory values change w/o CPU activity…•I/O port•Use two or more address spaces•Ports can be written or read, but are not Memories•Sometimes special I/O instructions or Status Bit•Issues•Kernel time limited – but•CPU protection modes•Coherence atomicity•Preservation of Device State•Minimal Kernel state for synchronization/modal behaviorI/O Device: hardware side•Physically must decode Memory address bus or I/O port address, then manage physical data transfer to device•Data formats and rates often very different•EG SPI based A/D is a bit-serial interface with rates between 20kHz and 50+MHz, yet CPU is expecting a Byte or Word parallel transfer on its event timing.•Physical device usually has own idea about time and who is boss…•Usually CPU is forgiving about adding ‘wait’ states or delaying trasnfers•Device operation timescales can be much faster or much slower than CPU software events, yet a reliable, efficient interface is needed.•Minimal: HW synchronization from event to CPU Bus•Often, buffering FIFO and interrupt generation as well as protocolEfficient Interfacing•Service dozens of peripherals, each with own time scale•How to keep data transfers coherent?•How to prevent slow devices from slowing down system?•Classically, two kinds of Interface•Polling (Program Driven I/O)•CPU polls the device addresses and takes action when needed•Simple to build HW, but CPU needs to poll often – so may not be efficient if lots of devices•Sequential program flow is maintained•Interrupts (Event Driven I/0)•Set up event, then go off and do other things until signaled•On signal, drop everything, service need and resume other things•Allows for preempt of CPU as events dictate, but•Breaks sequential program flowProgrammed I/O Example•Writing a string to a (RS-232) serial outputCopyFromUser(virtAddr, kernelBuffer, byteCount);for(i = 0; i<byteCount; i++) { while (*serialStatusReg != READY); *serialDataReg = kernelBuffer[i];}return;•Called “Busy Waiting” or “Polling”•Simple and reliable, but CPU time and energy waste•This is what happens when you talk to slow devices (like Board LCD) with 1 control thread…Better Programmed (scheduled) I/O•Idea– don’t wait locally for events, doing nothing else•Instead, poll for multiple events by merging local loops into larger one.•Leads to ‘grand loop’ designs•Works only if devices are slow compared to CPU•If devices are really slow– wastes CPU power•Can be generalized if you know something about the pattern of arriving signals.•Maybe better idea is to use hardware to do the ‘scan’ for change of I/O state?Interrupt-Driven I/O•Getting the I/O started:CopyFromUser(virtAddr, kernelBuffer, byteCount);EnableInterrupts();i = 0;while (*serialStatusReg != READY);*serialDataReg = kernelBuffer[i++];sleep ();•The Interrupt Handler:if (i == byteCount) Wake up the user processelse{ *serialDataReg = kernelBuffer[i] i++;}Return from interrupt• External hardware signals request - here, device signals that data in serialStatusReg has been sent• CPU Checks if interrupt can be taken BSR to interrupt handler Executes handler  Returns to interrupted taskLifetime of an InterruptHardware support for interruptsIf there are many devices, an interrupt controller can do the work instead of the CPU using multiple I/O pins. Connections between devices and interrupt controller actually use interrupt lines on the bus rather than dedicated wiresInterrupt Request (IRQ)•When an IRQ is asserted•MP stops doing what it was doing (executing instructions)•Completes execution of the instruction that is executing•flush the instructions currently pending execution•Create new stack frame (after any required context switch)•Saves the next address on the stack •Like a return address when a CALL instruction is executed•However the `CALL’ is done automatically•Jumps to interrupt routine•Interrupt handler or service routine (ISR)•Very short, fast subprogram•Interrupts live in real-time, often on system SWInterrupt Routines•Notice: Interrupt can occur between any two instructions•CALL instruction: compiler knows what code came before and after the call•Compiler can write code to save/restore registers used in the callee •The compiler (when generating code for interrupt handler)•Or assembly programmer•Can not know when interrupts will