Apologies if this isn't the right forum for this, it's my first post to Processing boards.  In fact, I'm very new to processing.

I am trying to communicate with a PIC 16F876 using RS-232.  I have written a simple program to react to an incoming character on the PIC serial port by echoing the next character in ASCII code (inspired by Tom's example).

This code works using a terminal connected to the PIC (i.e.,
if I send a 'h', I get an 'i' back, etc.).

Using the following processing code (loosely based on Tom's examples), I get no errors but unpredictable results (see output further down).  It's not a baud rate error because PIC, terminal, and processing are all set to 56kbps.  I don't believe it's a settings issue either as 8-N-1 is the default for all three (I believe).  Besides, if that were the issue then the output should be wrong but predictable.
I also don't think it's noise because it works on the terminal and because an 'h' (0d104) should return an 'i' (0d105) but sometimes returns an 'n' (0d110), which is off by 2 bits.

I also note that the code inside serialEvent() never gets executed.  So I'm wondering if it's something very basic in the setup that I haven't figured out.

Any help greatly appreciated.  Code and output follow.

Rob.

----- CODE ------
import processing.serial.*;

Serial myPort;    // The serial port
String myString;  // Variable to hold incoming string values
char   myKey;     // most recently sent data

void setup() {
 
  background(0);
 
  myPort = new Serial(this,56000);

}

void draw() {
 if (myPort.available()>0) {
   myString=myPort.readString();
   if (myString!=null) {
     println(" <> Received: "+myString);
   }  
 }

}  
void keyPressed() {

 if (key==CODED) {}          // don't sent SHIFT, etc.
 else if (key=='s') {        // for debugging to switch to terminal
   println("closing port");
   myPort.stop();
 }
 else if (key=='o') {
   println("opening port");
   myPort = new Serial(this,56000);
 }
 else {
   // Send the keystroke out:
   myPort.write(key);
   myKey = key;
   print("Sent: "+key);
   redraw();
 }
}

void serialEvent() {
 myString = myPort.readString();
 println(" | Received: "+myString);
 }
------- END CODE --------

------- OUTPUT -------
Devel Library
=========================================
Native lib Version = RXTX-2.1-7pre17
Java lib Version   = RXTX-2.1-7pre17
Sent: h <> Received: n
Sent: h <> Received: ~
Sent: h <> Received: ~
Sent: j <> Received: ê
Sent: j <> Received: ~
Sent: j <> Received: ú
Sent: k <> Received: k
Sent: k <> Received: û
Sent: k <> Received: ë
Sent: k <> Received: ë
Sent: k <> Received: k
Sent: g <> Received: g
Sent: g <> Received: g
Sent: g <> Received: g
------- END OUTPUT --------

Thanks for the response.  I added "Serial myPort" to the serialEvent() arguments and they are now triggering (note the '|' in the output rather than a '<>' shows input is being handled by serialEvent() rather than the main draw() loop...see code above).  The output remains incorrect and inconsistent, however, despite rebooting the device after the sketch was started:

Sent: k | Received: û
Sent: k | Received: ë
Sent: k | Received: k
Sent: k | Received: k
Sent: k | Received: ë
Sent: k | Received: û

(recall I am echoing ord+1 so expect a 'l' back)

In the mean time I have written a perl terminal interface to the same device, with no problems.  So I now have hyperterm, the bootloader terminal, and my perl terminal all communicating just fine but processing doesn't work the way I expect.  That's unfortunate since it's a processing sketch that I eventually want to send the information from, and porting the graphics to perl would be...well...difficult.  

Hopefully I'm forgetting some other aspect of initialization or something that someone can help with...

Thanks,
Rob.

Okay.  I'm at a loss to explain that one.

For some reason, the bootloader software for my PIC says it likes to communicate at 56000.  So I set my PIC, terminal, perl program, etc. to 56000.

Yes, switching to 57600 in my PIC code and Processing
code solved the problem.  The same PIC code appears to still work for my terminals, which are all configured at "56000".  Very strange.

At any rate, it seems to have solved the problem.

I may want to increase the baud rate further in the final product.  The PIC will support it and I'm actually using RS485 not 232, so I'm not concerned about distance.  Do you know if the processing library would support higher baud rates than this, and if so what rates?

Thank you!
Rob.

Hmm...thanks.  I couldn't make head or tails of the rxtx site, so I'll just try it out when I get a chance and let you know.

Rob.