Estoy tratando de transmitir desde un ATtiny85 a una PC usando el código Arduino-esque a través de un convertidor USB-Serie sin entender mucho de nada. Me sorprendió y horrorizó que no funcionó.
Confirmé que el pequeño está parpadeando el voltaje en uno de sus pines, pero cuando conecto ese pin para transmitir o recibir en el cable serie USB e intento escuchar usando un programa de terminal, no obtengo nada.
No estoy seguro de cómo saber qué parte está rota.
¿Necesito más que VCC, GND y TXD para transmitir en serie?
Detalles:
El código para el pequeño está escrito en el entorno Arduino y un código similar parpadea con éxito los 4 pines "PORTB", al menos según los LED. Utilizo el código de HLT y Saporetti para permitirme usar el dialecto Arduino de C ++ para programarlo. El programa todavía viene bajo una K.
#include <SoftwareSerial.h>
SoftwareSerial s(0,1); //receive on "0", and transmit on "1" aka "PB1" aka pin 6
void setup() { s.begin(4800); } // assuming 1Mhz, 4800 baud
void loop() { s.println(millis()); } // transmit something at every opportunityHay mucha traducción involucrada, pero el código es bastante básico. El código que establece la velocidad en baudios parece asumir 1MHz, pero afortunadamente mi attiny tiene fusibles predeterminados de fábrica y funciona a 1MHz. En cualquier caso, el pin 6 parpadea su voltaje de acuerdo con el LED.
Así que uso los pequeños cables para conectar el extremo "ftdi" del convertidor de serie USB FTDI al minúsculo: negro a GND, rojo a VCC, naranja a 6. Abro el programa "minicom" en la PC, configuro los baudios califica a 4800 y espera, para nada. Cuando hablo con mi Boarduino , no tiene problemas.
El cable del convertidor FTDI tiene el siguiente pinout: el negro es GND, el marrón es "CTS", el rojo es VCC (+ 4.98V), el naranja es "TXD", el amarillo es "RXD", el verde es "RTS".
Si quiero transmitir desde el pequeño a la PC, ¿debería estar parpadeando el voltaje en "TXD" o "RXD"? En otras palabras, ¿el cable de transmisión se transmite desde el esclavo al host o el host al esclavo?
En realidad probé ambos, ninguno funcionó. Hasta ahora he frito menos de un dólar en equipo, y me estoy volviendo arrogante, así que solo conecto los cables al cable. ¿Tal vez se supone que no debo ignorar los cables "CTS" y "RTS"?
¿Necesito usar otros cables? ¿RTS y CTS hacen algo?
El hardware es un ATTiny85-PU (paquete DIP-8, que funciona a 1MHz, clasificado a 20MHz) alimentado por USB a 4.98V. La PC host es una MacBook, y realiza con éxito todas las cosas de arduino, incluido el uso de ArduinoISP para programar el ATtiny para que parpadee.
Entonces, la respuesta parece ser: puede conectar los cables, de hecho solo GND (negro) y RXD (amarillo), y todo funciona siempre que el software sea bueno.
Cosas que no importaron:
El oscilador interno funciona bien. Parece relativamente estable a mis pruebas limitantes. A 9600 baudios, cualquier problema que tenga es insignificante.
El uso de alimentación USB en las señales funciona bien. Puede usar una fuente de voltaje separada (que comparte una tierra común), pero el cable FTDI lee perfectamente las señales de 3V y 5V. Conecté una batería, - a GND tanto del FTDI como del pequeño, + al VCC del pequeño, y esto funcionó bien. Sin embargo, solo usar el VCC (rojo) del FTDI (USB power 5V) es mucho más simple e igual de efectivo.
Cosas que hice mal:
La línea amarilla FTDI "RXD" recibe bits del microcontrolador, por lo que se conecta a la transmisión en el microcontrolador. Podría haberlo descubierto yo mismo conectando las líneas de transmisión y recepción (naranja y amarillo) a los LED o un Arduino y comprobando qué voltaje parpadeaba cuando transmitía desde la PC.
Ni SoftwareSerial ni NewSoftSerial funcionan de inmediato con un ATtiny. Si bien el ATmega328p y el ATtiny85 comparten muchas similitudes, hay suficientes diferencias que simplemente no es suficiente obtener el software antiguo para compilar el nuevo chip.
Las velocidades de transmisión más lentas no curan las cosas. 300 baudios requieren rutinas de retardo más complicadas ya que el número de ciclos entre bits es significativamente mayor que un contador de 8 bits. 9600 baudios funciona bien, y las velocidades de baudios más altas son factibles.
Tenga cuidado de escribir el código crítico de sincronización en C, especialmente en las funciones en línea. El tiempo que se tarda en ejecutar dependerá de cómo lo optimice el compilador. En particular, al calibrar el retraso simplemente cambiándolo hacia arriba y hacia abajo, obtendrá una respuesta diferente que cuando se usa un retraso constante (tiempo de compilación detectable), porque el conjunto generado puede ser bastante diferente. No es que C sea "lento", sino que fue demasiado rápido. En un momento estaba enviando 1s más rápido que 0s (presumiblemente son más aerodinámicos).
Para iniciar una transmisión, lleva la línea BAJA (el bit de inicio) y luego debe asegurarse de que la línea esté en el voltaje correcto en cada uno de los siguientes 8 puntos de muestra, y luego asegúrese de que el voltaje sea ALTO en la novena muestra . NewSoftSerial menciona hacer un retraso de media longitud en el bit de inicio, pero esto no funcionó bien para mí. Utilicé un retraso del 75% al inicio y un retraso del 125% al final.
La verdadera preocupación sobre el voltaje podría ser que algunos "en serie" (especialmente RS232) son ± 12V, no 0V / 5V. Pasé mucho tiempo tratando de entender cómo podía ajustar el voltaje de 5V a 3.3V, pero creo que eso era completamente irrelevante.
En cualquier caso, transmitir en serie es fácil, pero obtener el tiempo "perfecto" parece bastante importante. Para mí, esto era solo una cuestión de codificar la transmisión en ensamblado para poder contar los ciclos.
fuente