Array to String code behaving awkwardly

You need to go back to using the code I posted, to read packeted data.

Sir,I used your code for Sending packeted data, I loaded the code below in the uC:

char inData[20]; // Allocate some space for the string
char inChar = -1; // Where to store the character read
byte index = 0; // Index into array; where to store the character
int val[4];
int slaveSel = 0;

void setup() 
{
  pinMode(13, OUTPUT);
  Serial.begin(9600);  
  for (int pinNumber = 3; pinNumber <= 7; pinNumber++)
  {//function to read a jumper out of 5 jumpers 
       pinMode(pinNumber, INPUT); 
       if (digitalRead(pinNumber)==1) {
          slaveSel = pinNumber;
       }
  }
}
void loop() 
{
while(Serial.available() > 0) // Don't read unless
    // there you know there is data
  {
    if(index < 19) // One less than the size of the array
    {
	inChar = Serial.read(); // Read a character
	inData[index] = inChar; // Store it
	index++; // Increment where to write next
	inData[index] = '\0'; // Null terminate the string
    }
  }
        String Data = inData;
        if (Data == "on") 
        {
          digitalWrite(13, HIGH);
          index = 0;
          Data = 0;
          for(int i=0;i<19;i++)
          {
	  inData[i]=0;
          }
        } 
        if (Data == "off")
        {
          digitalWrite(13, LOW);
          index = 0;
          for(int i=0;i<19;i++)
          {
	  inData[i]=0;
          }
        }
}

I then wrote "on>" in the Serial Monitor the LED goes on and then i wrote "off>" but it didn;t go off.

I used your code for Sending packeted data, I loaded the code below in the uC:

?

I then wrote "on>" in the Serial Monitor the LED goes on and then i wrote "off>" but it didn;t go off

And that surprises you?
What resets "index"?

And that surprises you?
What resets "index"?

Couldn;t get you Sir.

All i know that it shouldn't be that hard to work it all out, do not know where my mind is flowing.

Think about it.
You receive an 'o', convert it to a String (dunno why), and compare it to "on".
It doesn't, so some time later you receive an 'n'.
You convert it and the 'o' you received into a String, and compare it to "on".
It does compare (hurrah!) so you switch on the LED, and reset the whole buffer (dunno why either).
Then later, you receive a '>'.
It doesn't equal "on" or "off", so you wait some more and receive a 'o'.
Now, you compare ">o" against "on" and "off", but it doesn't compare .
A while later, you receive an 'f''.
">of" still doesn't equal "on" or "off".

And so on, until the End of The Universe.

Sir,I used your code for Sending packeted data, I loaded the code below in the uC:

No, you didn't. My code actually looks for SOP and EOP. You don't have code that does that.

My code doesn't waste resources wrapping the char array in String objects. Yours does.

My code properly resets the buffer when a packet is received. Yours doesn't.

My code doesn't waste resources wrapping the char array in String objects. Yours does.

Sir, Im not wasting resources i did that to print stats on Serial monitor.

My code properly resets the buffer when a packet is received. Yours doesn't.

OK sir but where?

My code actually looks for SOP and EOP

Ok

Sir, Im not wasting resources i did that to print stats on Serial monitor.

Taking a perfectly acceptable C string (that could be compared against a constant string with a simple "strcmp"), and converting it to a String object is wasteful, in my book.
YMMV.

I got it is simply appending the values so when first time there is a ON its only a ON in the inData but the second time when OFF is written then in the variable not only ON is there but also OFF so IF condition evaluates false.

first time putting ON okay its

ON
( as inData has ON only)

second time when one puts OFF
its not only OFF but it is:

ON
OFF

I got it

Not quite.
You reset the buffer as soon as you see "on" so "on" is no longer in the buffer, but then you read the '<'.
Since you never test for this, it stays in the buffer, no matter what else you read in.

Cracked! It's because of the Serial.flush(); it just happened to flush the buffer from what was leftover from the previous Serial entry.

if(Comp("on")==0){
Serial.write("Motor 1 -> Online\n");
for(int i=0;i<19;i++){
inData*=0;*

  • }*
  • index=0;*
  • Serial.flush();*
  • }*
  • if(Comp("off")==0){*
  • Serial.write("Motor 1 -> Offline\n");*
  • for(int i=0;i<19;i++){*
    _ inData*=0;_
    _
    }_
    _
    index=0;_
    _
    Serial.flush();_
    _
    }[/quote]_
    very minimal changes nothing changed except the ARRAY elements/width and removing the following from code:
    _
    *_ <em>* if(index < x) // One less than the size of the array    {          .....;    }*</em> _**_

Cracked! It's because of the Serial.flush(); it just happened to flush the buffer from what was leftover from the previous Serial entry.

So, try that on Arduino 1.0.

So, try that on Arduino 1.0.

Tried in the Serial of Arduino 1.0 working.

Sir, the code is too heavy in Arduino 1.0 its about 3842 bytes about 4kb :fearful: and in 0022 its about 2.7kb

EDIT: 2 problems with using the Arduino 1.0:

  1. Very heavy code, almost double as compared to when compiled in 0022.
  2. Problems flush isn;t that working.

but then there are problems already with the Arduino 1.0 functioning like Wishield's no library works on it, even the library that was good on the 0022.

Tried in the Serial of Arduino 1.0 working.

Well, that's interesting, since the Serial.flush() function on 1.0 only affects outgoing data.

the code is too heavy in Arduino 1.0 its about 3842 bytes about 4kb and in 0022 its about 2.7kb

I'm pretty sure that the Arduino can handle the increased "weight".

I posted the EDIT in my above post.

You are right,Sir, there are problem with Serial.flush() but it works , this function is so smooth in 0022 but jumbles up in 1.0 but works as compared to nothing happening previously.

EDIT:

I'm pretty sure that the Arduino can handle the increased "weight".

I do not like specially this trait of new Arduino 1.0 IDE , i still use a lot of ATmega8's , infact all this that im doing here im testing and working with a ATmega8, what about guys like us?

And does flush still work when you remove the debug prints?

Flush is a sticking plaster fix.
A sticking plaster with added anthrax.

Flush is a sticking plaster fix.
A sticking plaster with added anthrax.

The behaviour of elements is so irrational and haywire that controlling them all the time becomes messy in Serial, This has worked for me pretty nicely achieving what i want! but then i will manage to make it work without flushing stuff.

The behaviour of elements is so irrational and haywire that controlling them all the time becomes messy in Serial,

I couldn't agree less.

I couldn't agree less.

Exactly.

I am a firm believer in the use of start and end of packet markers because they work so well to avoid NI$HANT's issues, with the need for delay() or flushing anything.

I am a firm believer in the use of start and end of packet markers because they work so well to avoid NI$HANT's issues,

Yes YES Sir, I also treat them needy so i incorporated the end markers, they are there in the code.