IEEE TRANSACTIONS ON EDUCATION, VOL. E-24, NO. 1, FEBRUARY 1981

An Interdisciplinary Course in Real-Time Computing

DONALD E. THOMAS, MEMBER, IEEE

Abstract-A need is arising for engineers who understand both anengineering discipline, and the use and capabilities of real-time com-puting equipment. This paper discusses the development, content, andimplementation of an interdisciplinary course in real-tihne computing.Experiences in running this course will be compared to the normalelectrical engineering course of similar content.

INTRODUCTIONA SUCCESSFUL engineering and science education pro-

gram must continue to balance a strong commitmentto the fundamentals of physics, chemistry, and mathematicswith the introduction of new, potentially revolutionary tech-nological advances; particularly those that cut across broaddisciplinary boundaries. Advances in the electronics industryhave produced the microcomputer: an inexpensive but capablepiece of equipment that is becoming an essential part of manyengineering applications. These applications span the range ofthe standard engineering disciplines and include: the controlof complex systems such as aircraft and chemical plants,basic consumer devices such as automobiles and telephones,the monitoring and control of manufacturing processes suchas steel making, and the testing of new structural materialsfor building. For these and other applications, the need arisesfor engineers who understand both an engineering discipline,and the use and capabilities of computer equipment in theengineering laboratory.

It is our contention that the introduction of laboratorymicrocomputers into our curriculum will be as revolutionaryas, in retrospect, the introduction of programming courseswas 15-20 years ago.This paper discusses the development, content, and imple-

mentation of an interdisciplinary course on the use of real-time computing equipment in the engineering laboratory.The course described here was offered for the first timeduring the Spring semester of 1980 and seven studentsenrolled. Three of the students were junior civil engineers, onewas a sophomore chemical engineer, one was a senior mathmajor, and two were mechanical engineering technicians.Experiences in running this course will be compared to thenormal electrical engineering course of similar content.

COURSE DEVELOPMENT

Since the use of microcomputers is becoming more prev-alent in the various engineering fields, the Carnegie Instituteof Technology (the Engineering College of Carnegie-MellonUniversity) developed a course to teach the fundamentals of

Manuscript received June 26, 1980.The author is with the Department of Electrical Engineering,

Carnegie-Mellon University, Pittsburgh, PA 15213.

laboratory computer usage. The major thrusts of the courseare to introduce the engineering students to the basics ofreal-time computer usage, and to allow them to study perti-nent uses of real-time computing in their major discipline.This section will discuss the development of the course.

Philosophy of the CourseAn interdisciplinary committee representing the various

engineering departments (Chemical, Civil, Electrical, Mechan-ical, and Metallurgy and Materials Science) with the author aschairman was organized to develop a course in real-timecomputing. A set of philosophical goals was proposed toguide the development of the course:

* The course should be interdisciplinary with respect toengineering students. The prerequisites should be an introduc-tory computing course and the engineering math sequence.

* The course should be at the sophomore-junior level withtwo hours of lecture and three hours of lab per week.

* The course should cover both the computer science andthe engineering aspects of using computers in a laboratorysituation.* The course should recognize the fast pace of the computer

technology and be general enough to prepare the student forfuture systems.

* The course should recognize that hands-on use of somecomputer equipment is fundamental to its understanding.

It was recognized that to maintain the interdisciplinarynature of the course, pertinent (and possibly state of the art)uses in each engineering field could not be discussed in depth.Thus a course sequence was proposed (Fig. 1) as a goal foreach department. The figure shows the prerequisite comput-ing course followed by the interdisciplinary real-time com-puting course. It was proposed that as more students obtainthe real-time computing background, senior level projectcourses could make use of this background, and eventuallyrequired courses could use it in examples and lab assignments.Thus with the above goals and a proposed course sequence

the committee developed an interdisciplinary course in real-time computing. The rest of this paper discusses the develop-ment, implementation, and trial run of this course.

Course ContentThere were a variety of models for real-time computing

