(31-12-2015, 11:48 AM)pedmar escribió: [ -> ]mira que soy torpe ni buscar en la red se me da bien...
Yo me he liado a hacer cálculos y copiando de arturo y dándole vueltas hasta que me salia humo para llegar a esta posible conclusión cosa que me llevo mas de una hora
O pensabais que lo adivine en un momento
aun así no vale si lo meto en el programa arduino me da error
(No se todavía meter en el programa lo que tengo en mi pequeña neurona)
Ni eres torpe ni has tirado el tiempo. Al principio las cosas más triviales son incomprensibles porque se trata de algo totalmente nuevo.
Los errores son muy útiles. Sin ellos no se puede aprender nada. No basta probar. Es necesario probar y equivocarse. Forma parte del proceso.
Hay empresas que pagarían una fortuna para poder garantizar la ausencia de errores en sus programas. Eso es una utopía. El ordenador siempre hace lo que tú le indicas, el juego consiste en hacer que eso coincida con lo que tú deseas que haga.
http://www.javiergarzas.com/2013/05/top-...ticos.html
El arte de corregir errores se llama depurar programas. Se usa por similitud con debug, que en ingles significa desinsectar.
Uno de los errores más sonados de los principios de la informática (1940 en un Mark II) En aquel entónces no solo no se usaban las válvulas de vacío. Para conmutar se usaban Relés que eran lógicamente mucho más lentos.
El fallo al que me refiero fue en realidad un fallo de hardware. Una polilla entro en el ordenador y sus alas quedaron entre los contactos de un relé imposibilitando su acción. Desde entonces se ha mantenido el gracioso término debug.
Poco después (en 1946) surgió el ENIAC. Ocupaba todo un sótano en la universidad y la temperatura subía a 50ºC. Llevaba 18.000 tubos de vacío. Alguna válvula se fundía casi todos los días, dejando al ENIAC parado un promedio de media hora al día.
¿Fallos? ¿Errores? ¿Caos? Estas cosas hacen que cuando algo hecho por ti funciona la recompensa sea mayor.
En programación hay dos tipos de fallos y cada uno requiere de un método diferente para depurarlo.
1) Errores en tiempo de compilación:
La compilación se hace en varias pasadas pero ya hablaremos de eso.
Si el programador pone algo que no cumple con la gramática del lenguaje y cambia un punto y coma por una coma, olvida cerrar un paréntesis, olvida declarar una variable, etc. El compilador no tendrá forma de saber que se pretende hacer.
Si el programador pretende usar un tipo inadecuado de variable en una sentencia, el ordenador avisará de que se intenta hacer algo no permitido.
2) Errores en tiempo de ejecución:
Si el programa ha compilado correctamente y ha generado un ejecutable, puede ocurrir que durante la ejecución del programa alguna operación imprevista provoque un error. Podría darse el caso de que el programa funcionara correctamente hasta que alguien se le ocurra introducir un dato problemático y no previsto en el programa. Por ejemplo si por culpa de los datos introducidos el programa intenta dividir por cero, el programa fallará. Estos errores suelen llamarse errores de lógica.
En el primer caso, el compilador suele ayudar bastante indicando la línea del programa que presuntamente provocó el o los problemas. El primer error mostrado es el más importante. Un error corregido puede hacer que desaparezcan varios errores de los que se muestran a continuación.
Si la cosa no queda clara, se puede comentar la parte sospechosa mediante /* ...parte sospechosa...*/
Con ello se logra que el compilador compile el programa sin la parte comentada y si todo va bien sabemos que dentro de la parte comentada hay un problema.
En el segundo caso, para poder seguir los cálculos que está haciendo el compilador interesa poner trazas. Es decir, instrucciones que muestren los valores de las variables y que detecten pos puntos del programa que se van ejecutando en cada momento, pero ya iremos viendo todo eso.
Para terminar, rogaría que todos los que obtenéis errores de compilación los compartierais aquí. Inicialmente es muy complicado interpretarlos correctamente.