ChapterX-ProgrammingIssues-w07

ChapterX-ProgrammingIssues-w07 - From Chapter 7. Challenges...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon
From Chapter 7…. Challenges of I/O Programming 1. Electrical interfacing of I/O devices 2. Synchronization of I/O devices to CPU I/O Devices operate Asynchronously I/O Devices operate at much different speeds, experience delays related to mechanical characteristics I/O Synchronization occurs Between interface chip and I/O device (largely a hardware issue) Between CPU and interface chip (software issues) Let’s consider the software issues
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Synchronization Methods 1. Blind cycle : Software simply waits a fixed amount of time and assumes the I/O operation is complete What’s an example on the Axiom board ? 2. Busy waiting (polling) Requires a status register on the I/O device that the software can read 3. Interrupt Requires an interrupt pin on the I/O device that can be connected to the MCU 4. Periodic polling : A clock generates periodic interrupts to which the software (ISR) checks the I/O status (polls) Used when regular status checks are required but no interrupt circuitry is available on the I/O device 5. Direct Memory Access (DMA) : Data is transferred directly from memory to device (without CPU involvement) …
Background image of page 2
Polling Programming Issues Polling is advantageous when : predictable arrival times, simple I/O, fixed load, nothing else to do Input Device while (status!=ready) { } read data Output Device while (status!=ready) { } write data They look the same, but what does “status” bean in each case ?
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Polling Programming Issues : Handling Multiple Devices Polling imposes a fixed priority (by the order of polling) and does not allow high-priority devices to suspend the operation of lower-priority devices - fixed, not flexible. if (status1 == ready) { service device1 } if (status3 == ready) { service device3 } if (status2 == ready) { service device2 }
Background image of page 4
Foreground runs in direct response to event, with deterministic latency Interrupts are advantageous when : variable arrival times, complex I/O, different speeds, other work to do infrequent but important alarms data acquisition and control real-time clocks and periodic behaviour start interrupt initialize ISR Wait for Data RTI Background Foreground Interrupt Programming Issues : Fore/Background Synchronization Synchronize access Global Data
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Recall : Interrupt-Driven Keypad EMPTY EQU $FF ; ASCII code != any key char db EMPTY In the foreground (ISR): jsr getASCII ; Returns ASCII key in accA staa char rti In the background (Main): ldaa #EMPTY polling: cmpa char beq polling ldaa char movb #EMPTY, char staa 1, x+ ; Store in array[i++] Atomic Access : O nce started, guaranteed to finish - Machine instructions are atomic Nonatomic access : Can be interrupted
Background image of page 6
Interference : Corruption of non-atomic access due to interruption by another thread of control manipulating same memory space.
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 8
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 43

ChapterX-ProgrammingIssues-w07 - From Chapter 7. Challenges...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online