Sí, puedes implementar un UART en el software. Aquí hay uno en el ensamblaje 8051, que debería funcionar para su microcontrolador. Esta técnica se llama bit banging .
Suponiendo que "serial" quiere decir RS-232 ¹, y suponiendo que está hablando con algo que en realidad quiere RS-232 y no "TTL serial" , aún necesitará un desplazador de nivel RS-232 externo como un MAX232 .
El problema con el software UART es que RS-232 no tiene una línea de reloj separada². Como tal, la comunicación confiable depende de la precisión de tiempo de los dispositivos en ambos extremos de la conexión. Por lo tanto, no desea probar y proporcionar un software UART si el reloj de sus instrucciones no es exacto, como ocurre con muchos osciladores RC internos. El AT89S52 que está utilizando no tiene la opción de un oscilador interno, pero aún necesita asegurarse de que su oscilador externo tenga una precisión del 1% del valor nominal de un UART de software para lograr una comunicación confiable.
Además de eso, para que el tiempo de ciclo de la instrucción central del procesador se divida uniformemente en el tiempo de bit de RS-232, debe seleccionar las frecuencias impares del oscilador. 11.0592 MHz es popular para esto. Otra opción es 14.7456 MHz, como se explica aquí .
La frecuencia de reloj afecta a los bucles de retardo codificados que necesita en un enfoque de bit banging. Eso es lo que el bit DJNZ R0,$ está en el código de ensamblaje al que te señalé: es un bucle de retardo puro, que no hace más que disminuir un contador para reducir el tiempo. En la parte superior del archivo, ve la constante BITTIM , que codifica esta implementación en particular para que su sincronización funcione cuando se usa un reloj de CPU de 11.0592 MHz. Si cambia la frecuencia del reloj, también tiene que cambiar esta constante. Luego, debe probarlo nuevamente con cuidado para asegurarse de que el tiempo sea lo suficientemente bueno. A veces es necesario agregar NOP o instrucciones similares para compensar el tiempo de espera con enfoques de bit banging como este.
Cuanto más baja sea la velocidad de sus datos en serie, más holgura podrá evitar. Por lo tanto, si solo necesita 1,200 bps, es posible que pueda salirse con un oscilador RC interno o una velocidad de reloj de instrucción μC "normal", particularmente si no está transmitiendo o recibiendo continuamente. A la inversa, mi experiencia es que si necesita ejecutar más rápido que 9,600 bps o más, realmente necesita un UART de hardware.
Footnotes
-
Hay muchas formas diferentes de comunicación en serie . Cuando se usa de forma genérica, el término más a menudo significa RS-232 , pero se basa en las etiquetas definidas aquí en Electronics.SE, I²C , < a href="http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus"> SPI , CAN , y RS-485 son bastante comunes.
RS-485 : Creo que todo lo anterior se aplica también a RS-485, así como a su pariente cercano RS-422 .
I²C and SPI : incluyen una línea de reloj síncrona, por lo que la mayoría de lo que he escrito anteriormente no se aplica a estos métodos de comunicación. Sin embargo, también es posible implementarlos en software mediante bit banging.
CAN bus : no es posible implementar en software, debido a la necesidad de CSMA / BA .
Todavía hay otras formas de comunicación en serie que son simplemente demasiado rápidas para implementar en el software para un μC típico, como USB , Ethernet , PCI Express y SATA . Puede implementarlas en los FPGA, pero esa es una pregunta aparte.
-
Bueno, no con DB-9 RS-232, ni ninguna de las variantes comunes de conteo de pin inferior. La versión original de RS-232 basada en DB-25 hizo a un lado un par de pines para los relojes de emisor y receptor (15 y 17), pero en mis décadas de experiencia con RS-232, nunca he usado un dispositivo que realmente dependa de su presencia.