Mis experiencias con el UNO clon y original

No se porqué el Arduino UNO nunca ha sido la placa que tengo en cuenta para desarrollar pero las circunstancias (el cliente) obligaron a usarlo con malas experiencias hasta ahora. Mi trabajo es un logger que consta de un UNO, un Logger Shield (SD y RTC DS1307, siii lo sé pero es lo que quiso el ciente en lugar del DS3231 que siempre recomiendo) y un LCD Shield que debe tomar una muestra en tiempos ajustables de 1 a 24 hs según sea elegido por menú LCD.

Tenía las cosas funcionando individualmente. Me faltaba la parte del menú LCD y decidí incursionar en algunas librerías MenuBackEnd y MENWIZ. Encontré que estan viejas y requieren algún trabajo compilarlas con IDE 1.6.11 que estoy usando.

Buscando el camino fácil, (yo tmb lo hago) encuentro un código y el mismo decía ajuste de brillo. MIro bien mi shield y no veo que tenga un transitor que permita ajustar brillo pero dije que pierdo? Luego de hacer que compilara el código, se me ocurre elegir la opción de ajuste de brillo. No recuerdo que elegí pero si aumentó el brillo y de golpe humo... reaccioné tan rápido como pude pero OUT CLON!! GAME OVER. Regulador con un cracter. Resultado: El CH340 sigue funcionando pero el ATMEL parece haber sucumbido a la tensión sin regulación. Placa para repuestos, otra más!!

Asi que encargué un ORIGINAL. Llegó 1 semana después (maravilloso sistema de entregas en mi país Argentina, aclaro que es ironía!!). Todo bien, seguí trabajando y olvidé comentar algo importante y es explicar el hardware que uso.

Son 3 placas, el Arduino UNO, SHield Logger y el LCD que alimentadas por USB no trabaja bien, a veces dice USB no reconocido. Así que uso un trafo de 9V con el conector externo en ambos casos. Como les recomiendo a todos uso las dos conexiones porque quiero ver momentos intermedios del código por el monitor serie y ayer algo paso y de golpe... stk500_getsync() attempt 1 ... attempt 10 y ya no respondió mas. Bueno si lo hace.. pero no flashea.

Como vivo leyendo e intentando solucionar esto en tantos hilos quiero ver que solución le iré dando, pero no será ahora, sino en cuanto vaya encontrando tiempo para dedicarle.

Tengo dos caminos: 1. Pedir otro porque yo habitualmente no pierdo tiempo con una placa que cuesta 5 a 10 dolares. La reemplazo porque mi tiempo es más caro. Y 10 dolares no vale ni una hora de mi trabajo. 2. Intentar encontrar una solución que claro haré solo para que sirve a la comunidad. En este punto diré lo siguiente. El UNO Original tiene un ATMEGA16u2 y claro todo luce como que algo le ocurrió al atmega porque ahora no permite subir el sketch. El posible camino es ponerlo en modo DFU y reflashear el firmware del ATMEGA16U2. Cosa que haré claro. Si no lo conté, el UNO al arrancar muestra el led verde de power todo el tiempo y nada sobre su comunicación pero si presiono RESET los leds RX TX flashean.

Buscando mis soluciones y alternativas ya pedi temprano un tercer UNO (doble o sea pedí dos) y seguiré con un MEGA que para el caso me sirve igual.

En lo que respecta al hilo mas tarde haré mi intento con el reflasheo del ATMEGA16U2 y les contaré.

A los que lean esto, les pido encarecidamente que concentren problemas solo similares a este. para explicarlo mejor, esta es la respuesa que tengo al intentar subir un sketch

El Sketch usa 928 bytes (2%) del espacio de almacenamiento de programa. El máximo es 32.256 bytes.
Las variables Globales usan 9 bytes (0%) de la memoria dinámica, dejando 2.039 bytes para las variables locales. El máximo es 2.048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3f
Problema subiendo a la placa. Visita http://www.arduino.cc/en/Guide/Troubleshooting#upload para sugerencias.

Ven que dice programmer is not responding Entonces lo que haré a continuación se aplica a este caso. no todos los problemas stk500_recv() tienen esta resolución.

CONTINUARA...

surbyte: No se porqué el Arduino UNO nunca ha sido la placa que tengo en cuenta para desarrollar pero las circunstancias (el cliente) obligaron a usarlo con malas experiencias hasta ahora. Mi trabajo es un logger que consta de un UNO, un Logger Shield (SD y RTC DS1307, siii lo sé pero es lo que quiso el ciente en lugar del DS3231 que siempre recomiendo) y un LCD Shield que debe tomar una muestra en tiempos ajustables de 1 a 24 hs según sea elegido por menú LCD.

