¿Cómo programar un código más robusto?

lo que debes buscar son temas de maquinas de estados y programacion multitarea usando timers
es un tema bastante interesante.
sobre todo cuando quieres prender un led cada 0.5s mientras lees un ADC, escribes o lees por rs232 y moviendo un motor a pasos ,ect.

si usas delays valio todo
 
Humm... para una persona que empieza, meterse con cosas de multitarea...

¿Por qué no nos olvidamos de los retrasos (delays) y nos centramos en la robustez?

Por ejemplo, hablémosle del tema de la alimentación, y de los recursos con los que cuenta un µcontrolador para gestionar la caída de alimentación.
 
...Se podía poner a punto con el motor en marcha. ¿Que sentido tendría que para hacer la puesta a punto hubiera que parar el motor?.

que sentido tiene? :unsure: no se, quizas algo muy tonto para vos, pero por lo general se hace para no torcer valvulas u pinchar piston por momento de ignicion en un ciclo erroneo.... o quizas, lo que hiciste fue un corrector de curva de avance? son cosas distintas, pero que van de la mano :cool:
mis felicidades por tal desarrollo :aplauso:
 
Perdonen por participar de forma tan tardía en este hilo.

Para mí el objetivo de crear código robusto se define, sin excluir lo escrito aquí, de insertar un comportamiento determinístico del programa a crear. Un curso de programación del lenguaje de "Python" lo trata en la combinación de la instrucción "try and except"!

Esa instrucción "try" contiene el código si todo va bien. Si no, por ejemplo división con "ZERO", ejecuta el código en "except"!

Todo código que escribimos puede contener las sentencias que implementan la funcionalidad. Pero todo código puede generar "excepciones" por ejemplo el dividir por "0", pero también por eventos exteriores que impactan la ejecución de nuestro código. Típico para los que escriben código para aplicaciones embebidas!

Hay que determinar que causas pueden hacer nuestro código menos robusto! Tal cual "Python" ofrece la funcionalidad de "Try and except", algo equivalente debe ser creado para cada módulo de nuestro programa!

Eso me trae a otro punto que también impacta si un código es robusto o no! El escribir código en forma de módulos con bien definidas "Input" a este y bien definidos "Output"! Cuando yo aprendí a programar algo mas de 4 décadas atras, mal código era "Espagetti" y algo a no usar la famosa sentencia "GOTO".

Un módulo debe ser tan pequeño para que podamos hacerlo determinístico! Cuando mas grande, mas difícil el ver todas las permutaciones posibles que puedan crear una excepción como las que presenté mas arriba. Así, cuando escribo código usando el lenguaje de "Python" este siempre va en la parte "Try" y en la parte "Except" pongo el código de reaccionar de forma "organizada" a las excepciones que pueda no haber previsto!

Esto facilita el volver a usar módulos de código que implementan cierta funcionalidad. Esta forma de proceder también facilita muchísimo el "debug", la búsqueda y eliminación de errores al programar y al ejecutar el código escrito.

Típicos módulos que vuelvo a usar es aquel en el cual el usuario de un programa debe entrar un "valor"! Si quiero que solo pueda entrar "dígitos", entonces el entrar una "letra" causa una excepción y el código en "Except" instruye al usuario que solo "dígitos son permitidos y vuelve a estar preparado para que el usuario entre un valor! Lo mismo cuando exijo que presione un "botón" físico. El código que evita que el presionar resulte en múltiples. Con el tiempo se tiene una biblioteca de "módulos" de los cuales se que están libres de errores y que saben tomar todas las condiciones de excepción por el evento que fuera.

Aquí el enlace a un video en español que presenta estas sentencias:


Ojalá me ha sido posible presentar que el crear código robusto empieza por "pensar" en cierta forma al crear código.
 
El problema es que los únicos lenguajes de programación que soportan excepciones son Python, Java y Ada. Por ahí dicen que Pascal también lo soporta, pero debe ser algún engendro agregado o alguna versión muuuuy nueva (que no sé si se sigue haciendo), por que no lo soportaba...
Y esos no son lenguajes que se usen en sistemas embebidos, excepto el Ada.... pero no todo el mundo hace sistemas redundantes para aviación.
 
Bueno, de hecho, son muchos los lenguajes que cuentan con algún tipo de control de excepciones.

Según la Wikipedia inglesa: ActionScript, Ada, BlitzMax, C++, C#, COBOL, D, ECMAScript, Eiffel, Java, ML, Object Pascal (es decir, Delphi, Free Pascal, y sucesores), PowerBuilder, Objective-C, OCaml, PHP (a partir de la versión 5), PL/1, PL/SQL, Prolog, Python, REALbasic, Ruby, Scala, Seed7, Tcl, Visual Prolog y la mayor parte de los lenguajes .NET. Perl 5 tiene soporte de try-catch con el uso de un módulo externo, mientras que Perl 6 ya lo trae incorporado.

Yo tengo que decir que es una forma horrible de llenar los programas con código aún más horrible. No es de extrañar que siga recibiendo críticas desde hace décadas, ya que crea una especie de nuevo control de flujo de ejecución que en ocasiones desorienta a los programadores.

Más divertida es la programación defensiva.
 
Mi recomendación, para el que está empezando, es que lea mucho código. Es un buen medio para aprender soluciones estándar, atajos, trucos y... comenzar a sospechar si el hacer tanto bucle vacío (las esperas) es una buena forma de programar. Más tarde se dará cuenta de que un microcontrolador dormido consume mucha menos energía (instrucción SLEEP en los PIC).

Debería existir un artículo en la Witronica sobre cómo pasar un problema escrito con esperas, a otra solución basada en temporizadores o interrupciones.

Estoy totalmente de acuerdo, sobretodo con el ultimo parrafo.