courses to build from. The Electrical Engineering Departmenthad run a course since 1972 [11, [2] and the literature is fullof reports on them. CACHE (Computer Aids for ChemicalEngineering Education) [3] had developed a monograph inreal-time computing. These previous efforts were drawn uponto develop our own course.

0018-9359/81/0200-0069$00.75 © 1981 IEEE

69

IEEE TRANSACTIONS ON EDUCATION, VOL. E-24, NO. 1, FEBRUARY 1981

Chemical Engineering

Civil Engineering

Introduction Real-Time

to - 3> Computing in Electrical Engineering

Computing the Laboratory

Required New Mechanical EngineeringProgramming InterdisciplinaryCourse Course

Metallurgy and

Material Science

Fig. 1. Proposed course sequence.

The previous course taught in electrical engineering waspresented at the senior-graduate level. The basic conceptstaught in this course were recognized as being applicable to

I. Basithe more interdisciplinary new version of the course. Topicsextracted from this course included: assembly language, high- P

Flevel languages, I/O, data structures, and interrupt systems. .NThe CACHE series was more neutral in its development of II. Highassembly language but contained more on interfacing to sensors Band actuators. The course developed contained topics and Eapproaches from both of these courses. III. I/O OThe topics of the course are shown in Table I. The course is

about half computer science and half engineering. It starts off :Owith a section on basic computer organization. The concepts IV. Interof processor, memory, I/O ports, addresses, the fetch-executecycle, and basic assembly instructions and addressing modes Dware covered. The section is meant to give the student a physi- Hcal feel for the computer as a simple, logical machine. A lab- V. Matheoratory assignment is included with this section to gain experi- pence with lab equipment. s

The course then moves to the use of high-level languages by sillustrating the compilation process through some simple VI. Interexamples. See Fig. 2. This is meant both to give the studenta feel for how a program written in a high-level language is Eactually executed on a computer, and to gain more under- V. Estanding of assembly language. Examples such as assignmentstatements and simple while-do loops help make the connec- Dtion between the student's previous programming courses andthe new machine dependent concepts presented in this course.The high-level language introduced at this point sets the stagefor more interesting lab assignments later in the course. the executionExamples of I/O operations are introduced through both (or high-level I

high-level and assembly-level languages. This includes the defi- Simple internition of standard interfaces such as parallel line units and the are then preseidemonstration of sensing and controlling logic voltage levels trations. A lalby the computer. Once these ideas have been developed, better feel foroutput signals from the computer can be used to illustrate of class time is

Proposed Senior LevelProject Courses inEngineering Departments

TABLE ICOURSE ToPIcs

Lc Computer Organization

Processor, memory, registers, I/O ports, addressesFetch-Execute cyclequmber representations

Level Language (The C Language)

Basic language contructs.xtensions for real-time processing

)perations

Cypical devices)perational aspects

:rupt Driven Systems

)efinitionssait-signal diagramslardware mechanism, priority

Nmatical Considerations

'recision, quantization error, scaling,ignal conditioningtability - second order systems,ampling rate

-facing

Cypical hardware - serial line, ADC, DAC, clock.lectrical considerations - DC characteristics

)le Systems

)raws above topics togetherifferent fields of engineering

time of a sequence of assembly instructionslanguage statements).rrupt systems and the motivation for having themnted through the use of the previous timing illus-b problem is assigned early to give the students athis new programming concept. A fair amounts allotted to discussing concurrent processing

70

THOMAS: INTERDISCIPLINARY COURSE IN REAL-TIME COMPUTING

