use of the " " or ' '

Hello, I am starting using bluetooth with Arduino, and I have a problem

#include <SoftwareSerial.h> /
#include <Servo.h>    
Servo servo;          

int led = 13; 
int android;    
 
SoftwareSerial bt(2, 3); 

void setup()
{  
 Serial.begin(9600); 
 bt.begin(9600); 
 pinMode(led, OUTPUT);
 servo.attach(9); 
}
 
void loop()
{
 android = bt.read(); 
 
 if(android == '1'){      
 digitalWrite(led, HIGH);
 
 }
}

In this if:

 if(android == '1'){      
 digitalWrite(led, HIGH);

i would like to use more characters using “” but when I use “” instad of ’ ’ this error appears: SO C++ forbids comparison between pointer and integer
What should I do to use more characters in the comparaison?
Thanks

You have to do comparisons between like data types.

'c' defines a single char "c" defines a string aka a array of char ended with a NULL terminator.

To compare a string you can use strcmp(). But you have to use NULL terminated strings. And I think softserial.read() just returns a byte....

If you use a state machine, you can read incoming characters and compare them to other characters one at a time, as if they were a string. This avoids the necessity for storage of the incoming string.

aarg:
If you use a state machine, you can read incoming characters and compare them to other characters one at a time, as if they were a string. This avoids the necessity for storage of the incoming string.

if i want to use “on” instead of ‘1’ what’s should i change in the code?

yeehaaw: if i want to use "on" instead of '1' what's should i change in the code?

Build a state machine. Or use Serial Input Basics to store the input into an array and use strcmp().

if i want to use "on" instead of '1' what's should i change in the code?

Instead of comparing the single characters one at a time as they arrive, the usual method is to capture the string of incoming characters into a variable of some type. In the below simple test code the characters are captured into a String and then a String function is used to evaluate what was captured.

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

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 == "on")     
    {
      digitalWrite(ledPin, HIGH);
      Serial.println("LED ON");
    }
    if (readString == "off")
    {
      digitalWrite(ledPin, LOW);
      Serial.println("LED OFF");
    }
    readString="";
  } 
}

@zoomkat, I can't believe you're actually recommending the use of the String class. The problems with it are so well known, that it is even documented in the Arduino reference!

aarg: @zoomkat, I can't believe you're actually recommending the use of the String class. The problems with it are so well known, that it is even documented in the Arduino reference!

I've followed this forum for a reasonable length of time and the code issues that many blame on String usage are really due to bad code that c-strings won't fix. As to the arduino references, those references are probably written by the same people that bash Strings on this forum. Just because people write/post/publish things doesn't necessarily make that material correct or factual. Remember the "good book" says the earth was created in seven days. I post code to get people started experimenting with the arduino. Other "c-string" types seem more interested in bashing and taunting the newbies than actually being helpful. YMMV

Well, it's a fact that frequently, threads get started here by people that have mysterious crashing and freezing up of their code. Usually it is recommended that the String class be abandoned, and subsequently the problems go away. That is not bashing, that is helping. The problems with it are fully understood, not based on abstract or religious beliefs.

Also, the validity of a given piece of documentation depends on its accuracy, not who wrote it.

Heap fragmentation is a concrete and problematic issue on a processor with only 2k of RAM, once the heap space begins to dwindle due to fixed allocation and stack allocation. It doesn't take much thinking to see why.

aarg: Well, it's a fact that frequently, threads get started here by people that have mysterious crashing and freezing up of their code. Usually it is recommended that the String class be abandoned, and subsequently the problems go away. That is not bashing, that is helping. The problems with it are fully understood, not based on abstract or religious beliefs.

Well, I'll be watching for the next time you bash String usage without demonstrating is a cause of the issue actually being discussed. Kind of like waiting for dogs to start barking at the moon. 8)

zoomkat: Well, I'll be watching for the next time you bash String usage without demonstrating is a cause of the issue actually being discussed. Kind of like waiting for dogs to start barking at the moon. 8)

Your input is always welcome. In such a case, I would be looking to see whether you can offer a successful solution.

Here's the big picture of the problem: Someone (often a noob, but could be a crossover user from another environment) begins a project. It starts small. They see the obvious convenience and elegance of the String class, so they use it. The project grows, as they see more features and enhancements that are desired or needed. More hardware might be added. It gets bigger. Now they are heavily invested in the String class. It grows some more. Gradually, without warning, the program becomes unstable. There is no error or apparent reason for it. They don't even know whether it is a hardware or software problem. So they post their problem here.

It's a huge sketch, so the most likely cause is pointed out to them, heap fragmentation due to the String class. It's hard to swallow. To change it now, means a complete re-write. Nobody wants to do that. So, often there is denial. Often they sulk away, never to be heard from again. Usually there is too much fixing to do for there to be instant feedback to the forum.

That is why it is important to avoid the class from the very beginning. The alternative method also uses memory, but in a more controlled, measurable way. Then a real error message will alert the programmer that memory is running out. This is especially important for beginners, who are justified in having some doubt about all the components of their program. Making the behaviour more predictable not only makes the program more reliable, but makes troubleshooting easier.

1 Like

. . . and we'll leave it there.