Coincido con Lucario448, estás usando String para algo que puedes resolver fácilmente con char *. Y siempre que puedas, en microcontroladores, evita las String. Pueden llegar a consumir demasiada memoria.
También a mi me surge la duda de si inicializas la variable
i
. También falta poder ver cuándo y cómo inicializas posini.
Ayudaría también ver cómo has declarado las variables. Vamos, que sin todo el código (o buena parte de él) es más difícil saber qué puede estar pasando.
Aún así, hay una cosa que "salta a la vista" en la línea:
buff[Serial1.readBytesUntil('#',buff, sizeof(buff))]=0;
Debería de ser:
buff[Serial1.readBytesUntil('#',buff, sizeof(buff) - 1)]=0;
E incrementar en uno el tamaño de buff en su definición.
¿Por qué? Pues porque, tal como lo tienes, readBytesUntil pone en buff los bytes que lee del puerto serie hasta que se encuentra un '#' o ha leído sizeof(buff) bytes sin encontrar lo que busca. Hasta ahí todo bien, porque readBytesUntil no te va a leer más bytes de los que cabe en buff, como mucho lo va a llenar si no encuentra antes lo que busca. El "problema" lo tienes después, con la parte buff[ ]=0. Esto está para que "la cadena" termine con un carácter nulo (el valor cero). Para ello lo que hacer es usar como índice el valor retornado por la función readBytesUntil y ahí poner el cero. Por ejemplo, si los caracteres que lee con abcd#, mete en buff abcd (el carácter buscado se descarta) y retorna un 4, que es el número de bytes que ha metido en buff. Luego se "ejecutará" el equivalente a buff[4]=0. Pone un cero en la quinta posición de buff (el índice empieza en cero). Supongamos, ya que esa parte del código no la has puesto, que has definido buff como:
char buff[10];
Eso significa que hemos reservado 10 bytes para buff, por lo tanto ese es su tamaño, así que el valor de sizeof(buff) será 10. Así que readBytesUntil leerá 10 bytes si no encuentra lo que busca. Entonces ejecutará lo equivalente a buff[10]=0. Esto pondrá a cero el undécimo byte de buff. ¿Cómo? ¿El undécimo byte? ¿Pero si sólo tiene diez? Pues sí, el undécimo. Ya sé que sólo tiene 10, pero el C++ no verifica que sólo tiene 10 y si le dicen que lo ponga en el 11, él lo pone sin hacer comprobaciones (por eso es tan rápido, porque no pierde el tiempo con ciertas comprobaciones).
Si esto pasa, que escribe un cero fuera del rango de buff, seguramente está "invadiendo" el espacio de memoria de otra variable, y si esa otra variable tiene un valor distinto de cero en esa posición de memoria... te está corrompiendo el valor de esa variable. Y dependiendo de qué variable sea, y qué hagas con ella, puede ser que ocurra un "desastre" (puede o casi seguro). Pero eso sólo te pasará si en "la búsqueda" del '#' éste no está y por lo tanto no lo encuentra. ¿Solución? Limitar la búsqueda a un byte menos de lo que cabe en buff. Por eso le resto uno al sizeof(buff). Y si es necesario se agranda en uno el tamaño de buff, para que quepa lo mismo que hasta ahora, más el terminador de cadena.
Pero ahí no acaba la cosa. Tienes otra "bomba" en potencia un poco más adelante. Con la
i
del do while. En este caso ocurre todo lo contrario, el problema no viene si no lo encuentra, viene si lo encuentra de más. ¿Qué pasa si hay un "/" de más (o dos, o tres... de más)? Pues que
i
llegará a valer 2 (... y 3, 4, etc, dependiendo de cuántos encuentre de más). Y por lo tanto escribirá en datos_RX[2] (... y datos_RX[3], datos_RX[4]...). No sé con qué tamaño has declarado datos_RX, pero si es de dos elementos (o aunque sea de más, existe la posibilidad de salirte de su rango) se estará escribiendo valores fuera de él. Recuerda que C++ no verifica si te sales del rango. Y recuerda que esto significa que se está "corrompiendo" otras variables. Y esto puede llevar a que haga "cosas raras", funcione mal o incluso "colgar" el programa. Para evitar esto, en el caso de que datos_RX fuera de dos elementos, yo lo habría hecho con un for tal que así:
for (i = 0, posini = 0, posfin = 0; (i < 2) && (posfin >= 0); i++) {
posfin= cadRX.indexOf("/",posini);
valor=cadRX.substring(posini,posfin);
posini=posfin+1;
datos_RX[i]=valor.toInt();
}
No descarto que la causa de tu problema sea que en algún momento te lleguan datos que se salgan de "lo previsto" y que se esté saliendo de rango a la hora de asignar los datos en los array. Aunque esto no fuera así, te sugiero que hagas los cambios que te he dicho para que sea "más robusto" a los fallos de transmisión.