(!globlI. comm.globlcomm.globl. textmain

I

{ jbrL3:L1: jmp. globl. data

a

-a,310i

-i,2_main

r5, csviT144, iL3i,rO

rOa (rO)i ,rO

rOrO,_ iL2

cret

Fig. 2. Compilation example.

systems (systems with multiple active interrupts), modelingtheir behavior, and synchronizing their actions.Whereas the previous topics have mixed engineering (timing,

hardware units) with computer science (new programming

concepts), the rest of the course is mostly engineering. Mathe-matical considerations such as quantization error and samplingrates are discussed. Discrete time systems (difference equa-

tions) are developed through the students' calculus backgroundand their application to real-time systems is demonstrated.The stability of second-order systems is reviewed and thebasic operation of a PID controller is covered.Near the end of the course, class time is spent discussing the

instrumentation of various types of systems. More details ofADC's and DAC's are discussed and a large variety- of trans-ducers is presented (pressure, optical interruptors, temperature,etc.). An example system can be designed in class to illustratekey considerations in the process.

Laboratory UsageAs has been mentioned, laboratory assignments are given to

develop a physical understanding of the topics being presentedin class. Although class lectures often include a discussion ofgeneralities (different methods of performing I/O, differentinterrupt mechanisms, etc.) the laboratories must focus on

the details of using a specific machine, language, and develop-ment system.

It was decided that it is more important for the students to

be provided with the most capable stand-alone computers anddevelopment systems available rather than to teach machinecode of an extremely simple processor. An emphasis of the

course, concurrent with software engineering principles, wasto stress the use of appropriate software tools. As will be seen,

the result was that the students saw the tradeoffs between high-and assembly4evel language software development and were

able to be fairly productive in their laboratory assignments.The stand-alone computer used was the LSI-1 1 and the

development system was the UNIX time-sharing system [4].A discussion of the laboratory facilities can be found in

the next section.

Texts

Several texts were reviewed for the first offering of thecourse. CACHE [3] had a series of notebooks. Stone and

Siewiorek [5] and MacEwen [6] covered the computerscience aspects of the course and used the PDP-1 1 as anexample machine. Cadzow and Martens [7] was considereda good reference for the discrete time systems section. InitiallyStone and Siewiorek [5] was selected as the main text for thecourse and the others were listed as references.

THE LABORATORY FACILITY

When the course was being developed, it was generally under-stood that the digital laboratory facility in the Electrical Engi-neering Department would be used. This facility has beendescribed previously [1] but will be overviewed here.The digital systems laboratory has two main components: a

development system and a set of microcomputers. The labora-tory centralizes the program development facility (whichincludes disks and line printers, etc.) and distributes thesingle-board computers to many lab stations. The centraliza-tion allows for the more expensive mechanical equipment tobe shared during program development. The single-boardcomputers allow for individual student or group use.160 students in groups of two are supported in the "Intro-duction to Digital Systems" course taught by the ElectricalEngineering Department and 60 students doing individual labwork in the Electrical Engineering real-time processing courseare supported.The development system is a UNIX time-sharing system

running on a PDP-1 1/34. The system, including the terminalsand microcomputers, originally cost about $60 000. Thesystem now has five cross-assemblers and two cross-compilers.Programs are downloaded into the microcomputers when thedevelopment phase is complete and the programs are readyto test.Sharing of course software (when permitted) and the com-

munity atmosphere exemplified by volunteers improving usersoftware has enhanced the capability and productivity of theaverage user. In comparison to four or five complete single-user microcomputer development systems (which would be ofequivalent cost), this system has provided a greater flexibilityin lab usage by being more capable of sharing developedsoftware (e.g., a new software translater from the xyz assemblerto the PROM burner), and by providing capable softwaredevelopment tools.During scheduled lab periods, the scheduled lab has priority

use of the system. However, during free periods students areencouraged to prepare programs for their courses on a first-come, first-served basis. Once the students learn the system inone course, extending their use to other courses has been rela-tively easy. Students are now beginning to use the labora-tory outside of their courses for undergraduate projects,research projects and support for their "home computer"systems. Thus the facility has operated as a springboardtoward developing applications in other courses and projects.Experience in the electrical engineering courses show that

the decision to use a very capable development system (morecapable than needed in the electrical engineering introductorycourse) was a good one. Students become interested in the

71

L (int a [ 1001 , i;main ()f F

IEEE TRANSACTIONS ON EDUCATION, VOL. E-24, NO. 1, FEBRUARY 1981

system and strive to learn more rather than being continuallyfrustrated by the limitations of a less sophisticated devel-opment system. Although students initially balk at the ideaof using the system's high-level language rather than assemblyfor real-time processing, they soon realize that their produc-tivity is increased greatly and their assignments are done moreeasily. It appears that these observations also hold true for theinterdisciplinary course.

LABORATORY ASSIGNMENTSThe use of laboratory equipment was considered to be an

important aspect of the course. Lab groups of two studentseach were formed to do the assignments. The laboratorysessions were run by a knowledgeable teaching assistant andconsisted of one three-hour session per week. The UNIX devel-opment system was available during the day for the studentsand they were encouraged to have their programs entered andcompiled before lab. During lab, the LSI-1 l's were availablefor hands-on use.The intended philosophy behind the lab assignments was to

require the least amount of programming to get specific con-cepts in real-time computing across. That is, the courseassumes a programming capability and attempts to illustratethe concepts needed for real-time computing which arebeyond the normal computing course. The successes andfailures of the implementation of the lab assignments will bediscussed in this section.

Implementation of the Lab Assignments14 lab periods were available during the semester and these

were broken up into seven two-period assignments. This gavethe lab groups a chance to fail, regroup, and try again aftera weeks worth of thought. The lab assignments are summarizedin Table II.The first lab (lab 0) was an introductory period which was

used to illustrate the basic hardware operation of a computer.A PDP-11/20 with panel lights and switches was used toshow the operations of load and examine memory, and single-bus cycle through instructions. This lab ties into the con-current class lectures describing the operation of a computer.The students were asked to explain each address and datadisplay generated by the machine in single-bus cycle modeas it executed several given instructions with differentaddressing modes. This lab was very useful.The next four labs were reimplementations of a Fibonacci

number generator. The first lab required them to write andrun an assembly language program on the LSI-1 1. Theprogram was void of I/O and only generated ten numbersin specified memory locations and halted. The students usedthe console odt (octal debugging technique) to examine theresults of the program. Basic concepts covered in this labwere the assembly process, assembly language programs andaddressing modes, and the structure of the machine.The second lab had the students write the same program

using the C programming language. This was an introductionto the C language and its I/O functions (put character,get character, print). The C program was first run on the

TABLE IILABORATORY ASSIGNMENTS

Number

0

3

Topics

Introduction. Lights and Switches.Load and Examine Memory. SingleStep Through Program.

Assembly program with bit manipulation.No I/O. Assembly process.

C language. Run on UNIX and LSI-11.I/O provided by instructors.

Busy-wait I/O. Write I/O functions forabove program.

Interrupt systems. Change busy-wait I/Oto interrupt driven.

Sampling real-time information. "Recordand playback" voice or other signal.Sampling rates, Timer interrupt.

Control of physical systems. Differenceequations. Stop model train at specifiedpoint.

6

UNIX system, and then linked with stand-alone versions ofthe I/O functions and run on the LSI-1 1. The I/O functionswere not written by the students. This lab was successfuland the students gained insight into the compilation processby examining the assembly language generated by thecomputer.The next lab required the students to provide their own

versions of the I/O functions. Busy-waiting for the I/O deviceswas implemented using the C language. The assembly codewas examined and the execution time of certain segmentswas calculated. Some groups had difficulty with this lab.The problems were partially due to their use of addresspointers to keep track of what character to print next(pointers were very foreign to those who only had Basic orFortran), and partially due to the instructors trying to makethe assignment "interesting." It was felt that the lab wouldbe too straightforward if "extras" like back-spacing overincorrect entries were not added. These "extras" onlyclouded the main issue of I/O and should not have beenincluded.

Finally, the students were to reimplement their I/O func-tions using interrupts. Some got their programs to work.However, like the previous lab, only the basics (and probablyonly interrupts on output) should have been asked for.As can be seen, labs one to four were meant to have the

groups concentrate only on specific issues and not write wholenew programs to illustrate I/O. In general, the idea wassuccessful but was tainted by the instructors asking for"extras" that were really unrelated to the main issues.The last two labs involved the sampling of waveforms

generated by physical systems and the control of physicalsystems. The fifth lab had the students sample a waveformand then "play it back." The intention was to enforce thefact that continuous signals could be represented by a set ofdiscrete numbers stored in a machine. The assignment askedfor the groups to sample and replay their voices. However,

72

THOMAS: INTERDISCIPLINARY COURSE IN REAL-TIME COMPUTING

due to sampling rates and the required processing times oftheir programs, the groups were only able to sample and recon-struct slower (500 Hz) signals. Although this was not theintended result of the lab, the concept and limitations ofsampled data systems were well illustrated.The last lab required that they model an N-gauge train as it

circles a loop and then make it stop at a predetermined point.The lab required them to determine the voltage to speed rela-tionship. When the train passed a sensor they were to slow itdown linearly and stop it at a point several inches away.Although most were able to determine the voltage to speedrelationships of the train by computer timing, hardwareproblems with the train power-driver hindered the total com-pletion of the lab.

SummaryIt was generally felt that the labs were illustrative of the

course topics and extremely useful in gaining an understandingof them. In summary:

* The lab problems had to be more specific and well definedthan those which had been used in the electrical engineeringcourse. The students were not as adept at deciding what wasbasic to the lab problem and what was extra. This causedproblems in labs 3 and 4 and may be due to the differencesbetween junior and graduate-level students.

* The better lab problems were the ones which showed thecomputer as a physical device, possibly controlling or sensingother physical devices. Thus the first lab (0), the assemblylanguage lab (1), the first I/O lab (3), and labs 5 and 6,although hindered at times by hardware problems and over-anxious instructors, seemed to convey the most information.The other labs although illustrating course topics were notconsidered "exciting."

* The idea of perturbing only portions of previously writtenprograms remains very valid. The instructors carried this to anextreme by using 4 similar labs. Labs 3 and 4 could have beenchanged to the sensing of some device (say calculating thespeed of a motor shaft). This could have been done once withbusy-wait I/O and then with interrupts.

STUDENT REACTION

The overall student reaction to the new course was good.Although the class size was small, it gave the instructors a

chance to really understand the students' problems. This was

very important in the first trial run of the course.

Students' comments included the following.* The labs were very useful but very time consuming.* The lectures were too general and should have included

more on how to do the labs.* The discrete time math systems (difference equations)

seemed out of place.* The course was useful and some now plan senior projects.The instructors response to these are that they are all under-

standable comments. The first comment is typical of mostcomputer courses and in this case is aggravated by a few prob-lems that were more difficult than intended. The observationsof the previous section should improve the quality of the labs.

The second comment is typical of many laboratory courses.To maintain some generality in education it must always betrue. The third comment indicated that one was not readyfor the math. Indeed the two technicians (who did not makethe third comment) were lost for most of this section.The last comment indicates that at least two plan to try to

use what they learned.The fact that the students were able to complete most of

the labs indicated that some learning was taking place. Thetwo students who received "A's" in the course were probablyas capable as most of the electrical engineering students. Inretrospect this is not surprising in that the basic skill neededin real-time processing is programming. Certainly, electricalengineers are not the only students who understand program-ming. Since the operation of most hardware can be describedin programming like languages (e.g., ISPS [8] ), nonelectricalengineering students can understand these systems.Where these two groups of students diverge is in the under-

standing of how the computer logically works, and howelectrical signals are conditioned for input to the computer(for example, the design of a low-pass filter to prevent aliasing).However, this is acceptable in that most engineers do not com-pletely understand the operation of their test and measurementequipment. This observation might preclude teaching a singleclass for all engineers because the electrical engineering studentswould be better served if the underlying logical operation ofthe computer were tied into the description of how the com-puter works.

CONCLUSIONS

An interdisciplinary course in real-time computing was devel-oped and offered to nonelectrical engineering students. A setof laboratory problem topics was presented and experiencewith them described. Results of the course indicated thatthe students were capable of understanding and programmingreal-time computer systems. Another course offering with alarger enrollment is planned for the next school year.

ACKNOWLEDGMENT

The author would like to thank Prof. C. DeSilva of theMechanical Engineering Department, C. Lupis of the Metallurgyand Materials Science Department, and A. Westerberg of theChemical Engineering Department for their efforts in develop-ing the course. Special thanks goes to Mr. J. D. Northcuttwho ran the laboratory sessions and helped make themsuccessful.

REFERENCES

[1 J D. Thomas, "A laboratory environment for the introduction ofmicroprocessor systems into the electrical engineering curriculum:Methodology and experiences," IEEE Trans. Educ., vol. E-22,May 1979.

[2] J. Grason and D. Siewiorek, "Teaching with a hierarchically struc-tured digital systems laboratory," Comput. Mag., vol. 8, Dec. 1975.

[3] D. A. Mellichamp, Ed., CACHE Monograph Services in Real-TimeComputing. Cambridge, MA: CACHE, 1977.

[4] Bell Syst. Tech. J., vol. 57, July-Aug. 1978.[5] H. S. Stone and D. P. Siewiorek, Introduction to Computer Organi-

73

IEEE TRANSACTIONS ON EDUCATION, VOL. E-24, NO. 1, FEBRUARY 1981

zation and Data Structures. PDP-1 I Edition. New York: McGraw-Hill, 1975.G. H. MacEwen, Introduction to Computer Systems Using thePDP-II and Pascal. New York: McGraw-Hill, 1980.J. Cadzow and H. Martens, Discrete-7ime and Computer ControlSystems. Englewood Cliffs, NJ: Prentice-Hall, 1970.M. Barbacci, G. Barnes, R. Cattell, and D. Siewiorek, "The symbolicmanipulation of computer descriptions; The ISPS computerdescription language," Dep. Comput. Sci., Carnegie-Mellon Univ.,Pittsburgh, PA, 1978.

Donald E. Thomas (S'74-M'77) received thePh.D. degree in electrical engineering fromCarnegie-Mellon University in 1977.He is an Assistant Professor of Electrical

Engineering at Carnegie-Mellon Universitywhere he has taught courses in real-time process-ing and minicomputer systems and presentlyserves as Director of the Digital Systems Lab-oratory. His research interests include theautomatic design of digital systems (synthesis).

An Introductory Course in Microprocessorsfor Freshmen

RICHARD D. KLAFTER

Abstract-Suggestions for faculty who wish to "retrain" and developtheir own course in microprocessors are presented along with theauthor's ideas about selecting a particular microcomputer system forsuch a course. (The AIM-65 in this case.) Class format and the num-ber of students/unit are also discussed. Course structure and contentare described in detail. A week-by-week breakdown of the coursetopics, in class exercises, and home assignments is given. The overal

philosophy underlying the course is that to keep the interest of fresh-men, it is necessary to have a "hands-on" approach. This has proven

to be correct.

INTRODUCTION

NT OT so many years ago, a freshman entering an engineer-ing or science program was taught how to use a slide-rule

so that he could utilize this important tool in other courses.

With the advent of pocket calculators and digital computers,this skill was made obsolete and so was eliminated from thecurriculum. Now, the microprocessor has made its explosiveappearance on the "technology scene" and it is certain thatstudents will need to have an understanding and workingknowledge of this new device. Thus, it seems reasonable thatengineering departments should offer an introductory course

in microprocessors to freshmen so as to provide them withthe necessary background that will be needed as higher levelcourses are inevitably upgraded. In addition, the early appear-

ance in the curriculum of this type of course will be especiallyimportant in schools with cooperative programs (such as

Drexel University), where the employers of "coops" are look-ing for people who have knowledge of this new technology.With the above as background, the purpose of this paper is

to describe a "hands-on" introductory course in micropro-cessors currently offered to freshmen in the College of Engi-

Manuscript received July 18, 1980; revised September 21, 1980.The author is with the Department of Electrical and Computer En-

gineering, Drexel University, Philadelphia, PA 19104.

neering at Drexel University by the Electrical and ComputerEngineering Department. This is a one quarter (i.e., 10 weeks)elective that introduces the students to assembly language pro-gramming and how to use a variety of interfacing devices. Thecourse is one year old, having been offered for the first timein the Spring of 1979. About 150 students have taken itsince then.

GETTING STARTED

Prior to the development of this course, the author had hadsome experience with teaching microprocessors on a theoret-ical basis to senior electrical engineering students. However,it was felt that for the new course to be a success (especiallywhen dealing with freshmen), a "hands-on" approach wouldbe necessary. In order to quickly leam what other peoplewere doing along these lines, the author participated in a threeday short course that was offered in the Philadelphia area bya commercial continuing education organization. This provedto be an extremely useful experience because it provided thebeginnings of a course outline (giving an indication of whatshould and should not be taught to freshmen), ideas on pre-

sentation techniques, an idea of what depth is necessary inorder to convey certain points, and some useful visual andwritten materials. The particular short course was selectedprimarily because of its timing (i.e., the Christmas break) andlocation (i.e., the Philadelphia area), and not for the contentand type of microprocessor utilized (i.e., in this case, the6502 in a KIM-1 microcomputer).In retrospect, a more intelligent approach would be to select

the processor that one wishes to use first and then pick thecourse accordingly. Since this requires some specific back-ground to begin with, this technique may not be practicalfor all people. In any case, the author recommends thatfaculty wishing to "retrain" in the area of microprocessorsshould select a commercial short course that provides "hands-

0018-9359/81/0200-0074$00.75 i 1981 IEEE

[6]

[7]

[8]

74