Serial data problem when using Tx/Rx pins

Hi,

I'm a long-time programmer, but new to Arduino. I have an Arduino Uno R2 and am trying to connect it to my iPhone using the Redpark Serial cable and the Sparkfun RS-232 Shifter SMD but am having problems passing data between the two.

I have a pretty simple sketch:

void setup() 
{
    Serial.begin(9600);   
    Serial.println("Arduino reset");
    Serial.flush();
}


void loop() 
{
  if (Serial.available() > 0)
  {
    int n = Serial.read();
    Serial.println(n, HEX);
    Serial.flush();
  }
}

If I run this and test with the Serial Monitor via USB, I get exactly what I expect: the 'Ardiuno reset' message and then the ASCII values for each character typed, plus the newline.

If I then use the Redpark cable together with the Redpark demo app to echo back the text I enter, I see the words 'Arduino reset' correctly, but text that I enter is not echoed back correctly. If I send the text 'abcdef', for example, I get

6B B5 B7 77 DF EB BB

echoed back. If I send the same text again, I get a completely different set of values returned. I seems like there's random noise appearing from somewhere, but only if I use the Tx/Rx pins - not when I use the USB connection. I've configured the connection as 9600 baud, 8N1. The fact that the 'Arduino reset' text displays just fine suggest the serial port is configured correctly, and so I suspect it's the data being that the Arduino is receiving is incorrect.

If I unplug the Tx/Rx leads from the Arduino and connect them together, I get the text echoed back correctly, so I'm pretty confident the cable and the RS-232 shifter are all working correctly. It's when I connect them to the Arduino that things go awry.

I've tried everything I can think of now and can't see anything else I might be doing wrong. The only thing that occurs to me now is that the Ardiuno itself may be faulty. Does that seem a likely possibility, or am I just doing something dumb somewhere?

Any suggestions would be gratefully received.

try

    Serial.write(Serial.read());
    Serial.flush();

Serial.write(Serial.read()); Serial.flush();

I get exactly the same data corruption issues.

for each character you type in iphone, how many characters are echoed back using the write(read) code? how about try removing the two flush command.

I assume your iphone serial setup is correct (baud rate, 8n1, no handshake, etc).

Why are you calling Serial.flush() at all? Which version of the IDE are you using? That determines what Serial.flush() does. That should be enough to make you wonder whether you should be calling it at all.

for each character you type in iphone, how many characters are echoed back using the write(read) code?

Just one

I assume your iphone serial setup is correct (baud rate, 8n1, no handshake, etc).

As far as I can tell, yes

Why are you calling Serial.flush() at all?

I wasn't originally, I added it during troubleshooting just to be sure there wasn't data lurking in some buffer somewhere. I'm using 1.0 and as I understand it, that version of flush should wait for the buffer to empty. I've just removed the calls to flush() just to be sure, and the behaviour remains the same.

I’m using 1.0 and as I understand it, that version of flush should wait for the buffer to empty.

True. Which, as you can see, does nothing for you. So don’t use it. The Serial.print()/Serial.write() functions will block automatically if there is not enough room in the buffer.

Prior to 1.0, Serial.flush() threw away random amounts of unread data. That would not help you, either. So, again, I would have said to get rid of it.

The Serial.read() function returns an int, so that it can use the sign bit in the high order byte to indicate an error condition, while using the low order byte to contain the data read, in the event of success.

Since you always check that there is data to read, the Serial.read() function will always succeed, so, you should be storing the return value in a char, and Serial.print()ing that char. There is no reason to convert the int to a string, in HEX format.