Checkpoint LAB USB-RS232 Especificaciones Pagina 1

Busca en linea o descarga Especificaciones para Sistemas operativos Checkpoint LAB USB-RS232. Checkpoint LAB USB-RS232 Specifications Manual de usuario

  • Descarga
  • Añadir a mis manuales
  • Imprimir
  • Pagina
    / 12
  • Tabla de contenidos
  • MARCADORES
  • Valorado. / 5. Basado en revisión del cliente
Vista de pagina 0
ECE391: Computer Systems Engineering Spring 2015
Machine Problem 2
Checkpoint 1: Monday, March 2, 7pm
Checkpoint 2: Monday, March 9, 7pm
Device, Data, and Timing Abstractions
Read the whole document before you begin, or you may miss points on some requirements.
In this machine problem, you will extend a video game consisting of about 4,000 lines of cod e with additional graphical
features and a serial port device. The code for the game is reasonably well-documented, and you will need to read
and understand the code in order to succee d, thus building your ability to explo re and comprehend existing software
systems. Most code that y ou will encounter is neither as small nor as well docum ented—take a loo k at some of the
Linux sour ces for comparison—but this assignment should help you start to build the skills necessary to extend more
realistic systems. As your effort must span the kernel/user boundary, this assignment will also expose you to som e of
the mechan isms used to manage these interac tions, many of which we will study in more detail later in the course.
Before discussing the tasks for the assignment, let’s discuss the skills and knowledge that we want you to gain:
Learn to write code that interacts directly with devices.
Learn to abstract devices with system software.
Learn to manipulate bits and to transform data fro m one format into another.
Learn the basic structure of an event loop.
Learn how to use the pth read API.
Device Protocols:
We wa nt yo u to have some experience writing software that interacts directly with devices and must adhere to the
protocols specified by those d evices. Similar problems arise when one mu st mee t software inte rface specifications,
but you need experience with both in order to recogn iz e the similarities and differences. Unfortunately, most of the
devices accessible from within QEMU have fully developed dr ivers within Linux. The vid eo card, however, is usually
managed directly from user-level so as to improve performance, thus most of the code is in other software packages
(e.g., XFree86).
We were fortunate to have a secon d device designed by Kevin Bassett and Mar k Murphy, two previous staff member s.
The Tux Controller is that funny little game controller attached to eac h of the machines in the lab.
The Tux Controller connects to the USB port of the lab machine. An FTDI “Virtual Com Port” ( VCP) driver makes the
USB port appear to sof tware as a stand ard (old fashioned) RS232 serial port. We can then set up QEMU so that one of
the e mulated serial ports on the virtual machine m a ps to the emulated serial port connected to the Tux Controller. In
this assignment, you will write cod e that interacts directly with both the ( emulated) video card and the game controller
board.
Device Abstraction:
Most devices implement only part of the functionality that a typical user might associate with th e m. For example, disk
drives provide only a simple inter face through which bits can be stored and retrieved in fixed-size bloc ks of several
kB. All other functiona lity, including everything from logical partitions and directories to variable-length files and file-
sharing semantics, is supported by software, most of which resides in the operating system. In this machine problem,
you will abstract some of the functionality provided by the Tux controller board.
Format Interchange:
Vista de pagina 0
1 2 3 4 5 6 ... 11 12

Indice de contenidos

Pagina 1 - Machine Problem 2

ECE391: Computer Systems Engineering Spring 2015Machine Problem 2Checkpoint 1: Monday, March 2, 7pmCheckpoint 2: Monday, March 9, 7pmDevice, Data, and

Pagina 2 - The Pieces Provided

level programs such as the game. You must implement the following ioctls for your device abstraction:TUX INIT Takes no argume nts. Initializes any var

Pagina 3 - Mode X and Graphic Images

110 1 0 00 0 1 0X XXC ALBUDRXX XS7 0120That is, the fir st byte will have the value MTCP POLL OK, the second and third will contain active-lowbit masks

Pagina 4 - Graphical Mapping in the Game

adjacent levels look different (you can reuse so me colors if you want, but you can’t h ave just one). You can also makethem glow, chang e with the nu

Pagina 5

This machine problem gives you several o pportu nities for working with da ta layout in memory and for tr ansformingdata from one form to another. Mos

Pagina 6 - The Checkpoint

assert.c Suppor t for assertions and cleanups as design and debugging aids.blocks.s Graphic block images of the maze, the player, fruits, etc.input.c

Pagina 7

Each pixel in mode X is represented by a on e -byte color value. Although only 256 colors are available in mode X, theactual color space is 18-bit, wi

Pagina 8

The game defines a two-dimensional world of pixels, an d the screen at any time shows a region of that world. Themaze world is never f ully constructed

Pagina 9

The next question is the size of the build buffer. If we can limit the size of the maze world, we can allocate a buildbuffer large enough to hold any

Pagina 10

easy p la c e to start. The main difficulty is for you to understand bo th how mode X maps pixels and how the abstractionsin modex.c work, so try to re

Pagina 11

the USB port appear to software as a standard (old fashioned) RS232 serial port. We can then set up QEMU so that oneof the emulated serial ports on th

Pagina 12

Building the Driver:The mp2/module directory contains a framework for the driver you will be implementing for the Tux controller. Amodule is similar t

Comentarios a estos manuales

Sin comentarios