Rotating Text Marquee. Stephen Rochelle, CoE Mark Randall, EE University of Evansville

Transcription

1 Rotating Text Marquee Stephen Rochelle, CoE Mark Randall, EE University of Evansville Presented at 2003 MUPEC Student Paper Conference April 26, 2003

2 Virtually all experts agree that demand for computer engineering majors will continue to increase over the next several years. A persistent problem exists, however, in attracting prospective computer engineering majors; namely, illustrating to a high school student what computer engineering is. For example, at the University of Evansville, a prospective student visiting the College of Engineering and Computer Science can reasonably envision the architectural and structural applications of civil engineering, various portions of a mechanical engineering project like the mini-formula 1 car, or web application development in computer science. Succinctly, simply, and meaningfully describing computer engineering areas like embedded software, real-time programming, or branch prediction design often, bluntly, fails miserably. The Rotating Text Marquee (RTM) has been envisioned as an effective illustration and explanation of computer engineering principles that provides a readily perceptible, demonstrable effect. The RTM relies on ocular retention the tendency of the human eye to remember and prolong the visual perception of brief high-contrast events. The afterimage left by a lightning bolt is an excellent example of relevant natural phenomena, while a camera flash provides a slightly more accurate analogy. An RTM printed circuit board mounts a single line of light-emitting diodes (LEDs) along the radius of a Lexan circle. The Lexan is then mated with a motor and spun between 1000 and 2000 rpm. A microcontroller onboard uses microsecond-specific timing to flicker the LEDs in such a pattern as to be an apparent two-dimensional display consisting of hundreds of points of light suspended in midair. In the current application, the display consists of programmer-defined ASCII text oriented such that no letters are upside-down.

3 The RTMs hardware is centered around its microcontroller, a Philips 89C51RD2. The RD2 is a variant of the Intel bit microcontroller, its primary advantage being its (relatively) gigantic allocation of Flash ROM for storing code (Table 1). The RD2 is Core Clock Speed 2 MHz RAM 256 Bytes ROM 64 Kilobytes (Flash ROM) I/O Ports 4 8-bit Timers 3 16-bit Interrupts 2 External, 3 Timer, 1 Serial, 1 PCA Programmable Counter Array (PCA) 5 Channels Counter, Comparator, Timer, PWM Modes Table 1: Philips P89C51RD2 Features Overview coupled with the circuitry needed to perform in-system programming, helping to speed the development process and reduce the risk of accidental processor damage. The remaining hardware on the PCB consists of 16 LED transistor resistor groups, broken into two sets of eight, and a Hall Effect sensor. Two identical PCBs are mounted opposite each other to allow the RTM to effectively double its refresh rate. In unusual fashion, the RTM s motor is mounted on the spinning portion of the apparatus with the shaft fixed to the unit base. While at first appearing ungainly, the arrangement places the motor control directly beside the processor, allowing for starts, stops, and other speed changes in software. Additionally, the shaft retains enough room to mount a pair of slip rings suitable for transferring power to the RTM from an external DC source. The Hall Effect sensors are without question the key to successfully generating and maintaining the illusion. With a powerful magnet mounted at the 3 o clock position on the RTM base, each Hall Effect sensor provides a pulse to its host processor on

4 External Interrupt 0 (EX0). To boost resolution, each EX0 pin is then tied to the External Interrupt 1 (EX1) pin of the other processor (Fig. 1). Thus, when EX0 is tripped on HES1 HES2 EX0 EX0 CPU1 EX1 EX1 CPU2 Figure 1: Hall Effect Sensor Cross-Linkage Board A at the 3 o clock position, Board B sees EX1 trip at the corresponding 9 o clock position. By crossing the connections from EX0 to EX1, each board can continue to run identical code EX0 corresponds to 3 o clock on each board. This could also have been accomplished by placing a second magnet at the 9 o clock position of the base, but this strategy has flaws. First, a second Hall Effect sensor is needed for each board, since they no longer share. Second, precise placement of the magnet is required to make sure each half is exactly 180. Without such placement, subsequent calculations of rotation time become flawed. Furthermore, since the Hall Effect sensor operates because of invisible electromagnetic forces, precise positioning cannot be simply measured with a ruler. Software for the RTM emulates a multi-threaded environment with a barrage of interrupt service routines (ISRs). After initialization, the main code thread relegates itself to continuous background recomputation of display timing, passing all other functions to the various system interrupts (Fig. 2). Of the interrupts, the above mentioned EX0 and

