No abstract

This paper describes a design methodology useful for team-based (cooperative) and problembased embedded systems education. The design methodology includes a detailed design convention and formalized hardware and code design reviews where the quantity and nature of each design errors are documented. Reviews are held before design implementation and dramatically reduce development time by aborting the far too common cycle of develop, test, change, and test again. The design methodology presented here yields a high-quality product within a short design cycle, while mimicking design methodologies found in industry. Furthermore, data obtained in design reviews can be used to improve the instruction quality and track the maturity of the student design skills. An added benefit of the methodology is development and exercise of the students' teaming and communication skills often neglected by traditional engineering curricula. The proposed methodology has been used in a senior-level embedded systems course at Mississippi State University. In this course, student teams design, build, and troubleshoot a microcontroller-based project composed of common embedded systems peripherals, including I/O and electromechanical devices, industry standard communication networks, and complex digital integrated circuits. The target design is progressive requiring each successive subsystem to be incorporated without disturbing previously completed subsystems. Details of the methodology as it relates to this course offering, sample design review forms, collected data and discussion are presented. Course evaluations were obtained from students and external reviewers, and the results show that offering was well received and achieved its educational objectives.

Demands and stresses on a dual-career couple can be great. When the couple works in the same department, it starts to become difficult to separate professional and person life. Each dual-career couple must work out their own arrangements for dealing with communication, confidentiality, and emotional support. However, each person in the couple must strive from the first day to maintain a separate professional identity and manage the inevitable conflicts of interest that will arise when two people work in such close proximity to each other. The authors share some experiences and advice on dealing with dual careers within the same department. Prologue The quintessential western movie ends with the showdown on the deserted, dusty Main Street. Two gunslingers, a cowboy and a cowgirl, stand nose-to-nose, grimacing with anger and resolve. The duelers stare down each other with steely eyes and dirt-stained faces. The cowgirl with the white hat says confidently, "this town ain't big enough for the both of us". The cowboy, dressed in black from head to toe except the shiny silver belt buckle like a serving tray, responds with "Then, let's do something about it."

Knuth's literate programming paradigm positions source code as a work of literature for which communication to a human is prioritized over communication to a computer. A primary pedagogical value of literate programming lies with the act of writing, especially good writing, leading to good thinking. Issues with early literate programming tool implementations plagued the classroom adoption of literate programming. Advances in technology have warranted a reinvestigation of the benefits of the paradigm. To complement existing inquiry of literate programming in computer programming courses, we investigate, "How can literate programming support student learning in microprocessors and digital system design courses?" In our examination of microprocessors, the instructor used principles of literate programming during in-class demonstrations of assembly programming. In our examination of digital system design, students used the tool to engage in literate programming while writing in a hardware description language. Our results indicated students had a slight preference for instructors to utilize literate programming when presenting in-class examples, and we observed small improvements for graded assignments in sections in which literate programming examples were employed. We also observed a difference in preferences for literate programming by major (computer versus electrical engineering) and noted multiple instructor-observed challenges with introducing a drastically different pedagogical technique in upper-level courses. While our examination did not produce statistically significant results, student and instructor perceptions can be used to guide future literate programming implementations and investigations.