¿Por qué el convertidor de puerto usb a serie no puede programar el microcontrolador avr?

Con un puerto serie o un puerto paralelo en la PC, la programación del microcontrolador avr es muy fácil y económica. El problema es que ninguna computadora moderna viene con puerto serial o paralelo. Entonces, el convertidor de usb a serie debería ser la solución, pero desafortunadamente no.

Debe haber una diferencia entre el puerto serie real y el puerto serie convertido. ¿Qué es?

Otra pregunta relacionada sería, ¿cómo USBasp se comunica casi directamente con la PC? Pensé que la mayoría o todos los microcontroladores de la serie ATmega no tienen soporte usb.

He comprobado este enlace: programador AVR con convertidor de serie a USB

Sé que hay varias preguntas como esta, pero como soy nuevo en la programación integrada, necesito una explicación fácil para entender el concepto. Gracias.

Editar: quiero usar un circuito como el siguiente con la interfaz serial convertida (posiblemente, RS232). Este circuito está diseñado para el puerto serial real. Con un puerto serial convertido, podría reducir la complejidad del circuito.Esquema del programador serial.

Los detalles se pueden encontrar en Simple Serial Programmer para AVR

Muchos pueden, aunque menos que idealmente. Consulte, por ejemplo, arduino.stackexchange.com/questions/3361/…
El USBasp "aproximadamente" implementa el estándar de interfaz USB de menor velocidad con una red que "más o menos" acopla las señales hacia y desde los pines GPIO y un software excesivamente inteligente que lee o escribe los estados de los pines aproximadamente en el momento adecuado.

Respuestas (3)

El programador en serie que está usando está usando un puerto en serie para conectarse a la computadora, ¡pero no el protocolo estándar RS232! Eche un vistazo más de cerca al esquema:

  • el pin 4 (DTR) está asignado a MOSI. En un verdadero puerto serie de la placa base, este pin se puede alternar alto y bajo, emulando así un modo bitbang
  • pin 6 (DSR) y 7 (RTS) están asignados a SCK. Como DTR, RTS se puede configurar alto o bajo, por lo que junto con DTR permite la implementación de software de protocolos seriales sincrónicos personalizados
  • El pin 8 (CTS) es un pin de entrada asignado a MOSI. Su valor se lee en el conmutador SCK.

DTR y RTS son los únicos pines del puerto serial que pueden ser bitbanged. Pero existe la necesidad de una señal de reinicio. El diseñador de ese adaptador usa un truco. Envía un carácter 0x00 sin bits de parada sobre RS232 TX estándar, creando así un breve pulso de reinicio (que para algunas MCU debe invertirse).

Los datos reales en una comunicación serie RS232 estándar se envían solo a través de líneas Rx/Tx. Todas las demás son líneas accesorias utilizadas por los dispositivos para señalar diferentes estados de funcionamiento o para señalar la disponibilidad de datos o la finalización de la transferencia.

Este es el problema con los adaptadores serie USB. La mayoría de ellos solo pueden usar líneas Rx/Tx y, por supuesto, solo el protocolo serial RS232 (asíncrono), que de ninguna manera es compatible con el protocolo de programación AVR (SPI, síncrono). Entonces, la única forma de comunicarse a través del puerto serie por SPI es usar líneas alternativas y emular el protocolo en el software.

Puede ver en este foro que en algunos casos funciona con adaptadores serie USB, pero en la mayoría de las situaciones no es así.

Pensé que la mayoría o todos los microcontroladores de la serie ATmega no tienen soporte usb.

Que dices de: ATmega 8U2, 16U2, 16U4, 32U2, AT90USB1286, AT90USB1287, AT90USB162, AT90USB646, AT90USB647, AT90USB82. Lista completa desde aquí .

¡Pero USBasp no está usando una de esas MCU! Si observamos su esquema, podemos ver que utiliza una resistencia pull-up en la línea D, lo que significa que le indica a la PC que es un dispositivo de baja velocidad (1,5 Mb/s). Y el software emula el bus USB a través de un puerto de E/S de uso general (se puede ver en el código fuente del firmware AVR - archivo usbconfig.h):

