¿Qué calificador de variable debe colocarse a los datos que se obtienen a través del módulo bluetooth?
Por ejemplo:
String texto_entrada;
void loop(){
texto_entrada = BT1.readString();
}
este String no debe ir acompañado de algo antes?
Un poco de Google te ahorrará tiempo a ti y a nosotros, aunque tu pregunta no molesta, hay muchas respuestas que simplemente las consigues con una busqueda simple como dice mi lema.
google: Arduino Serial.readString()
Si quieres puedes definir asi
String texto_entrada = "";
pero mas importante es que cuando dejes de usar String o sea texto_entrada vuelve a ponerlo a 0 con de este modo
texto_entrada = "";
Aclaro que edité tu pregunta porque la malentendí incialmente.
Es que mi pregunta quedó corta.
Resulta que vi este código
volatile int sleepLoopCounter = 0;
y resulta que "volatile" es para manejar variables en la RAM, de lo contrario da errores.
en este caso sleepLoopCounter es un cotador, que se activa desde una condición externa al setup inicial.
Busco un calificador para los "String" que ingresan desde el bluetooth, ya que así normal como lo he mostrado, no me funciona para más de una cadena.
Lo primero que te diré es que intenta concentrar todas tus consultas en un mismo hilo porque tu tienes una idea que tiene que ver con tu aplicación conectada al HC06 y al arduino y haces preguntas relacionadas aqui y alla cuando todas debería estar en el mismo hilo.
Estas haciendo un crossposting sin que te des cuenta o conciente de ello.
Es mucho mas productivo para ti y para quien lea tus progresos, problemas y sus soluciones tener todo en un hilo y no en tantos.
A tu pregunta le falta contexto.
Tu sabes de que hablas pero los demás y yo, no estamos a tu lado entendiendo tu proyecto/programa.
Entonces si no vemos bien donde falla tu código con esas dos líneas es imposible decirte qué esta mal.
Ese código funciona esperando que alcances un limite de tiempo.
Por eso te puse el link a Serial.readString() para que leas las características y limitaciones que pueda tener la función o procedimiento.
Dice y cito:
Serial.readString() reads characters from the serial buffer into a String. The function terminates if it times out (see setTimeout()).
Serial.readString() inherits from the Stream utility class.
Lee caracteres del buffer serie a un String (el que tu has definido). La función termina si se ha alcanzado el timeout predefinido en setTimeout() que esta por defecto en 1000 mseg
Serial.setTimeout() sets the maximum milliseconds to wait for serial data. It defaults to 1000 milliseconds.
Todo absolutamente todo, tiene su respuesta, leyendo la especificación de la funcion.
Ahora bien, tienes otra función que te pueda servir que es Serial.readStringUntil()
Finalmente y como no le pusiste contexto y yo debo advinar por tus palabras que esto
en este caso sleepLoopCounter es un cotador, que se activa desde una condición externa al setup inicial.
quiere decir que sLeepLoopCounter esta en una ISR activada por interrupciones, entonces si, debes usar volatile aunque en un debate de hace unos días alguien dijo que si lo usas como global funciona y yo le discutía que debía ser volatile y para mi sorpresa, funciona.
Asi que no se si te he respondido o no.
surbyte:
...debes usar volatile aunque en un debate de hace unos días alguien dijo que si lo usas como global funciona y yo le discutía que debía ser volatile y para mi sorpresa, funciona.
Surbyte, no he encontrado el debate (tampoco he buscado mucho). Pero puedes usar el siguiente argumento, si te convence, en el debate:
La "palabra reservada" volatile es para indicarle al compilador que no se quiere que optimice el código que genera en el acceso a la memoria de la variable indicada.
Por ejemplo: si tenemos un bucle que compara el valor de dos variables continuamente, sin que estas sean modificadas dentro del bucle, podría optimizar el acceso a memoria cargando inicialmente en un par de registros especializados del micro los valores de ambas variables, y usar esos registros en cada iteración del bucle sin necesidad de "volver a leer" las variables desde la memoria. Esto no daría problemas si "nadie ajeno al código del bucle" modifica una de las variables. Pero si tenemos una interrupción que modifica una de las variables, como la interrupción modifica sólo el valor que hay en memoria y no "la copia" del valor que está en el "registro especializado", nos encontramos que para el código optimizado no se ha cambiado el valor. Si indicamos que esa variable es volatile entonces el compilador hará que el programa lea siempre el contenido de la memoria, aunque sea más lento. Así sí que "se detecta" en nuestro bucle que una interrupción ha cambiado el valor.
Ya sabemos porqué cuando hay interrupciones de por medio, si no ponemos el volatile, el programa puede no comportarse como queremos. ¿Pero porqué en ocasiones el programa lo hace bien a pesar de no poner el volatile? Pues porque no siempre el compilador puede utilizar esos "registros especiales" para optimizar el código ya que esos registros "escasean". O bien porque el compilador no está configurado para que haga ese tipo de optimización. Así que no es de extrañar que en ocasiones funcione sin el volatile. Pero lo mejor es no dejar las cosas al azar y dejarle clarito al compilador que esas variables que vamos a usar "dentro y fuera" de las interrupciones no han de ser optimizadas.
Otro detalle es que aunque funcione sin declarar como volatile la variable (porque el compilador decidió por su cuenta no optimizar) es aconsejable ponerlo para que, si alguien (incluso nosotros mismos) revisando el programa ve la declaración de la variable como volatile, se espere que su valor pueda cambiar "inesperadamente" (vamos, que lo más probable es que una interrupción la modifique, así que mejor que mire si es así).
Por otro lado existe la "palabra reservada" register que le indica todo lo contrario al compilador. Con ella le indicamos al compilador que, si es posible, optimice con registros esa variable. A diferencia de volatile, que nos hará casomsiempre y no optimiza, register no obliga al compilador a optimizar. Lo hará si puede... o incluso ni le hará caso porque a partir del C++17 register pasa a ser una palabra reservada sin utilidad alguna. Se considera que los compiladores actuales optimizan mejor el código que los humanos y ya no hace falta "sugerir" ese tipo se optimización.
El debate no esta en este foro, es en otro foro en el que participo.
Seguramente eso explica porque me funcionó y porque debe usarse para evitar problemas.