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:
int analogPin = 0;
int analogValue = 0; // integer to print
void setup() {
Serial.begin(9600);
}
void loop() {
// read the analog input, divide by 4:
analogValue = analogRead(analogPin) /4;
// print in many formats:
// Print the raw binary value analogValue
Serial.print(analogValue, BYTE);
Serial.print('\t');
// print the ASCII encoded binary analogValue
Serial.print(analogValue, BIN);
Serial.print('\t');
// print the ASCII encoded decimal analogValue
Serial.print(analogValue, DEC);
Serial.print('\t');
// print the ASCII encoded hexadecimal analogValue
Serial.print(analogValue, HEX);
Serial.print('\t');
// print the ASCII encoded octal analogValue
Serial.print(analogValue, OCT);
Serial.println();
delay(10);
}
Back to the lab… how can we distinguish between multiple sensors sending back serial?
There are several techniques to choose from:
Punctuation
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 background() 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.)