next topic »

[Reply #30 on:]

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

[Reply #31 on:]

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.

[Reply #32 on:]

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

[Reply #33 on:]

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.

[Reply #34 on:]

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();
  }

very minimal changes nothing changed except the ARRAY elements/width and removing the following from code:

Code:

if(index < x) // One less than the size of the array
    {
          .....;
    }

[Reply #35 on:]

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.

[Reply #36 on:]

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   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.

[Reply #37 on:]

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".

[Reply #38 on:]

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?

[Reply #39 on:]

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

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

[Reply #40 on:]

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.

[Reply #41 on:]

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

I couldn't agree less.

[Reply #42 on:]

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.

[Reply #43 on:]

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.