1 / 31

G53SRP: Hardware interfacing

G53SRP: Hardware interfacing. Chris Greenhalgh G53SRP. Contents. PC/bus architecture Device registers I/O instructions High-level language support Device register interaction Bit-wise operators (review) Interrupts High-level language support Java, RTSJ Java and C

jenniferwallace
Download Presentation

G53SRP: Hardware interfacing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. G53SRP: Hardware interfacing Chris Greenhalgh G53SRP

  2. Contents • PC/bus architecture • Device registers • I/O instructions • High-level language support • Device register interaction • Bit-wise operators (review) • Interrupts • High-level language support • Java, RTSJ Java and C • Book: Burns & Wellings 15.1, 15.2, 15.5, 15.7, Wellings 15 intro & 15.3, plus a few extra bits :-)

  3. Typical PC architecture CPU VDU controller Keyboard controller System bus Businterface/ bridge Expansion bus (e.g. PCI, ISA,…) Disc controller General I/O Controller? memory disc Other hardware…

  4. Buses • Def. • "Common set of electrical connections" • Standard interface • control signals • address signals • data signals • Standard protocol (rules) • read cycle • write cycle • interrupt cycle (see notes on device programming)

  5. Example: CPU read cycle 0x394 (e.g.) Address (from CPU) Control: “read memory” (from CPU) Memory retrieves requested data Data (from memory) 0x45 (e.g.) Time

  6. Device registers • "Look" like memory • status registers (read) • control registers (write) • data buffer registers (read/write)

  7. I/O instructions • Memory mapped • (same physical & logical bus) • normal read/write instructions • E.g. Motorola 68000 MOVE.L reg,address • Separate I/O space • (separate physical or logical bus) • dedicated I/O instructions • E.g. Intel x86: IN reg, portOUT reg, port

  8. HLL register access • Requires either HLL functions which wrap these low-level operations E.g. • Linux kernel helper routines: void outb(unsigned char byte, unsigned int port);unsigned char inb(unsigned int port); • RTJavaRawMemoryAccess class • see over and memory areas notes

  9. RawMemoryAccess class package javax.realtime; public class RawMemoryAccess { public RawMemoryAccess( Object type, long base, long size); … public byte getByte(long offset); public intgetInt(long offset); public void setByte(long offset, byte value); public void setInt(long offset, int value); … } As for Physical memory areas Raw memory bytes Byte order platform dependent…

  10. HLL register access (2) • Or Ability to mix HLL and assembly language E.g. C/C++ • gcc: /*C…*/asm("movl %ecx %eax"); /*C…*/

  11. Register value manipulation (1) • The same location may have different functions • Setting other bits/registers may determine what register/function it actually has when accessed • Reading and writing may have different functions • Reading a status register vs writing to a completely different control register from/to same location => May need to maintain “shadow” control register values in code since cannot rely on reading values back

  12. Register value manipulation (2) • Registers often contain packed binary data • Minimise number of addresses required • Minimise rounds of communication • Requires extensive use of bit-manipulation operations in the driver…

  13. Java integer types

  14. C (default) integer types

  15. Hexadecimal (0x…) NB. Exactly 4 bits/digit

  16. Octal (0…) NB. Exactly 3 bits/digit

  17. Unary Bit-wise operators • ~ (bitwise complement)

  18. Bit-shift operators • << (left shift) • 0x1234 << 30001001000110100 base 2 • = 0x91A01001000110100000 base 2 • >> (right shift) • 0x1234 >> 30001001000110100 base 2 • = 0x02460000001001000110 base 2

  19. Binary bit-wise operators

  20. Interrupts • Device-initiated • I.e. asynchronous, external events • Controlled by device control registers • E.g. individually enabled & disabled • Managed by CPU • I.e. can be temporarily ignored under program control (See later notes)

  21. Approaches to device control • Status driven • CPU polls • Interrupt driven, i.e. interrupt from device initiates… • CPU controlled • All data transfer performed by (main) CPU • CPU initiated (Direct Memory Access) • Data transfer delegated to specialised helper unit • Channel controlled • Data transfer (perhaps also interrupt handling) delegated to specialised I/O processor (“channel”) (mainframe!)

  22. Note • Interrupts and DMA/channel IO can result in CPU cycles being “lost” or “stolen” from the main process(es) • Increases worst-case execution time(s) • May make process sets unschedulable • So interrupts are often disabled in safety critical systems • Rely on guaranteed scheduled polling rates

  23. HLL support for interrupts (1) • Interrupt handler: • Can call suitable procedures directly • E.g. C subroutine address registered as handler for low-level interrupt • Or requires some other way to bind HLL process to interrupt • E.g. RTSJ AsyncEventHandler for AsyncEvent with interrupt bound to HW Interrupt

  24. HLL support for interrupts (2) • Requires access to interrupt management operations • (again) inclusion of relevant machine code instructions • E.g. to set/clear interrupt enable bit • Or wrapper functions in HLL giving access to these • E.g. Linux C helper functions (set/clear interrupt enable bit)void sti(void);void cli(void); • Or other language-specific mechanisms • E.g. RTSJ priority-based scheduling of handlers, plus use of Java Synchronisation

  25. High-level language facilities • Assembly language • Low level!! • Java (non-RTSJ)… • RTSJ Java… • C…

  26. Non-RTSJ Java • Con: • No direct access to memory • No bit field types • No machine-specific I/O instructions • No link to hardware interrupts • No access to interrupt management • Difficult machine code integration • Fixed method prologues/epilogues • Unpredictable GC • Relatively heavy-weight classes/methods

  27. RTSJ Java • Con: • No bit field types • Difficult machine code integration (but shouldn’t need it?!) • Fixed method prologues/epilogues (but shouldn’t matter?!) • Relatively heavy-weight classes/methods • Pro: • Direct access to memory via API • Machine-specific I/O via API • Link to hardware interrupts via async. events • Access to interrupt management via scheduling • Alternative memory management options to control GC

  28. C • Pro: • Supports native pointers • Includes bit fields • (Relatively) easy inclusion of assembly • C procedure = machine code subroutine • Customisable prologue/epilogue • Con: • Lack of classes, GC, etc.

  29. Some example devices • simple joystick interface • 2001 exam, Q2 • printer interface • 2002 exam, Q1 • UART (serial line) • appendix A

  30. Summary (1) • PC/bus architecture interfaces to hardware via • Registers = virtual memory locations • Interrupts = asynchronous notifications from device • Device registers typically • Status of device/interface – read • Control of device – write • Data input/output – read/write • Accessed via custom I/O instructions or mapped memory access • RTSJ access via RawMemoryAccess

  31. Summary (2) • Interrupts allow more efficient/timely (non-polling) notification of CPU by device • RTSJ support via AsyncEvent bound to interrupt • Management via RTSJ scheduling facilities and Java synchronization • Non-RTSJ Java unsuitable for device interfacing • C suitable (e.g. Linux/UNIX device drivers)

More Related