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.
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".
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:
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.
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> _**_
Sir, the code is too heavy in Arduino 1.0 its about 3842 bytes about 4kb and in 0022 its about 2.7kb
EDIT: 2 problems with using the Arduino 1.0:
Very heavy code, almost double as compared to when compiled in 0022.
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.
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?
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.
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.