a digital scan of a 35mm film image of a processing sketch running on an LCD
Skip to Content

Lab: Serial Duplex

Another serial lab, this time about duplex: handling multiple inputs at once.

I don't have an accelerometer handy, and my ultrasonic sensor is giving weird values, so I went with two potentiometers as analog input. Uninspired, but workable.

The multi-format serial print program seems very handy. Shows a number of potential interpretations of the same serial data. Cornflake lets you toggle between different representations of byte data... but I couldn't find a way to get everything side by side at once... maybe I overestimate how useful this is.

I'm keeping the code here for reference:

  1. int analogPin = 0;
  2.  int analogValue = 0;                // integer to print
  4.  void setup() {
  5.    // open serial communications at 9600 bps
  6.    Serial.begin(9600);
  7.  }
  9.  void loop() {
  10.    // read the analog input, divide by 4:
  11.    analogValue = analogRead(analogPin) /4;
  13.    // print in many formats:
  14.    Serial.print(analogValue, BYTE);     // Print the raw binary value analogValue
  15.    Serial.print('\t');                  // print a tab
  16.    Serial.print(analogValue, BIN);      // print the ASCII encoded binary analogValue
  17.    Serial.print('\t');                  // print a tab
  18.    Serial.print(analogValue, DEC);      // print the ASCII encoded decimal analogValue
  19.    Serial.print('\t');                  // print a tab
  20.    Serial.print(analogValue, HEX);      // print the ASCII encoded hexadecimal analogValue
  21.    Serial.print('\t');                  // print a tab
  22.    Serial.print(analogValue, OCT);      // print the ASCII encoded octal analogValue
  23.    Serial.println();                    // print a linefeed and carriage return
  25.    delay(10);
  26.  }

Back to the lab... how can we distinguish between multiple sensors sending back serial?

There are several techniques to choose from:

Put a character between each value, and then send a newline to terminate the "packet" of info. We always know that the first item in the sequence is sensor 0, the second is sensor 1, and so on.

Demo code worked fine, just had to set bgcolor and change the sensor mapping to work well with the pots instead of the accelerometer for which the code was intended. Also made a few aesthetic tweaks: noStroke() and smooth() keeps the ellipse looking nice, and moving backgroung() out of the draw loop gives an etch-a-sketch effect well suited to the potentiometers.

(Worth noting: In Processing, setting myPort.bufferUntil('\n'); handily prevents serialEvent() from firing until a newline character is read.)

Call and Response (Handshaking)

Similar idea, but the Arduino waits for a message from processing before it sends data. More hassle than just sending the data perpetually, but maybe this makes sense when bandwidth is limited (wireless?) or your device has several different modes (e.g. send one byte from processing to request data from one sensor, then a different byte to get data from another sensor.).

Update: The lab explains it... Call-and-response works well when you need to push around binary data. With punctuation only, you risk a collision between your punctuation values and the binary data. Also, if we're reading data slower than it's coming in, the buffer of unread serial data can get too long, which means there will be lag before the most recent data is read. (Investigate this further to figure out why, exactly, the draw() loop is a rotten place to write serial handling code.)

October 20 2009 at 11 PM