Thomas W. Schultz
Purdue University
Electrical Engineering Technology Department
West Lafayette, IN 47907
For some 20 years the ``microprocessor group'' here in the EET department at Purdue has firmly maintained an emphasis on embedded microprocessors and hardware interfacing. We have avoided the design issues of the processor itself (our students will never design a processor), and have not gotten into design of high-level software such as operating systems. We have insisted that our students are most valuable with a detailed-level perspective on the hardware along with ability to see how that hardware relates to software.
During those 20 years, however, the personal computer (PC) has become such a common device that many technologists in industry now use it merely as a tool. The processor's internal electronics has become hopelessly complex, but at the bus level the hardware is not too complex. Likewise, the operating system has moved from somewhat understandable BIOS calls under DOS to Windows and C++. The software is all developed to isolate the user from any direct interaction with the hardware! All the forces are combining to make the previous emphasis difficult to continue.
There are frontiers in education associated with teaching methods, but there are also frontiers where we try to track rapidly changing subject matter. Most educators agree that we should try to equip our students with the very latest methods and tools.
For technology programs, at least, we need frequent surveys of what is being done ``out there.'' It is very easy, as a teacher, to lose track of what is being done today. What was good practice a few years ago may no longer be economical or competitive with pressures for shorter design cycles and less ground up development.
Industrial advisory committees are useful, not just for accreditation, but also to provide a reality check. To get useful input from such a committee, I have found it best to present it with a specific idea or range of ideas and ask them for feedback. Input by reaction is more specific and useful than waiting for un-prompted input. Your tentative idea is easier for a committee to visualize and compare with current practice back in industry, so the feedback is better.
Keeping current is also best achieved by taking risks. I find that new courses are no fun to develop when I'm not yet an expert. But nothing spurs me on to more personal development better than a group of 20 or 30 students who are expecting answers today!
Other faculty and industrial advisors want a PC-related course and the microprocessor group maintains that detailed hardware issues must be included (but not motherboard and processor system design). As a result, the lab portion of the course concentrates on add-on hardware and the basics of input/output (I/O). That means, for a PC, the standard serial and parallel (printer) ports or the use of the bus (ISA with its extensions or IBM's bus). While quite clever use is sometimes made of the printer port, students should understand the internal bus because it brings in issues of addressing and timing that are more broadly applicable to computer interfacing in general. In addition, add-in devices call for other than the ``standard'' drivers that are associated with the standard ports, allowing more freedom and broadening the experience. Add-in cards are readily available for numerous functions, so they make a good starting point. Students then go on to wire up a custom card of their own design as well-there is no better test of understanding than to have to actually build something and make it work.
This has been a most difficult area for a PC-as-a-tool course. Modern users of add-in hardware expect Windows-type interfaces with impressive graphical screens having buttons to ``push,'' levers to ``slide,'' and windows that show levels or developing graphs of values over time. But this isn't easy. Students coming into this PC course now arrive having taken a course in microcontrollers using assembly language and having taken a first programming course from a software-only perspective (eventually it will be in C, but now it is in BASIC). Even when they will come in with C, with all the new concepts of the Windows API as well the object-oriented concepts of C++ it seems hopeless to expect significant results from students using Visual C++ in a class that also includes hardware issues. Yet staying with C and a DOS interface is clearly obsolete for any new product on a PC. Add to this the likelihood that Windows 3.1 will soon be replaced by Windows NT or Windows 95, and there is no certainty except that things will change.
So we ponder what would constitute the most long-lasting subject matter for this course when the subject changes so rapidly? What software concepts are likely to still be useful in five or ten years? My guess is that designing graphical user interfaces will still be important, so some skill in determining the best user-friendly screens will be of ``lasting'' value. If I can teach how screen layout can minimize human errors and enhance a product, since people do not change nearly as fast as software, this bit of ergonomics might remain valid for quite some time.
An understanding of event-driven programming is inherent to Windows and real-time systems, so it should also remain useful to students years from now. Straight-line programming, the approach of most beginning students-especially ones that are insulated from the hardware-gives no appreciation for multitasking or handling parallel I/O demands at the same time. It is unfortunate that Windows 3.1 does not support real priority-based, preemptive, multitasking, but even with the coarse timing capability of DOS/Windows, the concepts can be taught.
Having discarded Visual C++ as too complex, I still considered conventional C programming for Windows. Again, the complexity of windows interfacing made it undesirable for a short course. For ease of use, I considered Quick BASIC, but it does not really mesh with Windows. Labview and Lab Windows were considered, but they are expensive packages aimed at one set of hardware. (They do carry many of the features that a technologist using the PC as a tool would value.) I finally decided to use Visual BASIC because it is quite easy to learn, it works with Windows, it allows easily customized user interface screens, and it makes the event-driven nature of the software quite apparent. In addition, the software appears to have become an industry standard to the point where many add-on software packages are available, and the other language packages have supported the VB. software.
I hope, in the long term, to refine the course to where the students can write driver software in assembly or C to interface to the high-level software. DLL's and DDE are aspects of hardware/software interfaces that need more attention. Unfortunately, the books in the area are more for practicing professionals than students. Also, the material is usually obsolete within a year or two. It is like standing at the foot of an escalator trying to decide when to step on.
There is a valid place in EET for a course that approaches add-in hardware for a PC from a detailed level while using an easy, but highly graphic language like Visual BASIC.
``Nothing ventured, nothing gained,'' is an excellent motto for a new course. It is important to take chances in order to grow. I've set a specific direction for this course on PCs as a tool by auditing a class from another instructor, by posing the question to the industrial advisory board, and by discussing the course with any the faculty or students who were interested. The final choice favors the simplest software to illustrate long-lasting concepts rather than more powerful software where detailed complex approaches are possible with less being accomplished in a semester.