Salida serial distorsionada desde el tablero ATmega328 a través de la ruptura FTDI

1

Tengo un ATmega328P-PU en una placa de pruebas,

yestoyintentandoquelascomunicacionesenseriefuncionenatravésdeunodeestoschicosmalos:

El328PsecargaconunbocetodeparpadeomodificadoquesolohaceunSerial.print()alfinaldecadaiteración.

intled=13;intcount=0;voidsetup(){pinMode(led,OUTPUT);//initializethedigitalpinasanoutput.Serial.begin(9600);}voidloop(){count++;for(inti=0;i<2;i++){digitalWrite(led,HIGH);delay(150);digitalWrite(led,LOW);delay(150);}delay(350);Serial.print("abcdefghijklmnopqrstuvwxyz");
}

La buena noticia es que estoy recibiendo algo , pero la mala noticia es que todo está confuso.

Aquí hay un ejemplo de la línea de comandos de Linux de las cosas que estoy recibiendo. También veo resultados confusos similares a través del monitor serie de Arduino y el minicom también:

$ (stty 9600 cs8 -parenb -cstopb;od -a )<  /dev/ttyUSB0
0000000 ack ack   '   f   ' ack   x   f ack   x   ~ ack  rs ack  rs can
0000020  rs  rs  rs   '  rs   f  rs   x  rs   ~  rs nul   f ack   x   f
0000040   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~ ack ack   '   f
0000060   ' ack   x   f ack   x   ~ ack  rs ack  rs can  rs  rs  rs   '
0000100  rs   f  rs   x  rs   ~  rs nul   f ack   x   f   x ack   ~   f
0000120 ack   ~   ~ ack   f ack   ~   ~ ack ack   '   f   ' ack   x   f
0000140 ack   x   ~ ack  rs ack  rs can  rs  rs  rs   '  rs   f  rs   x
0000160  rs   ~  rs nul   f ack   x   f   x ack   ~   f ack   ~   ~ ack
0000200   f ack   ~   ~ ack ack   '   f   ' ack   x   f ack   x   ~ ack
0000220  rs ack  rs can  rs  rs  rs   '  rs   f  rs   x  rs   ~  rs nul
0000240   f ack   x   f   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~
0000260 ack ack   '   f   ' ack   x   f ack   x   ~ ack  rs ack  rs can
0000300  rs  rs  rs   '  rs   f  rs   x  rs   ~  rs nul   f ack   x   f
0000320   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~ ack ack   '   f
0000340   ' ack   x   f ack   x   ~ ack  rs ack  rs can  rs  rs  rs   '
0000360  rs   f  rs   x  rs   ~  rs nul   f ack   x   f   x ack   ~   f

He usado el boceto Atmega_Board_Programmer de Nick Gammon para escribir con éxito el cargador de arranque, en particular probando un par de configuraciones de fusibles diferentes (con y sin el bit de división por 8), pero el resultado es siempre el mismo: basura basura. Bueno, en realidad, cuando se divide por 8, el parpadeo fue super S L O W y obviamente no está bien.

Agradecería cualquier comentario o ideas sobre las vías para explorar. ¿Qué ajustes para tweek? ¿Es razonable el circuito?

EDITAR / ACTUALIZAR

Basándome en la sugerencia de MarkU, ejecuté con éxito mi boceto de parpadeo modificado en un Arduino Uno. Al hacer eso, también verifiqué que el panel de ruptura FT232RL funciona como se esperaba. También noté que en el Uno, la secuencia de parpadeo parecía ser más rápida que el mismo boceto que se ejecuta en mi tablero. Hmmm ...

Así que configura la placa de prueba de nuevo, obteniendo resultados confusos. Luego, pensando en un parpadeo más lento en comparación con la ejecución en Uno, cambié la velocidad en baudios en el lado de Linux 9600 - > 4800. Hey! ¡Ya no está confuso!

El boceto cree que se está enviando a 9600, así que parece que estoy fuera por un factor de 2 en algún lugar. ¿Es mi cristal 4 MHz en lugar de 8? No noté ningún fusible u otra configuración que cambiaría el tiempo por un factor de 2.

Estoesloquecreoqueelproblemaes:estoycompilandoconlaplacaobjetivoconfiguradaen"Arduino Uno", la cual Creo que esto usa una constante F_CPU = 16000000UL. Luego subo a mi placa de pruebas que ejecuta un oscilador de 8 Mhz, la mitad del valor esperado.

    
pregunta Steve

2 respuestas

2

El hecho de que estés obteniendo algo me indica que podría haber algún problema con tu reloj real o esperado. ¿Hay un pin en el que puedas medir el reloj? ¿Definió su cristal / frecuencia correctamente como lo requiere la biblioteca en serie que está utilizando?

    
respondido por el AJBotha
1

Esa placa azul parece una variante de Sparkfun USB a Serial Breakout enlace usando el FTDIchip.com FT232RL en el paquete 28SSOP . Este tablero en particular parece ser Folger Technologies enlace No hablan mucho acerca de las especificaciones de la placa, pero probablemente es casi como todas las otras tarjetas USB FT232R.

Hoja de datos de FT232R disponible del fabricante: enlace

Verifique que la salida de transmisión de TXos / ttl TX desde ATmega328 esté impulsando la entrada de recepción de RX cmos / ttl en el FT232R, y la salida de TXOS / ttl de FT232R esté impulsando la entrada RX cmos / ttl de ATmega328. (El error más común con UART serie es conectar TX a TX).

A 9600 baudios (8 bits, sin paridad, 1 bit de inicio, 1 bit de parada), cada carácter tarda 10/9600 = 1.042msec en transmitirse, y 26 caracteres deben tomar aproximadamente 27msec. ¿Puedes pedir / pedir prestado un osciloscopio para mirar la señal de TX? Esa es la única forma de descubrir qué está pasando aquí.

Nunca he visto que un oscilador de cristal de alta frecuencia haya funcionado nunca en una placa de pruebas blanca sin soldadura; a menudo hay una capacitancia parasitaria significativa que causa efectos de carga no deseados en frecuencias más altas. Es posible que desee considerar (¿me atrevo a decirlo?) Probar su firmware en una de las placas Arduino comúnmente disponibles, ya que ya sabe más sobre electrónica que el usuario objetivo de Arduino, puede cargar su propio firmware personalizado, no sabe tienen que usar su IDE / bootloader / shields / etc. Tener un diseño de PCB probado / verdadero debería funcionar mejor que un tablero sin soldadura. Sparkfun vende un Arduino Pro Mini 328 que tiene un factor de forma mucho más agradable, que en realidad podría enchufar en una placa de pruebas, pero que tiene el circuito del oscilador de cristal en un diseño de PCB. enlace

    
respondido por el MarkU

Lea otras preguntas en las etiquetas