Go Down

Topic: Problema entre Atmega328 y Atmega328p (Read 2550 times) previous topic - next topic

AlexTadeo

Hola estimada comunidad,

Mandé a fabricar una placa con un "arduino uno" + sim900+gps, el fabricante me envío la placa con un Atmega328 con un programa pre-cargado (un test de leds y gps) y funciona bien.

*nota: yo no me había dado cuenta que era Atmega328.

Procedí a cargar mi programa usando un Atmega328p ya con el bootloader y pude observar que tardaba en iniciar, explico esto. Con el micro que me enviaron conecto la alimentación y empieza a funcionar de inmediato, encienden los leds y no hay problema. Con mi Atmega328p tarda en iniciar cuando se alimenta y puede o no reiniciarse o no terminar de encender los leds.

Le pregunté al fabricante y me dijo que el había configurado el micro con los fuse del arduino uno.

La verdad no tengo idea que son los fuse y no sé si el problema también sea que son Atmega328 y Atmega328p.


Muchas gracias por su apoyo.

AlexTadeo

Puede ser que el micro que me enviaron este trabajando con el reloj externo mientras que el que tengo este trabajando con el interno?

Lucario448

De dónde viene ese 328p?

Si viene de un Arduino Uno, entonces sí está programado para trabajar con un oscilador externo.

Además, que te preocupa de que el otro microcontrolador no lleve la 'p'? Que no le puedas cargar otros programas?

AlexTadeo

Si vino de un Arduino UNO R3 y no es que me preocupe, es que su comportamiento no es estable.

AlexTadeo

No sé como poder poner un video para que vean como se comporta.
Si no es permitido el linkear un video de dropbox disculpe.

https://www.dropbox.com/s/6hdau2y5pd68jmr/20160522_143729.mp4?dl=0

surbyte

Perfectamente linkeado.
bueno como siempre digo, una simple busqueda ahorra tiempo : 
google: atmega328 vs atmega328p
Uno de los mejores enlaces fue este link

AlexTadeo

Bueno, tengo nueva información.

El Atmega328 que vino con la placa fue programada en Atmel Studio y con el avrdude se le puso los fuse del arduino uno, no tiene el bootloader.

puedo pensar que el bootloader es el causante de dicha inestabilidad y retraso al encendido?

Lucario448

puedo pensar que el bootloader es el causante de dicha inestabilidad y retraso al encendido?
Yo no sabría decirte con toda certeza si esa es la causa, pero... por qué no intentar reprogramar el bootloader?
Si tienes otro Arduino, este lo puedes utilizar como programador ICSP, sabías?

AlexTadeo

Yo no sabría decirte con toda certeza si esa es la causa, pero... por qué no intentar reprogramar el bootloader?
Si tienes otro Arduino, este lo puedes utilizar como programador ICSP, sabías?
si, de hecho no usaba el atmega328p de mi arduino. Pensando que podría ser que no hubiera quemado correctamente el bootloader utilice el micro que vino con mi arduino, y presentó el mismo problema de inestabilidad.

Lucario448

si, de hecho no usaba el atmega328p de mi arduino. Pensando que podría ser que no hubiera quemado correctamente el bootloader utilice el micro que vino con mi arduino, y presentó el mismo problema de inestabilidad.
Espera... cuál es el del comportamiento anormal? El que tiene la 'p' o no?

AlexTadeo

si, tengo dos atmega328p uno que compre aparte y uno me vino con el arduino. Los 2 tienen el mismo comportamiento en la placa.

noter

Bueno, tengo nueva información.

El Atmega328 que vino con la placa fue programada en Atmel Studio y con el avrdude se le puso los fuse del arduino uno, no tiene el bootloader.

puedo pensar que el bootloader es el causante de dicha inestabilidad y retraso al encendido?
Del retraso en el encendido puedes estar seguro que sí. En un hilo reciente y cercano a este puse un comentario del proceso de subida de programa mediante bootloader. Efectivamente, cuando el arduino tiene bootloader éste se ejecuta inmediatamente al encendido o tras un reset, y antes del programa del usuario. Toma habitualmente un par de segundos, hasta que el bootloader "se da por vencido" de que no queremos enviar programación y transfiere el control al programa de usuario. Los montajes que suelen tener mucho inconveniente con este proceso de arranque suelen ser los que integran relés, dado que en dicho proceso, además, se suele producir el encendido y apagado de éstos. Supongo que ese problema también se verá muy mitigado si quitamos el bootloader.
Lo que no entiendo es a qué te refieres con "inestabilidad", pues una vez pasado el bootloader, el funcionamiento del programa debería ser casi idéntico.

AlexTadeo

#12
May 25, 2016, 04:26 pm Last Edit: May 25, 2016, 04:44 pm by AlexTadeo
Hola noter,

Gracias por responder.

En ocasiones se resetea más de una vez o no termina la "secuencia" de encendido.

https://www.dropbox.com/s/6hdau2y5pd68jmr/20160522_143729.mp4?dl=0

mira este video, el primer micro es el que me mandaron (Atmega328 con fuse de Arduino Uno, sin bootloader) y posteriormente es el Atmega328p del arduino UNO.

Podrá ser que como dices, el bootloader no se "lleva bien" con el relé y ahí esté el problema?

noter

Si lo único que cambia en ambos montajes es el atmega, a buen seguro que gran parte de la culpa sea del bootloader.
Si el inicio más lento y la pequeña inestabilidad durante ese segundo no son un gran obstáculo, seguramente que el programa después debería funcionar correctamente (tal vez haya que hacer algún chequeo adicional).
Si ese segundo de inestabilidad te supone problema importante, y dispones de programador, lo mejor es que quites bootloader. Ganarás, además unos pocos bytes de SRAM y de FLASH.

AlexTadeo

Tengo un Master Prog, se supone que se puede utilizar como pickit2, intentaré usarlo para borrar el bootloader.

En cuanto tenga datos nuevos les hago saber.

Gracias por su apoyo.

Go Up