Test for a Serial.read() string

Using Arduino Project Guidance
1

Hi, I am trying to create a text-based game for Arduino using an LCD shield and so far it works, however, I cannot seem to find out how to compare a Serial.read() string ( e.g. "if (Serial.read() == 'go west') { code code code }" ). Is it possible to compare an entire string to Serial.read()?

Thanks, Parzivail

2

No Serial.read reads a single character. You have to do the parsing yourself. One way to do this is to store characters in an array, and use strcmp, when you've gotten enough characters. Note, on a traditional Arduino, you probably want to use the PROGMEM facility to put the strings you are matching against into program memory to save your precious SRAM. You will need to worry about whether your buffer is large enough, and what to do about illegal inputs.

Other ways are to parse the string on the fly. This might be faster than using strcmp, but generally if you are waiting for humans to type something, you probably don't need to optimize for speed.

3

I've used the StringIndexOf function to look for a particular character string in a captured String like below.

// zoomkat 8-6-10 serial I/O string test
// type a string in serial monitor. then send or enter
// for IDE 0019 and later

//A very simple example of sending a string of characters 
//from the serial monitor, capturing the individual 
//characters into a String, then evaluating the contents 
//of the String to possibly perform an action (on/off board LED).

int ledPin = 13;
String readString;

void setup() {
  Serial.begin(9600);
  pinMode(ledPin, OUTPUT); 
  Serial.println("serial on/off test 0021"); // so I can keep track
}

void loop() {

  while (Serial.available()) {
    delay(3);  
    char c = Serial.read();
    readString += c; 
  }

  if (readString.length() >0) {
    Serial.println(readString);

    if(readString.indexOf("on") >=0)
    {
      digitalWrite(ledPin, HIGH);
    }

    if(readString.indexOf("off") >=0)
    {
      digitalWrite(ledPin, LOW);
    }

    readString="";
  } 
}
4

zoomkat:
I've used the StringIndexOf function to look for a particular character string in a captured String like below.

int ledPin = 13;

String readString;

The problem of using the String class is it uses dynamic allocation. In a hosted environment where you have plenty of memory, this isn't as much of a problem (though the program is still inefficient IMHO). However, in the Arduino environment, you don't have much SRAM and you potentially will run out of memory. In addition, if you are not using 1.0.5 of the Arduino IDE, there is a serious bug in the library that means you run out of memory more often.

5

if you are not using 1.0.5 of the Arduino IDE, there is a serious bug in the library that means you run out of memory more often.

Just for a creditability check, weren't the memory loss issues corrected in version 1.0.4?

6

weren't the memory loss issues corrected in version 1.0.4?

The bug in free() that corrupted the stack was fixed. The way that String potentially fragments memory is still present.

7

zoomkat:

if you are not using 1.0.5 of the Arduino IDE, there is a serious bug in the library that means you run out of memory more often.

Just for a creditability check, weren't the memory loss issues corrected in version 1.0.4?

It looks like there were two fixes to malloc. The fix in 1.0.4 from Paul Stoffregen fixed the serious bug, but 1.0.5 had a merge from avr-libc 18.0 to fix another malloc problem. I stopped when I was looking through the ChangeLog at the first malloc fix, but the 1.0.4 fix was the one that everybody hit with the String class.

I think to think that the Arduino team should never have included the String class in the Arduino library, since dynamic allocation really does not make sense in a small memory environment.

In addition, the program segment does not work if second character to be read is not immediately available after the first character has been read, since the string will be reset immediately once the first loop that reads the characters finishes (i.e. no character available), and then it goes to test whether "on" or "off" appears somewhere in the string.

ARDUINO 1.0.5 - 2013.05.15

[core]

  • [avr] malloc bug: backported avr-libc 1.8.0 implementation
  • [avr] removed deprecated interrupt handlers causing compiler issues
    with newer avr-gcc.
  • [avr] added c_str() method to String
  • [avr] Stream "_timeout" field and related methods are now protected

[libraries]

  • Upgrades to WiFi library
  • Fixed a bunch of examples
  • Added Arduino Robot libraries
  • Added TFT display library

[firmwares]

  • Upgrades to WiFi firmwares

[ide]

  • Backport from 1.5: install Library from .zip file or folder
  • Updated windows drivers
  • Added Windows installer

ARDUINO 1.0.4 - 2013.03.11

[core]

  • Fixed malloc bug (Paul Stoffregen)

[libraries]

  • Fixed memory leak when calling Ethernet.begin() multiple times.
  • Fixed SD example listfiles.ino
  • Fixed a lot of Esplora examples
  • Added GSM library

[environment]

  • Sort entries in preferences.txt (Shigeru Kanemoto)
  • Fixed some wrong translations
  • Fixed NPE due to permissions IO error
  • Updated drivers for Windows (all-in-one, signature for Win8)

[bootloaders]

8

MichaelMeissner:
I think to think that the Arduino team should never have included the String class in the Arduino library, since dynamic allocation really does not make sense in a small memory environment.

Yes, it was IMO a misguided decison. I suspect it was driven by the same motivation that I guess was behind the peculiar .ino/.cpp pre-processing that was bodged on top of the standard compiler - a desire to run something close to Java on a platform that was obviously not capable of running Java.

9

I think to think that the Arduino team should never have included the String class in the Arduino library, since dynamic allocation really does not make sense in a small memory environment.

The string class makes good sense for new or non coders like me. For me Strings is much easier to understand and use than the cryptic C functions. Properly written code within the limits of the arduino should not have memory issues no matter what coding format is used.

In addition, the program segment does not work if second character to be read is not immediately available after the first character has been read, since the string will be reset immediately once the first loop that reads the characters finishes (i.e. no character available), and then it goes to test whether "on" or "off" appears somewhere in the string.

??? If you are referring to the code I posted, using the 3ms delay between serial input buffer reads and receiving on the serial port at 9600 baud from the serial monitor works on my machine. Doesn't work on your machine under the same conditions? Hmmm... Note that the code I posted was to show the use of the String functions and not the methods of serial data transport.