Para mi, por ejemplo, se me hace cuesta arriba manejar interrupciones, mira un ejemplo, tube que usar las de RB4-7 de un 16F877A por que no se me ocurria como hacer para activar o deasctivar, en funcion del gusto, lavado rapido o agua extra en un programa para mi lavadora, seguramente habra otra forma de hacerlo mas simple peroa mi no se me ocurria.

Hay muchas clases de interrupciones, pero, habeces es mejor un ejemplo sencillo para poder comprender como usarlas para evitar en lo posible los delays.
 
Bueno, de hecho, son muchos los lenguajes que cuentan con algún tipo de control de excepciones.

Según la Wikipedia inglesa: ActionScript, Ada, BlitzMax, C++, C#, COBOL, D, ECMAScript, Eiffel, Java, ML, Object Pascal (es decir, Delphi, Free Pascal, y sucesores), PowerBuilder, Objective-C, OCaml, PHP (a partir de la versión 5), PL/1, PL/SQL, Prolog, Python, REALbasic, Ruby, Scala, Seed7, Tcl, Visual Prolog y la mayor parte de los lenguajes .NET. Perl 5 tiene soporte de try-catch con el uso de un módulo externo, mientras que Perl 6 ya lo trae incorporado.

Yo tengo que decir que es una forma horrible de llenar los programas con código aún más horrible. No es de extrañar que siga recibiendo críticas desde hace décadas, ya que crea una especie de nuevo control de flujo de ejecución que en ocasiones desorienta a los programadores.
El que escribió el artículo de wikipedia (y los que lo revisaron) no tienen NPI de como se gestionan las excepciones ni para que sirven. De hecho, el ejemplo con el EmptyLineException es patético, arrojando una excepción para atajarla dos líneas mas abajo :confused: :confused: :confused: y en el mismo contexto.
Mucho mas razonable es escribirlo de esta forma.
Código:
try {
     line = console.readLine();
     if (line.length() == 0) {
         console.printLine("Hello!");
     } else {
         console.printLine("Hello %s!" % line);
         console.printLine("The program ran successfully");
     }
 } catch(AlgunaExceptionEspecífica e) {
     console.printLine("Error: " + e.message());
 }
El finally está demás y el atrapar una Exception que es la superclase de excepciones mas específicas, confirma el diagnóstico.

Si el contexto de aplicación de ese fragmento de código fuera mas claro, hasta se podría eliminar el try-catch por completo y propagar la excepción al "llamador" de ese código.
 
Última edición:
Lo de las críticas, me refería, a la sección Criticism de esa página, que como verás tiene unos cuántos enlaces a referencias y artículos que critican el uso y abuso de dicha construcción.

Significativo el párrafo relativo al lenguaje Go, que está de moda en los últimos años (lenguaje creado por Google):
Go se lanzó, inicialmente, con la omisión de la gestión de excepciones, con la excusa de que los desarrolladores decían que ofuscaba el control de flujo. Más tarde se añadió al lenguaje el mecanismo de excepción pánico/recuperación, con el consejo de los autores de Go de usarlo sólo para errores no recuperables que pudieran parar todo el proceso.

Yo estuve presente, en el 2009 en Lisboa, cuando en la comunidad Perl se presentó en sociedad el módulo "autodie", por el que el proceso entero moría si ocurría algún tipo de error. La idea es la que comentas: si ocurre algo grave, debe ser el proceso llamante el que debe tomar la decisión de qué hacer a continuación.

Fue divertida la presentación de "autodie", recordando el proverbio Kinglon
bIlujDI' yIchegh()Qo'; yIHegh()!

Es mejor morir que regresar con deshonor.

-- Proverbio Klingon de la programación.
Bueno, en realidad está tomado de un proverbio latino:
improba vita mors optabilior.

Es más deseable la muerte que una vida deshonrosa.
En los últimos meses he estado programando con control de excepciones cada llamada a la base de datos, cada escritura en archivos, cada salida al registro de actividad, a la pantalla, a la web... un maldito infierno de miles de líneas que lo único que hacen es perder el tiempo (el nuestro).

Con lo sencillo que es sacar un texto en pantalla que diga "la conexión con la base de datos se ha perdido o no existe. Por favor, vuelva a intentarlo".



Estoy totalmente de acuerdo, sobretodo con el ultimo parrafo.


¿Has repasado los temas sobre microcontroladores? Debería haber algo...

Una lástima que la Witronica esté desactivada. No es lo mismo escribir un artículo en un foro que en una wiki.
 
Última edición por un moderador:
Bueno si quieres tener un sistema robusto, tienes que implematrar tu aplicación con un RTOS
(sistema operativo de tiempo real), Ef free RTOS es bastante compacto y permite su uso en el Arduino, ( Yo uso, solo usando los conceptos, una modificación de el, en un PIC16F54,
las aplicaciones son multitareas y con tiempos bien extrechos). Como el PIC16F54 no tiene interrupciones, la programación de cuando debe correr las tareas (scheduler) es vital. Asi como la prioridad de las tareas. Algunas veces uso el único Timer que interrumpe (WDT) para tiempos largos ya que se puede poner el prescaler alli y dar clicks del sistema cercanos a los 50ms @ 4Mhz para tareas como revision de teclado, envio de pulsos, etc

Cursera tiene un curso de la Universidad de Oslo "Introducción a la programación de RTOS"
son videos bastantes buenos en Ingles por supuesto de unos 35 min x video. Si no quieres el certificado, puedes tomar el curso gratis. Pero si no tienes acceso y tienes una un Google drive o MS cloud, te puedo enviar los videos. Solo contactate a mi correo políticas@delforo.com


 
Última edición por un moderador:
Atrás
Arriba