Once we hook that up to our computer (using the USB– our friend in the world of Serial Communication :), we try a series of Serial.println to learn the basics of Serial Monitor print-outs and data exchange in the form of binary or ASCII.
This is printing out readings constantly, and we can’t keep track of them, so we learn to implement the HANDSHAKE or “Call & Response” method of Serial Communication to fix this. By adding an “if” statement at the beginning of our loop, we only get the Serial.println IF data is requested– we must send info via the serial monitor to receive a reading (before this, our setup function dictates the monitor will constantly print “hello” until data is requested).
Anyway, this lab does get some creative juices flowing— Serial Communication is really the guts of most of what we’ve been doing so far without realizing it. Understanding more about how it works enables me to think in terms of applicative terms, for instance, in Game Design terms.
Let’s say I want to design a board game with physical cards that have digital components. So you place the cards on the conductive game board, and it reads data, prints it to a digital screen integrated into the board, and then waits for the opposing user to input data before returning the results to each player. This is a simple meditation in order of operations, in terms of information flowing back and forth between two physical objects, via a third physical object. A deeper understanding of serial communication will allow me to execute this physio-digital game board!