#define USB_CFG_IOPORTNAME      B
/* This is the port where the USB bus is connected. When you configure it to
 * "B", the registers PORTB, PINB and DDRB will be used.
 */
#define USB_CFG_DMINUS_BIT      0
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
 * This may be any bit in the port.
 */
#define USB_CFG_DPLUS_BIT       1
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
 * This may be any bit in the port. Please note that D+ must also be connected
 * to interrupt pin INT0!
 */
#define USB_CFG_CLOCK_KHZ 12000
/* Clock rate of the AVR in MHz. Legal values are 12000, 16000 or 16500.
 * The 16.5 MHz version of the code requires no crystal, it tolerates +/- 1%
 * deviation from the nominal frequency. All other rates require a precision
 * of 2000 ppm and thus a crystal!
 * Default if not specified: 12 MHz
 */
Oye, puedes eliminar tu comentario ya que actualizaste la respuesta y es correcto. Eliminaré el mío en breve ya que los comentarios sobre esto ahora son irrelevantes.
@Cornelius Solo tengo curiosidad; Estoy usando un Teensy con el boceto "Benito" y creó una conexión en serie a través de USB y luego conecta su puerto UART, que es simplemente una serie de hardware en el nivel TTL. Así que tampoco estoy usando RS232 (el adolescente no lo tiene a bordo). Así que pensé que debería poder usar un cable USB serie en su lugar y me topé con este hilo. ¿Podrías aclararlo por favor? ¡Gracias!
@JulianF.Weinert puede usar convertidores de USB a serie para el protocolo RS232 UART estándar. No debería importar si el dispositivo serie utiliza un puerto emulado de hardware o software, siempre que sea compatible con el protocolo estándar.
@Cornelius seguro. Tal vez no estaba un poco claro aquí. La implementación en realidad solo está desplazando cada bit recibido fuera del puerto serie. No veo ninguna evidencia de RS232. ¿Qué me diría exactamente si estoy haciendo "RS232 real" o una serie arbitraria?

Algunos pensamientos de mi cabeza basados ​​en una amarga experiencia:

  • Solo use convertidores FTDI USB-Serial, son de lejos los más confiables, configurables y con mejor soporte. Otros pueden funcionar bien, pero es una lotería y la vida es demasiado corta para un hardware errante.

  • Verifique que la salida "en serie" del chip sea realmente lo que realmente desea; Los convertidores pueden generar datos seriales de nivel RS232, TTL (0-5v) completos o datos seriales 0-3v3 y, a veces, RS485/RS422, según el convertidor.

  • Como se mencionó, hay otras configuraciones como bits de inicio/parada, paridad, almacenamiento en búfer, modos bit-bang, etc., que pueden causar problemas.

El almacenamiento en búfer en el chip o controlador de serie USB puede causar problemas especialmente cuando el software de programación intenta ejecutar retrasos de tiempo específicos durante la programación. Los controladores FTDI le permiten cambiar todas estas cosas.

La recomendación para los chips FTDI habría sido cierta cuando se escribió, pero dado que FTDI comenzó a lanzar controladores que bloquean chips no originales, y muchas personas que compran adaptadores FTDI no saben si su chip es genuino, comprar FTDI ahora es la opción más riesgosa. Sin mencionar que algunos pueden verlo como una razón para no apoyar a esa empresa.
@Al sr. Esa es una noticia bastante vieja ahora, y FTDI recibió tanta reacción negativa que es poco probable que lo intente nuevamente. Tampoco cambia la verdad subyacente de que sus dispositivos siguen siendo los mejores en términos de confiabilidad y compatibilidad. Para proyectos comerciales, comprar chips FTDI genuinos sigue siendo una obviedad.
Lo último que escuché fue que se retractaron de la creación de ladrillos, pero continúan haciendo que los controladores no funcionen en ellos. Y, nunca reconocieron completamente el enladrillado. Si esa situación ha cambiado, sería bueno.
Y nuevamente, para un producto comercial o cualquier cosa que realmente le interese que funcione correctamente, no hay problema si compra chips FTDI genuinos de un proveedor de confianza.

