I’ve read kasper and todbot’s posts about the leds. I am trying to store 4 values in the arduino as well. I am using the code below, in which i expect to see the value for xStep printed. Instead of that I always get 32 returned by the serialmonitor, does anyone know why?

cheers, tim


#define stepPin 26
#define dirPin 28
#define enablePin 24

void stepx_p(){
digitalWrite(stepPin, HIGH);
delayMicroseconds(2);
digitalWrite(stepPin, LOW);
delayMicroseconds(2);
}


NICE post! far the most usable I have seen the past few days on the subject, tnx.. Btw making me a wifi robot :)

 long start_time = millis();

 while(Serial.available()){

   // Permet de rendre la main au reste du programme
     if((millis() - start_time) > 10 )  { // wait at most 10 ms
          break;
        }

      // Lecture du byte arrivé
      byte theByte = Serial.read();
      //Nouvelle trame et que nous sommes pas dans la construction d'une trame ou la trame met trop longtemps a arrivé
      if((theByte == START_TRAME && newTrame == false) || (millis() - DEB_START_TRAME>OUT_OF_TIME_TRAME))
      {
        newTrame = true;
        nbBuf = -1;
        DEB_START_TRAME = millis();
      }
      else {
        // Cas ou nous sommes en construction d'une trame
        if(nbBuf>=BUFFER_SIZE)
        {
          // Cas ou le buffer et plein mais nous il ne s'agit pas de la fin de la trame
          // alors on sait que la trame est corrompu pas besoin de la traiter
          if(theByte != END_TRAME)
          {
             newTrame = true;
             nbBuf = -1;

             for(int i = 0;i<BUFFER_SIZE;i++)
             {
               Serial.print(cmdbuf[i]);
             }
             Serial.println(" Erreur de trame - ");
          }
          else {
             // Verification du checksum car la trame est valide
             // On pointe sur le pointeur cmdbuf

              if(cmdbuf[11] == checkSum())
              {
                // Checksum ok
                      Serial.println("Checksum ok");
                    // Ici la trame est ok donc on peux executer une commande en call back
                    Serial.print("Commande : ");
                    Serial.print(cmdbuf[0]);
                    long val  = ((long )cmdbuf[9]) << 8;
                    val |= cmdbuf[10];
                    Serial.print("Val : ");
                    Serial.print(cmdbuf[9],DEC);
              }
              else {
                // Checksum error $A0000000080I%
                  Serial.print("Erreur dans le check sum : ");
                  Serial.println(cmdbuf[11],DEC);
                  Serial.print("Compute checksum : ");

                  Serial.println(checkSum(),DEC);
              }
          }
          break;
        }
        else {
         //Decodage d'une trame en cours
          cmdbuf[++nbBuf] = theByte;

          Serial.print(nbBuf,DEC);
          Serial.print(" - ");
          Serial.println(theByte);
        }
      }
  }

In human readable way, the packet is : $A0000000080I%
where $ start trame
A command
0000000080 Data
I Checksum
% end trame

How to pass float data ?

But 10 bytes to pass latitudelike -2.153627728 is a good idea?

Thanks

while( Serial.available() < 5 ) {  // wait for 5 bytes
  // do nothing
}

If the host never sends 5 characters, it'll just hang. One wait to get around this is to have a timeout:

long start_time = millis();
while( Serial.available() < 5 ) {       // wait for 5 bytes
  if( (millis() - start_time) < 3000 )  // wait at most 3 seconds
    break;
}

I think it is a big problem to solve.

r.

*Loved* the code for serial communication- many many thanks…

In using it I noticed it was getting so far and it was freezing.. going through the code (Rob re-wrote) I noticed that the malloc was been run and using up all the memory.. so put

free(cmdbuf);

somewhere when you are clearing variables and you shouldn’t have the same problem :D

I tried the method above and I got it working partly. It works almost perfect when I send a message with a keypress action in Processing. However when I trigger the sending code from the draw() function it fails. I tried several framerates ( 1 loop every second ) but that didn’t work out.

By the way, with lower framerates (<10) the keyPress function seems more unstable as well.

It could be Osx Snow Leopard in combination with Processing. Since they fixed serial communication with “duct-tape” for the 1.0.7 release.

Another thing could have been that I send DMX ( and use sei() and cli() to disable interrupts during that time ), however even turning the DMX sending of ( and let Arduino response with the received message ) didn’t help.

Maybe you see any flaws ? Code below is working good when I write the array from the keyPressed function.

Arduino code :

int intensity_Array[72];
int arraylength=72;

byte ledNum;
byte redVal;
byte grnVal;
byte bluVal;  

int arrayStartPos;

void setup()
{ pinMode(11, OUTPUT);
  digitalWrite(13, HIGH);
  Serial.begin(57600);
}

void loop()
{ if( Serial.available() == 4 ) {
    ledNum = Serial.read();
    redVal = Serial.read();
    grnVal = Serial.read();
    bluVal = Serial.read();

    arrayStartPos = ledNum*3;

    intensity_Array[arrayStartPos]   = redVal;
    intensity_Array[arrayStartPos+1] = grnVal;
    intensity_Array[arrayStartPos+2] = bluVal;
  }

  if(ledNum==22)
  { ledNum=0; // set the ledNum to the beginning

    for(int i=0; i<arraylength ; i++)
    { Serial.print(intensity_Array[i]);
      Serial.print(",");
    }
    Serial.println(13);

    /* send frame to led data */
    //cli();
    //sendFrame();
    //sei();
  }

}

Processing code :

import processing.serial.*;

Serial port;
String message = null;              

int counter = 0;

void setup()
{ //frameRate(10);
  println("Opening: "+Serial.list()[0]);
  port = new Serial(this, Serial.list()[0], 57600);
} 

void draw()
{  // running writeArray from here doesn't work
   //writeArray();

   // print the reply from Arduino
   message = port.readStringUntil(13);
   if (message != null) println(message);
}

void keyPressed()
{ writeArray();
}

void writeArray()
{ for( int i=0; i< 23; i++ )
  { writeLed( i, 200, counter*20, 0 );
  }
  counter++;
  if(counter>12) counter=0;
}    

void writeLed( int ledNum, int r, int g, int b )
{ port.write( (byte) ledNum );
  port.write( (byte) r );
  port.write( (byte) g );
  port.write( (byte) b );
}

void loop() {
  if( Serial.available() == 4 ) {
    ledNum = Serial.read();
    redVal = Serial.read();
    grnVal = Serial.read();
    bluVal = Serial.read();
    set_led( ledNu, redVal, grnVal, bluVal );
  }
}

(where “set_led()” is some function you have in your Arduino sketch that does the actual LED handling).

In Processing, the code to set a particular LED to a particular color would look something like:

void setLEDColor( int ledNum, color c ) {
  myPort.write( (byte) ledNum );
  myPort.write( red(c) );
  myPort.write( green(c) );
  myPort.write( blue(c) );
}
void draw() {
  for( int i=0; i< 22; i++ ) { // 22 == number of LEDs
    color c = color( random(), random(), random() );
    setLedColor( i, c );
  }
}

Because this very simple 4-byte protocol has no stop/start byte, it's possible for the Processing sketch and the Arduino sketch to get out of sync. In practice, this rarely happens. ]]>