Serial fixes #4015

Merged
merged 2 commits into from Oct 20, 2015

Conversation

Projects
None yet
4 participants
@gohai
Contributor

gohai commented Oct 18, 2015

No description provided.

gohai added some commits Oct 18, 2015

Fix Serial SimpleWrite example
The Arduino code would read one byte from the buffer an then sleep for 1/10th of a second, while Processing would send a byte every frame. Instead, read in all the bytes in the input buffer and act on the most recent one.
@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Oct 18, 2015

Another potential fix would be putting this code

if (mouseOverRect() == true) {  // If mouse is over square,
    fill(204);                    // change color and
    myPort.write('H');            // send an H to indicate mouse is over square
  } 
  else {                          // If mouse is not over square,
    fill(0);                      // change color and
    myPort.write('L');            // send an L otherwise
  }
}

outside of draw() and into void mouseMoved on the Processing side

REAS commented on 531dbc2 Oct 18, 2015

Another potential fix would be putting this code

if (mouseOverRect() == true) {  // If mouse is over square,
    fill(204);                    // change color and
    myPort.write('H');            // send an H to indicate mouse is over square
  } 
  else {                          // If mouse is not over square,
    fill(0);                      // change color and
    myPort.write('L');            // send an L otherwise
  }
}

outside of draw() and into void mouseMoved on the Processing side

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 18, 2015

Owner

Agree, that'd work too. But the

void loop() {
    if (Serial.available()) {
      val = Serial.read();
    }
    ...
    delay(100);
}

is probably not a good pattern to re-use on its own.. (what I mean: even if the example sent fewer bytes, someone else's sketch will)

Owner

gohai replied Oct 18, 2015

Agree, that'd work too. But the

void loop() {
    if (Serial.available()) {
      val = Serial.read();
    }
    ...
    delay(100);
}

is probably not a good pattern to re-use on its own.. (what I mean: even if the example sent fewer bytes, someone else's sketch will)

This comment has been minimized.

Show comment
Hide comment
@tigoe

tigoe Oct 20, 2015

The code in that example is almost ten years old, and hasn't been synced with the equivalent Arduino examples. So it should change. See https://www.arduino.cc/en/Tutorial/PhysicalPixel for the current version.

Not sure where the delay(100) is coming from, but it's not in the equivalent Arduino example (see https://www.arduino.cc/en/Tutorial/PhysicalPixel). The real dependency is the delay(), of course, and the Serial.read(). It reads one byte at a time. If you read using if(), then the remaining bytes stay in the Arduino's serial buffer until the next read(). I tend to use them both interchangeably. If I'm sending ASCII, then I use Serial.parseInt() (see https://www.arduino.cc/en/Tutorial/ReadASCIIString).

If you use a while() loop, then nothing else happens until you're finished that loop. In this example, that's no problem, but if a person tries to incorporate other things into their code that's timing-dependent, there can be trouble, depending on how fast the sender is sending.

I usually follow this lesson up with a lesson on handshaking, in which Arduino only sends when Processing requests bytes. (See https://www.arduino.cc/en/Tutorial/SerialCallResponse). But I keep them separate, because these are two different concepts, and I find people learn better when a given example introduces only one concept at a time.

I also try to teach people not to use delay() where possible, but instead to use something like this instead:

long lastTime = 0;    // a timestamp to record the last time you did the action in question
int interval = 500;    // a half-second delay. Change to suit your needs
if (millis() - lastTime > interval) {
  // do thing
  lastTime = millis();  // update timestamp
}

Hope that helps,
Tom

The code in that example is almost ten years old, and hasn't been synced with the equivalent Arduino examples. So it should change. See https://www.arduino.cc/en/Tutorial/PhysicalPixel for the current version.

Not sure where the delay(100) is coming from, but it's not in the equivalent Arduino example (see https://www.arduino.cc/en/Tutorial/PhysicalPixel). The real dependency is the delay(), of course, and the Serial.read(). It reads one byte at a time. If you read using if(), then the remaining bytes stay in the Arduino's serial buffer until the next read(). I tend to use them both interchangeably. If I'm sending ASCII, then I use Serial.parseInt() (see https://www.arduino.cc/en/Tutorial/ReadASCIIString).

If you use a while() loop, then nothing else happens until you're finished that loop. In this example, that's no problem, but if a person tries to incorporate other things into their code that's timing-dependent, there can be trouble, depending on how fast the sender is sending.

I usually follow this lesson up with a lesson on handshaking, in which Arduino only sends when Processing requests bytes. (See https://www.arduino.cc/en/Tutorial/SerialCallResponse). But I keep them separate, because these are two different concepts, and I find people learn better when a given example introduces only one concept at a time.

I also try to teach people not to use delay() where possible, but instead to use something like this instead:

long lastTime = 0;    // a timestamp to record the last time you did the action in question
int interval = 500;    // a half-second delay. Change to suit your needs
if (millis() - lastTime > interval) {
  // do thing
  lastTime = millis();  // update timestamp
}

Hope that helps,
Tom

benfry added a commit that referenced this pull request Oct 20, 2015

@benfry benfry merged commit 1470f6c into processing:master Oct 20, 2015

@gohai gohai deleted the gohai:serial-fixes branch Nov 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment