Modificar códigos de Arduino.

[cosmefulanito04]

Yo jamás enviaría ni envío cadenas como comandos.
Lo que suelo enviar es una trama de bytes con cabecera, datos y checksum.
Compruebo la cabecera y realizo el cálculo del checksum, si coincide con el enviado entonces proceso los datos.

Yo creo que depende de la limitación de procesamiento que tengas, en este caso en el lado de Arduino (el uC), si no te ves limitado, yo usaría tramas en strings y le agregaría un checksum al final (siempre armando un protocolo adecuado). La mayoría de las comunicaciones en alto nivel suelen ser strings gigantes con un principio y un fin, el ejemplo más claro es el protocolo http.

Algo que estoy aprendiendo hace relativamente nada, es la magia de los XML en conjunto con los XSD. Esto te soluciona un montón de problemas de chequeo de trama y además te permite aumentar los campos de manera muy sencilla sin necesidad de tocar el código en la etapa de verificación. El problema de este tipo de soluciones es que para el lado del uC puede llegar a ser muy demandante, pero por ej. a nivel de PC, es muy práctica esta solución.

 

[Dr. Zoidberg]

Algo que estoy aprendiendo hace relativamente nada, es la magia de los XML en conjunto con los XSD. Esto te soluciona un montón de problemas de chequeo de trama y además te permite aumentar los campos de manera muy sencilla sin necesidad de tocar el código en la etapa de verificación. El problema de este tipo de soluciones es que para el lado del uC puede llegar a ser muy demandante, pero por ej. a nivel de PC, es muy práctica esta solución.

Yo usé XML hace 23 años ya. Hoy todo está cambiando a JSON, que a mí no me gusta mucho pero es mucho mas fácil de analizar que XML, aunque no sé si puede validarse con algo parecido a un DTD.
Pero bué....todas las herramientas son válidas dependiendo del contexto de uso, tal como decís...

 

[Meta]

Yo jamás enviaría ni envío cadenas como comandos.
Lo que suelo enviar es una trama de bytes con cabecera, datos y checksum.
Compruebo la cabecera y realizo el cálculo del checksum, si coincide con el enviado entonces proceso los datos.

Pues todo eso tengo entendido.

¿Por qué el del libro lo vende enseñando a la gente hacer las cosas mal? Solo lo sabe él.

Lo de los comandos es comprensible, envías un comando, y hace una acción.

Principio de un la trama de bytes + contenido o datos + final + acuse de recibo.

Pensando que el código ya por fin es la leche y está fatal como dicen arriba. Eso si, funciona bien.

Gracias por las aportaciones y sinceridad, que sin ella sigo haciendo las cosas mal.

 

[Scooter]

¿Por qué el del libro lo vende enseñando a la gente hacer las cosas mal? Solo lo sabe él.

Pues anda que el que inventó el delay

 

[Meta]

Cuando se inventó el delay, en sus antigüedades de la época. ¿Había interrupción?

 

[Dr. Zoidberg]

Cuando se inventó el delay, en sus antigüedades de la época. ¿Había interrupción?

Las interrupciones existen desde que existen los microprocesadores!
Yo estudié programación de microprocesadores en 1986, y el SCMP y el 8080 ya las tenían y se usaban...vos verás la antigüedad de las interrupciones...

 

[resistencio]

Entonces DIOS, hizo la luz, luego a DrZoid, a Scooter, y después todo lo demás que ya conocemos...!!!

 

[Meta]

LA verdad el delay no creo que se invetara. Recuerdo en un libro del PIC16F84A en asm o ensamblador, que los delay se usa para muy poco tiempo como en los temás de los antirrebotes o pulsadores por nombrar un ejemplo, no que dure 5 minutos en apagar un Led y no haya interrupción por medio. Hay que usarlo debidamente, no a lo loco, eso si, los milli() mejor.

 

[cosmefulanito04]

Me acuerdo que en juegos viejos de DOS se usaban los clocks del CPU como delays. Como consecuencia, cuando aumentaron la velocidad de los CPU, los tiempos se fueron por los caños y tuvieron que inventar el modo "TURBO" y "LOW".

 

[Nuyel]

La única utilidad en los delay es cuando al iniciar x modulo necesita que esperes algunos ciclos antes de utilizarlo para que se estabilice.

 

[cosmefulanito04]

Para los displays de dos filas, había comandos que eran uS, valía la pena usar un mini delay.

 

[D@rkbytes]

De hecho existen varios dispositivos que requieren cierto tiempo entre instrucciones para que respondan.
Incluso hasta para leer códigos IR, EEPROMS, etc. O sea, son válidos donde sí o sí de todos modos se debe cumplir un protocolo que requiere retardos para finalmente poder recibir los datos.

 

[AleSergi]

a Mí me parece que los Viejitos Contestones, tienen que ponerse a estudiar nuevos micros, esos de al menos dos núcleos, así usan delay tranquilamente... pero con mucho cuidado, porque después entran los millenian, con nombre de usuario de mujer y me los turbinan a todos juntos!.
Mientras tanto Yo aun no me decidí por micros de Raspberry (RP2040) o los Esp32 (Tensilica LX6.)...

 

[cosmefulanito04]

Siempre hablando a nivel de uC, para esas cosas usas un lindo y bonito RTOS, te olvidás de todo y usas sleeps/mutex/etc en vez de delays. Para cosas más grosas como un Raspberry, ya arrancás con un Linux, porque usarlo pelado como baremetal, es un dolor de h..vos.

 

[Scooter]

a Mí me parece que los Viejitos Contestones, tienen que ponerse a estudiar nuevos micros, esos de al menos dos núcleos, así usan delay tranquilamente... pero con mucho cuidado, porque después entran los millenian, con nombre de usuario de mujer y me los turbinan a todos juntos!.
Mientras tanto Yo aun no me decidí por micros de Raspberry (RP2040) o los Esp32 (Tensilica LX6.)...

¿Y con la tercera, cuarta, quinta, sexta... tarea que haces?
¿Compras un micro de N núcleos para tener N-1 haciendo nada.?
Compra un coche para el lunes, otro para el martes... es mucho mejor que aprender a aparcar. Lo sabe todo el mundo.

Si que he usado micos con dos núcleos, pero en dos segundos estás en lo mismo otra vez.
Y todo el mundo sabe que soy un cascarrabias, es notorio.
Cada uno que programe como quiera, pero que luego no se queje de por qué no leo el pin 2 si me he quedado en un bucle esperando a que pase algo en el pin 3, esto con o sin delays.

¿Que significa turbinar con palabras de boomer?

 

[AleSergi]

Siempre hablando a nivel de uC, para esas cosas usas un lindo y bonito RTOS, te olvidás de todo y usas sleeps/mutex/etc en vez de delays. Para cosas más grosas como un Raspberry, ya arrancás con un Linux, porque usarlo pelado como baremetal, es un dolor de h..vos.

Me refería solo a esas placas, Esp32 y Raspberry Pi Pico (tal vez un STM32 pero no registro), que tiene el tamaño de un microcontrolador de unos 40 pines, solo dos núcleos y parecen estar a mitad del camino de los micros ARM que nombras los que son capaces de correr minisLinux.
Esas placas que nombro, seguramente las manejaremos pensando como en los viejos micros y sus aplicaciones directas, sensores, teclados pantallas sencillas lcd, leds etc etc, , nada de Iot, o descontrolarse con el WiFi...

¿Y con la tercera, cuarta, quinta, sexta... tarea que haces?
¿Compras un micro de N núcleos para tener N-1 haciendo nada.?
Compra un coche para el lunes, otro para el martes... es mucho mejor que aprender a aparcar. Lo sabe todo el mundo.

Si que he usado micos con dos núcleos, pero en dos segundos estás en lo mismo otra vez.
Y todo el mundo sabe que soy un cascarrabias, es notorio.
Cada uno que programe como quiera, pero que luego no se queje de por qué no leo el pin 2 si me he quedado en un bucle esperando a que pase algo en el pin 3, esto con o sin delays.

¿Que significa turbinar con palabras de boomer?

solo seremos de primera y segunda ja ja ja! (dos tareas, nuestro cerebro no da para más!)
Sehhh, claro conocemos el concepto de programación orientada a eventos, y con esto de los micros, y sus interrupciones, estamos a mitad de camino... estaba bromeando, se entiende?

Boomer?.. ahh no sé, soy X, pero las turbinas generan trabajo, así que si te turbinan, es que te hacen trabajar de arriba, mediante ingeniería social...

Y Meta sigue pensando en cadenas... sabes, echale una mirada (a vuelo de pájaro) a los viejos computadores hogareños, esos ZX Spectrum, Commodore, MSX, como codificaban su teclado, a fuerza de UN byte, pensando en eso fue que te nombre lo de solo UN byte, y no perder tiempo en recepciones largas y comparaciones tediosas, solo OCHO BITS.

 

[resistencio]

Dijo BILL, "640K debe ser suficiente para cualquier persona...."
Le faltó agregar, "UN byte: también...", estoy con ALESERGI en esta.

 

[Scooter]

Gracias por aclarar el concepto de turbina.

 

[Meta]

Dijo BILL, "640K debe ser suficiente para cualquier persona...."
Le faltó agregar, "UN byte: también...", estoy con ALESERGI en esta.

Solo en modo comandos...

 

[D@rkbytes]

Solo en modo comandos...

Para mí es más fácil hacer esto...

        private void Serial_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            // Leer los datos y saber cuántos bytes se recibieron.
            int dataLen = Serial.Read(dataInput, 0, dataInput.Length);

            // Si se reciben menos de los esperados, no hacer nada.
            if (dataLen < dataInput.Length) return;

            int chkSum = 0;

            // Comprobar los dos primeros bytes.
            if(dataInput[0] == ident1 && dataInput[1] == ident2)
            {
                // Obtener el checksum.
                for(int i = 0; i < dataInput.Length - 1; i++)
                {
                    chkSum += dataInput[i] & 0xFF;
                }

                // Si el checksum calculado es igual al enviado, se procesan los datos.
                if(chkSum == dataInput[dataInput.Length - 1])
                {
                    processData();
                }
            }
        }

De esta forma se pueden procesar cientos de comandos a la vez, que no necesariamente tienen que ser cadenas.