5 EX0 ISR 3 O Clock HES Pulse EX1 ISR 9 O Clock HES Pulse PCA ISR Spin Timer (27-bit) Check Timer Pulses MAIN CODE Calculate Blink Delay T2 ISR Real-Time Clock Time Per Half-Revolution Interrupt Rate Update Display Mode T1 ISR Display Routine Figure 2: Software Block Diagram EX1 each signal the main code block to pull new revolution timing data. That timing is generated with an amalgamation of resources. The PCA master clock serves as the primary 16-bit timer. To slow its clock rate, Timer 0 (T0) is set to roll over at 2 usec intervals, one-quarter the speed of the 2 MHz core clock. The PCA then clocks off the T0 overflow. Finally, the PCA overflow triggers an interrupt incrementing an 8-bit counter. With proper interpretation of the data, this gives the processor what would ordinarily be a 27-bit counter good for a revolution rate of less than one rpm! This timing data is eventually compressed into a 16-bit variable which the main code segment separates into high and low bytes for use by Timer 1. The Timer 1 ISR is responsible for the actual flickering of the LEDs. The display of a particular ASCII character is broken into six apparent columns of eight LEDs. To write the bit mapping necessary, the ISR cross-references the current line, character, and sub-character column against a massive array stored in code space using the following

6 statement: P1 = CharMap[line][line[line][char] - offset][char_subpos]; Supposing that the variable line[0]= test was to be displayed, and that the routine was midway through displaying the s. Substituting arguments would yield or P1 = CharMap[0][line[0][2] 0x20][2]; P1 = CharMap[0][ s 0x20][2]; with the 0x20 representing the offset from the beginning of the ASCII set (index 0) to its first printable character (index 32). This, at last, yields P1 = CharMap[0][0x53][2]; The relevant section of CharMap appears as follows: unsigned char code CharMap[4][119][6] = { { // line 0 {... }, {0xFF, 0xDF, 0xAB, 0xAB, 0xAB, 0x7F}, // s... } } Finally, then, the statement arrives at P1 = 0xAB; the bit pattern needed for the third column of the s character on the top row. Due to space constraints, all four rows possess different top-to-bottom bit orders. While more complex than desired, the resulting enlarged size of the lookup array isn t a significant design concern; even quadrupled in size it poses no threat to the 64KB Flash segment. To simplify the process of reasoning through an active-low irregular-bit-order array with thousands of elements, a separate C program was written to transpose a standard active-high linear-bit-order ASCII set into the four patterns required by the RTM. Once that output was successfully generated, it was a simple task to add basic

7 formatting to the data. As an end result, the program now automatically generates the entire C file used by the microcontroller compiler to hold the lookup array, easily reducing the amount of time needed to create a font by an order of magnitude. Finally, the RTM lends itself to further enhancement by future students. As noted earlier, the motor shaft has space for slip rings and brushings to supply power. At present, attempts to fabricate such equipment have fared poorly. The RTM therefore currently powers itself with two banks of 4 AA batteries, one for the processors and one for the motor and LEDs. The motor / LED battery bank exhausts itself in half an hour, clearly unacceptable for a long-term solution. However, with the twin power bus, external DC could easily be adapted in given the slip rings and brushings. While such a dirty power source would render the microcontrollers useless, it would easily serve for powering the motor and LEDs. With the current design, though, the microcontrollers can remain independently on a single battery bank with a lifetime of weeks. Additionally, the RTM could be equipped with a remote control decoder module on a daughterboard with almost no changes to the current PCBs. Such an addition would allow for end-user controlled motor starts and stops and a far more friendly means of changing the displayed message. The RTM has fulfilled its primary expectation beyond our original hopes. Not only an object of interest to passers-by and the electrically uninitiated, it stole the show of the most recent Evansville / Owensboro IEEE Section meeting, drawing far more interest than the keynote presentation of student-designed autonomous robot projects. Various principles of hardware and software design, as well as the synthesis of the two so defining of computer engineering, are clearly, quickly, and vividly revealed, sparking questions and conversations at every level of expertise.