Novato en serie: ¿por qué no puedo conectar los cables?


14

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 opportunity

Hay 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.

Respuestas:


9

Definitivamente puede transmitir datos usando solo TX y GND.

En primer lugar, desea conectar la línea ATtiny85 TX a la línea FTDI RX (amarilla en el TTL-232R). Asegúrese de que el adaptador USB puede manejar 5V: estoy bastante seguro de que incluso el 3.3L TTL-232R es tolerante a 5V.

De acuerdo con la página de ejemplo de SoftwareSerial , debe establecer la dirección de las líneas TX y RX en su función de configuración:

// include the SoftwareSerial library so you can use its functions:
#include <SoftwareSerial.h>

#define rxPin 2
#define txPin 3
#define ledPin 13

// set up a new serial port
SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);
byte pinState = 0;

void setup()  {
  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
}

La velocidad de transmisión será de 4800 en su caso. La biblioteca SoftwareSerial no parece admitir CTS y RTS, así que asegúrese de no usarlos en el software host.

Consulte la página de referencia para obtener más detalles, donde hablan sobre algunos posibles problemas de temporización que pueden exacerbarse si está ejecutando a 1MHz usando el oscilador interno en el pequeño.


¡Gracias! La página de referencia dejó en claro que 4800 era demasiado rápido, así que bajé a 300 baudios y las cosas están "mejor". El pinMode no afecta la transmisión, pero de todos modos lo agregué para aclarar las cosas. Ahora estoy intentando reducir el retraso entre bits hasta que se reciba algo. ¿Minicom solo está mostrando? marcas en este momento. En el peor de los casos, mis osciladores de 16mhz y 20mhz llegan el viernes.
Jack Schmidt

¿Crees que podría ser el problema de voltaje? Ajustar el tiempo todavía no ha funcionado, y recibo muchos signos de interrogación, por lo que se está transmitiendo algo. ¿Puedo arreglarlo simplemente bajando el Vcc al pequeño a 3V, es decir, puedo conectarlo a algunas baterías en lugar de USB? ¿Conecto la tierra a la tierra del USB y a la batería?
Jack Schmidt

Ah, también gracias por señalar que el cable amarillo es para que mi pequeño pueda transmitir. El cable naranja parece parpadear mucho (conectado a un LED de la PC). ¿La PC está transmitiendo o permanece "encendida" la mayor parte del tiempo?
Jack Schmidt

Sí, debería permanecer HI cuando está inactivo y parpadear cuando transmite; no estoy seguro de si el FTDI es capaz de suministrar suficiente corriente para conducir un LED. El AVR estará bien, pero eliminaría el LED de la línea FTDI-TX. Crystal debería solucionar los problemas de sincronización (pero debe configurar los fusibles para cambiar desde el oscilador interno).
Peter Gibson

Todavía estoy trabajando en ello, pero estoy convencido de que es un problema de tiempo o un horrible problema de software Arduino-on-ATTiny. Se reciben unos 2-3 bytes intermedios (pero no se muestran) y el resto se confunde como 0x80. Voy a escribir mi propia (trivial) función de envío en serie suave de AVR mientras espero el cristal. ¿Hay alguna forma fácil / barata de ver lo que se envía? 300 baudios todavía es bastante rápido para mis viejos ojos.
Jack Schmidt

7

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.


2
+1 para 1 es más aerodinámico :) El FTDI TTL232R emite señales uart de nivel lógico (0-5V), si estuviera interactuando directamente con un puerto serie estándar, necesitaría una interfaz IC como el MAX232, que convierte el voltaje niveles en ambos sentidos.
Peter Gibson

Felicidades por hacerlo funcionar. Gracias por tu publicación detallada, espero que esto ayude a muchas otras personas con sus proyectos ATtiny.
davidcary
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.