c should be equal to what was read with c = Serial.read(), so if I send a 1,2; c should first equal "1", but it does not, in stead I get "end" and the function exits. In fact I will get "end" 3 times, then 25 0's from the array print.

This appears to all be a timing type issue, which makes how the Serial data is handled unreliable. I can get the code working, but I can change the results, or how well it works by adding delay() in different parts of the code, or a simple Serial.print() added here or there will yield different results. It is almost like the data is wiped from the buffer faster than it can be processed or something.

Either I am doing something wrong or there is something wrong with my Arduino. I can't imagine that this issue hasn't happened before because I shouldn't half to adjust how I handle the data based on how many lines of code - thus causing different timings - I have in the program. In otherwords, adding more code shouldn't change my Serial results, but it does.

We need to see your current code. Serial data arrives in it's own time. You have to remove it from the buffer faster than it is placed in the buffer, or you will begin loosing data. delay()s and Serial.print()s cause it to take longer to read all the data.

If you are sending less than a buffer's worth of data, though, you could take all day to read the data, and not risk loosing data.

That you are having such difficulties means that the problem is in your code. Post it again.

We need to see your current code. Serial data arrives in it's own time. You have to remove it from the buffer faster than it is placed in the buffer, or you will begin loosing data. delay()s and Serial.print()s cause it to take longer to read all the data.

This is what I am currently working with. It is working but I don't feel confidant that it is correct.

You should only be printing index values, here. You know how many you received. After using/printing the values, some initialization would be a good idea. Wiping the values from iData, for instance. iData is a lousy name, by the way. It gives no clue what is in the array.

This indicates that every other Serial.read() results in a -1 null character instead of reading the next character.

There is serial available so the function is called, c is loaded with Serial.read() and it is printed as 49 (char '1'), the while loop is no over so c is read again, but this time it is -1 instead of the next character in line to be read There is still data avail so the main loop calls ReadData() again, then 50 is printed, but again the next character read is -1, so on.

That's precisely what I'd expect you to get.Serial comms are SLOW, you can whip around your while loop loads of times in the time it takes to receive one character (in fact, it's only your serial prints that are slowing you down)

Quote

This indicates that every other Serial.read() results in a -1 null character instead of reading the next character.

No, Serial.read returns -1 when there is nothing there to read, i.e. nothing has been received. (-1 is most definitely NOT null)

Follow your code through:In loop, suddenly "available" returns 1 because a character has just been received.Call ReadData, set c to zero, test to see if c is a semicolon (it isn't), so read the character that just came in.it isn't -1, so print it.Go back to the top of the while, see if the character was a semicolon.It wasn't a semicolon, so read the the next character.Oh dear. It hasn't arrived yet.

"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.Do not send technical questions via personal messaging - they will be ignored.

That's precisely whaty I'd expect you o get.Serial comms are SLOW, you can whip around your while loop loads of times in the time it takes to receive one character (in fact, it's only your serial prints that are slowing you down)

See, I thought that from the very beginning, So I removed the serial printing and made it only print when nothing else was going on just to verify the data. all I got back was 0's as if nothing had been stored. I could only get the data to store if I printed it right away. So I need to verify that there is actually a character present before reading that character.

Follow your code through:In loop, suddenly "available" returns 1 because a character has just been received.Call ReadData, set c to zero, test to see if c is a semicolon (it isn't), so read the character that just came in.it isn't -1, so print it.Go back to the top of the while, see if the character was a semicolon.It wasn't a semicolon, so read the the next character.Oh dear. It hasn't arrived yet.

I am seeing that now, the Serial port is very slow which explains why when I add Delays I can get it to work - but that's not the right way to do it.

I guess I should have just asked the question,How do I separate a string of data? For example I will be receiving something like this,345,234,532,231,426,63,312,4,523,543;How do I tun it into Data[0] = 345Data[1] = 234Data[2] = 532etc etc?

If I use while(Serial.available()) the wile loop exits before the next character come in. if I check for a ending character ';' I could get stuck in a loop. I agree that counting the loops is a cheesy way of doing it, guess I will half to compare mils to make sure it's not taking too long.

Oh, by the way everyone, I really appreciate the help and head knocking

You don't need to add a timer or something like that, because you only read once after serial.available(), if there are more characters in the serial buffer, you will read the next one in the next loop round.