Tenía las cosas funcionando individualmente. Me faltaba la parte del menú LCD y decidí incursionar en algunas librerías MenuBackEnd y MENWIZ. Encontré que estan viejas y requieren algún trabajo compilarlas con IDE 1.6.11 que estoy usando.

Buscando el camino fácil, (yo tmb lo hago) encuentro un código y el mismo decía ajuste de brillo. MIro bien mi shield y no veo que tenga un transitor que permita ajustar brillo pero dije que pierdo? Luego de hacer que compilara el código, se me ocurre elegir la opción de ajuste de brillo. No recuerdo que elegí pero si aumentó el brillo y de golpe humo... reaccioné tan rápido como pude pero OUT CLON!! GAME OVER. Regulador con un cracter. Resultado: El CH340 sigue funcionando pero el ATMEL parece haber sucumbido a la tensión sin regulación. Placa para repuestos, otra más!!

Asi que encargué un ORIGINAL. Llegó 1 semana después (maravilloso sistema de entregas en mi país Argentina, aclaro que es ironía!!). Todo bien, seguí trabajando y olvidé comentar algo importante y es explicar el hardware que uso.

Son 3 placas, el Arduino UNO, SHield Logger y el LCD que alimentadas por USB no trabaja bien, a veces dice USB no reconocido. Así que uso un trafo de 9V con el conector externo en ambos casos. Como les recomiendo a todos uso las dos conexiones porque quiero ver momentos intermedios del código por el monitor serie y ayer algo paso y de golpe... stk500_getsync() attempt 1 ... attempt 10 y ya no respondió mas. Bueno si lo hace.. pero no flashea.

Como vivo leyendo e intentando solucionar esto en tantos hilos quiero ver que solución le iré dando, pero no será ahora, sino en cuanto vaya encontrando tiempo para dedicarle.

Tengo dos caminos: 1. Pedir otro porque yo habitualmente no pierdo tiempo con una placa que cuesta 5 a 10 dolares. La reemplazo porque mi tiempo es más caro. Y 10 dolares no vale ni una hora de mi trabajo. 2. Intentar encontrar una solución que claro haré solo para que sirve a la comunidad. En este punto diré lo siguiente. El UNO Original tiene un ATMEGA16u2 y claro todo luce como que algo le ocurrió al atmega porque ahora no permite subir el sketch. El posible camino es ponerlo en modo DFU y reflashear el firmware del ATMEGA16U2. Cosa que haré claro. Si no lo conté, el UNO al arrancar muestra el led verde de power todo el tiempo y nada sobre su comunicación pero si presiono RESET los leds RX TX flashean.

Buscando mis soluciones y alternativas ya pedi temprano un tercer UNO (doble o sea pedí dos) y seguiré con un MEGA que para el caso me sirve igual.

En lo que respecta al hilo mas tarde haré mi intento con el reflasheo del ATMEGA16U2 y les contaré.

A los que lean esto, les pido encarecidamente que concentren problemas solo similares a este. para explicarlo mejor, esta es la respuesa que tengo al intentar subir un sketch

El Sketch usa 928 bytes (2%) del espacio de almacenamiento de programa. El máximo es 32.256 bytes.
Las variables Globales usan 9 bytes (0%) de la memoria dinámica, dejando 2.039 bytes para las variables locales. El máximo es 2.048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x3f
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3f
Problema subiendo a la placa. Visita http://www.arduino.cc/en/Guide/Troubleshooting#upload para sugerencias.

Ven que dice programmer is not responding Entonces lo que haré a continuación se aplica a este caso. no todos los problemas stk500_recv() tienen esta resolución.

CONTINUARA...

proba usando isc, quizas se jodio el bootloader o el ch340 o atmega16. Tengo una UNO que hace lo mismo despues que mis alumnos jugaron por su cuenta. La reconoce pero no carga el codigo. Pero por ISC anda bien.

Ademas que de esta forma recuperas bastante espacio de flash suerte y comentá

Iba a comenzar intentar recuperar la comunicación. ICSP siempre es la opción para seguir usándolo. Cierto es que no lo escribí ni mencioné porque me enfoqué en lo que haría cualquiera con ganas de recuperarlo.

edito: creo un post