Para poder programar dichos dispositivos, es posible que el puerto SERIAL deba configurarse para operar en modo bitbang. La mayoría de los convertidores USB <-> serie no ofrecen esa capacidad.

Dependiendo del tipo de convertidor USB <-> SERIAL, es posible que pueda "configurarlo" para facilitar dicho modo.

www.ftdichip.com/Documents/AppNotes/AN232B-01_BitBang.pdf

Los chips FT232BM y FT245BM se pueden configurar en un modo especial donde se reemplaza la función normal de los chips. Este modo cambia las 8 líneas de datos del FT245BM o las líneas de datos y control RS232 del FT232BM a un bus bidireccional de 8 bits . El propósito de este modo estaba destinado a ser utilizado para programar dispositivos FPGA. También se puede usar para hablar con EEPROM seriales o cargar un latch de datos.

Eso no tiene ningún sentido. La mayoría de los puertos serie "reales" no tienen un "modo bitbang". ¿Estás pensando en puertos paralelos?
@DaveTweed: la mayoría de los puertos serie reales permiten girar las líneas de control con una latencia más baja (y potencialmente una mejor coordinación con el estado de las líneas de datos) que las mediadas por USB. Muchos dispositivos serie USB probablemente puedan hacerlo, solo que más lentamente. Pero algunos ofrecen modos bitbang/GPIO especiales (después de todo, suelen ser microcontroladores con firmware especial)
@Dave Tweed Los chips FT232BM y FT245BM se pueden configurar en un modo especial donde se reemplaza la función normal de los chips. Este modo cambia las 8 líneas de datos del FT245BM o las líneas de datos y control RS232 del FT232BM a un bus bidireccional de 8 bits. El propósito de este modo estaba destinado a ser utilizado para programar dispositivos FPGA. También se puede usar para hablar con EEPROM seriales o cargar un latch de datos. TAMBIÉN. bitwizard.nl/wiki/index.php/FTDI_ATmega Verifique antes de votar negativamente.
@Naib: No entendiste la pregunta. El OP pregunta por qué la programación funciona con puertos serie "reales", pero NO con convertidores de USB a serie. Soy muy consciente de que algunos convertidores de USB a serie admiten un modo de operación "bit-bang" de precisión de alta velocidad.
@Cornelius: Eso no es lo que dije. Dije que los puertos seriales "reales" no pueden aprovechar las líneas de datos Tx y Rx como lo hacen algunos convertidores de USB a serie.
@DaveTweed: en realidad, parece que uno puede controlar un pin SOUT 16450/16550 sin enviar datos UART pero usando el bit BREAK para un ESPACIO y el bit de modo de bucle invertido para una MARCA. Eso, junto con dos líneas de estado de escritura y una línea de estado de lectura, lo haría. En cualquier caso, se sabe que la gente ha hecho ATmega ISP con puertos serie "reales". Y es posible por otros medios con algunos convertidores USB-serie. Lo que no está claro es si es posible manipularlos lentamente usando API seriales en lugar de modos especiales.
Los puertos seriales "reales" de @DaveTweed pueden acercarse: vivara.net/blog/?p=24
@markrages: eso es lindo, pero no particularmente relevante. El envío de datos PWM en función de la cantidad de bits activos en una palabra no implica de ninguna manera que uno pueda satisfacer la secuenciación perfectamente ordenada de múltiples señales que necesita un periférico serial síncrono. En cambio, lo que se necesita es una forma de establecer el estado de una señal y dejarla mientras se manipula otra, y un UART no proporciona eso cuando se opera en modo estándar . Sin embargo, muchas partes pueden estar en modos alternativos/de prueba.
¿Por qué el convertidor de puerto usb a serie no puede programar el microcontrolador avr?
RespuestasAquíPolítica de privacidad1y, 2v