skip to main content

Title: Pin Status: An Arduino Debugging Library for High School E-textile Courses
When learning to code a student must learn both to create a program and then how to debug said program. Novices often start with print statements to help trace code execution and isolate logical errors. Eventually, they adopt advance debugger practices such as breakpoints, "stepping" through code execution, and "watching" variables as their values are updated. Unfortunately for students working with Arduino devices, there are no debugger tools built into the Arduino IDE. Instead, a student would have to move onto a professional IDE like Atmel Studio and/or acquire a hardware debugger. Except, these options have a steep learning curve and are not intended for a student who has just started to learn how to write code. I am developing an Arduino software library, called Pin Status, to assist novice programmers with debugging common logic errors and provide features specific to the e-textile microcontroller, Adafruit Circuit Playground Classic.
Authors:
Award ID(s):
1742081
Publication Date:
NSF-PAR ID:
10163644
Journal Name:
SIGCSE '20: Proceedings of the 51st ACM Technical Symposium on Computer Science Education
Page Range or eLocation-ID:
1429 to 1429
Sponsoring Org:
National Science Foundation
More Like this
  1. Today’s STEM classrooms have expanded the domain of computer science education from a basic two-toned terminal screen to now include helpful Integrated Development Environments(IDE) (BlueJ, Eclipse), block-based programming (MIT Scratch, Greenfoot), and even physical computing with embedded systems (Arduino, LEGO Mindstorm). But no matter which environment a student starts programming in, all students will eventually need help in finding and fixing bugs in their code. While the helpful IDE’s have debugger tools built in (breakpoints for pausing your program, ways to view/modify variable values, and "stepping" through code execution), in many of the other programming environments, students are limited tomore »using print statements to try and "see" what is happening inside their program. Most students who learn to write code for Arduino microcontrollers will start within the Arduino IDE, but the official Arduino IDE does not currently provide any debugging tools. Instead, a student would have to move on to a professional IDE such as Atmel Studio or acquire a hardware debugger in order to add breakpoints or view their program’s variables. But each of these options has a steep learning curve, additional costs, and can require complex configurations. Based on research of student debugging practices[3, 7] and our own classroom observations, we have developed an Arduino software library, called Arduino Debugger, which provides some of these debugging tools (ex. breakpoints) while staying within the official Arduino IDE. This work continues a previous library, (redacted), which focused on features specific to e-textiles development boards. The Arduino Debugger library has been modified to support not only e-textile boards (Lilypad, Adafruit Circuit Playground) but most AVR and ARM based Arduino boards.We are also in the process of testing a set of Debugging Code Templates to see how they might increase student adoption of debugging tools.« less
  2. Comprehending programs is key to learning programming. Previous studies highlight novices’ naive approaches to comprehend ing the structural, functional, and behavioral aspects of programs. And yet, with the majority of them examining on-screen program ming environments, we barely know about program comprehension within physical computing—a common K-12 programming context. In this study, we qualitatively analyzed think-aloud inter view videos of 22 high school students individually comprehending a given text-based Arduino program while interacting with its corresponding functional physical artifact to answer two questions: 1) How do novices comprehend the given text-based Arduino pro gram? And, 2) What role does themore »physical artifact play in program comprehension? We found that novices mostly approached the program bottom-up, initially comprehending structural and later functional aspects, along different granularities. The artifact provided two distinct modes of engagement, active and interactive, that supported the program’s structural and functional comprehension. However, behavioral comprehension i.e. understanding program execution leading to the observed outcome was inaccessible to many. Our findings extend program comprehension literature in two ways: (a) it provides one of the very few accounts of high school students’ code comprehension in a physical computing con text, and, (b) it highlights the mediating role of physical artifacts in program comprehension. Further, they point directions for future pedagogical and tool designs within physical computing to better support students’ distributed program comprehension.« less
  3. One aspect of developing correct code, code that functions as specified, is annotating loops with suitable invariants. Loop invariants are useful for human reasoning and are necessary for tool-assisted automated reasoning. Writing loop invariants can be a difficult task for all students, especially beginning software engineering students. In helping students learn to write adequate invariants, we need to understand not only what errors they make, but also why they make them. This poster discusses the use of a Web IDE backed by the RESOLVE verification engine to aid students in developing loop invariants and to collect performance data. In additionmore »to collecting submitted invariant answers, students are asked to provide their steps or thought processes regarding how they arrived at their answers for each submission. The answers and reasons are then analyzed using a mixed-methods approach. Resulting categories of answers indicate that students are able to use formal method concepts with which they are already familiar, such as, pre and post-conditions as a starting place to develop adequate loop invariants. Additionally, some common trouble spots in learning to write invariants are identified. The results will be useful to guide classroom instruction and automated tutoring.« less
  4. Debugging is an important skill all programmers must learn, including preliterate children who are learning to code in early childhood settings. Despite the fact that early learning environments increasingly incorporate coding curricula, we know little about debugging knowledge in early childhood. One reason is that the tangible programming environments designed for young children entail a layer of material complexity that we have yet to account for in terms of learning to debug. In our study of young children learning to program, we found that in the midst of solving programming tasks and learning to debug, tangible toys presented bugs ofmore »their own. This paper analyzes video of Kindergarteners learning to debug errors in the program and errors in the physical materials. We argue that concurrent physical and programming bugs present opportunities for young children to learn about the broader computational system in which they are learning to code.« less
  5. Programming games provide players opportunities to practice and learn the fundamentals of coding in engaging ways. Many games have players program in block-based languages similar to environments like Scratch and Snap! as a means to scaffold student learning and reduce syntax errors. Block-based environments (BBEs) have been praised for their open-ended, constructionist designs allowing students to develop what they wish, express themselves, and explore the possibilities of the system. However, programming games tend to be more linear, usually designed as a fixed series of puzzles. We present Resource Rush, a game designed to resemble BBEs and present users with amore »game world that allows users to learn the fundamentals of programming in an open-ended game environment.« less