Download TP Puerto Serie - Parte 3
Document related concepts
no text concepts found
Transcript
Ingeniería en Informática Sistemas Operativos Trabajo de Investigación “Segunda parte de Optimización del Puerto Serie” Equipo Docente Nicanor Casas Graciela De Luca Waldo Valiente Gerardo Puyo Sergio Martín Federico Díaz Sebastián Deuteris GRUPO: 3 Días de Cursada: Miércoles / Viernes 19 a 23 hs. Apellido Campodónico Holgado Saizar Godoy Alumnos Nombre Facundo Sergio Victoria DNI 30.860.213 29.246.646 32.359.515 Fecha Calificación Acreditación: Instancia PRE-ENTREGA ENTREGA FINAL Universidad Nacional de la Matanza Sistemas Operativos ÍNDICE OBJETIVO DEL TP 3 Alcance 3 RESUMEN DEL DOCUMENTO Y EXPLICACIÓN DE SU ESTRUCTURA 4 TEORÍA 4 Configuración de la Máquina Virtual Bochs en Windows 4 Transmisión de datos en modo real 6 PRÁCTICA 8 Introducción práctica al tema a tratar UART Control de Flujo 8 8 10 Resumen de modificaciones Funciones 11 11 Resumen de agregados Funciones Variables Parches a bajar al SDK 12 12 13 13 Documentación de las funciones y programas –del Doxygen-. Qué hacen Qué devuelven Qué parámetros lleva Cómo se usa (con un ejemplo) 14 14 14 14 14 Forma de uso de los comandos pr_series pr_fifo cfg_serie activarchat activarlogserie 15 15 15 15 16 17 Caso de ejemplo Entrada (Caso de prueba) Proceso (Forma de ejecutarlo) Salida (¿Es la esperada?) 17 17 17 18 Programas utilizados Putty Hércules SublimeText Meld 19 19 20 22 22 CONCLUSIONES 23 REFERENCIAS 25 ANEXO A 26 Página 2 de 27 Universidad Nacional de la Matanza Sistemas Operativos Objetivo del TP El objetivo del presente trabajo es continuar con la optimización de las actuales funcionalidades que brinda el driver de Puerto Serie. Para ello partimos de una versión de SODIUM, realizada por un grupo anterior, que contaba con funcionalidades básicas. Inicialmente el TP fue dividido en dos etapas / entregas: 1. Integración con versión “Programación Segura”1: Se trata de unificar la rama del proyecto SODIUM que contiene las mejoras realizadas de programación segura con la que contiene el desarrollo del driver de Puerto Serie. 2. La optimización en sí misma que constó de varias tareas: ● La implementación de mecanismos de control de flujo durante la transmisión de datos, tanto por hardware como por software, con la finalidad de sincronizar la comunicación serial entre el Sistema Operativo y la terminal remota. ● La ejecución de las tareas necesarias para permitir la utilización del buffer FIFO presente en los chips UART, permitiendo, además que el umbral de interrupciones sea configurable mediante la ejecución del script configurar.sh. ● La optimización del envío y recepción de datos utilizando el puerto COM para permitir transmitir correctamente un único carácter o una cadena de string a la vez. ● La configuración necesaria de la Máquina Virtual Bochs en Windows para poder utilizar una imagen del Sistema Operativo SODIUM con la implementación del Puerto Serie. ● Efectuar correctamente el envío y recepción de datos a otra terminal en modo real utilizando el puerto serial, es decir, enviar y recibir datos durante la primera etapa de inicialización del Sistema Operativo (mientras el mismo se encuentra ejecutando en modo real). Alcance ● Implementar mecanismos de control de flujo en la transmisión de datos por puerto serie. ● Utilización del buffer FIFO de los chips UART. ● Configuración de máquina virtual Bochs para que funcione en Windows con una imagen del Sistema Operativo SODIUM. ● Transmisión de datos en modo real. 1 Esta etapa del TP se trata en el “Anexo A”. Página 3 de 27 Universidad Nacional de la Matanza Sistemas Operativos Resumen del documento y explicación de su estructura El presente documento trata paso a paso los cambios que fueron necesarios para cumplimentar cada uno de los puntos prácticos solicitados y la explicación de los puntos teóricos requeridos. El componente teórico trata los siguientes ítems: ▪ Cómo y por qué se debe configurar la Máquina Virtual Bochs en Windows para poder utilizar una imagen del Sistema Operativo SODIUM con la implementación del Puerto Serie. ▪ Las distintas formas en las cuales es factible llevar a cabo la transmisión de datos mediante el puerto serie durante la ejecución de SODIUM en modo real. Ambos ítems facilitan la comprensión de los conceptos que serán aplicados luego en los puntos teóricos. El componente práctico explica todos aquellos cambios llevados a cabo en la estructura de archivos de SODIUM, y agregados de nuevas bibliotecas, ficheros de código, funciones y variables. Teoría Configuración de la Máquina Virtual Bochs en Windows La máquina virtual Bochs es un emulador altamente portable, publicado bajo la licencia GNU/GPL y escrito en C++, el cual corre en la mayoría de las plataformas populares. Incluye una emulación de la CPU Intelx86, dispositivos I/O tradicionales y una BIOS personalizada. Bochs puede ser compilada para emular diferentes CPUs x86, desde 386 hasta los más recientes procesadores de Intel y AMD x86-64. Bochs es capaz de correr la mayoría de Sistemas Operativos dentro de la emulación, incluyendo Linux, DOS o Microsoft Windows. La configuración de las opciones de Bochs se realiza a través de un archivo de configuración llamado bochsrc.bxrc .En este archivo se especifica la máquina a emular, indicando qué discos tiene, diskettes, memoria, procesador, puerto serie, etc. A continuación hay un ejemplo de bochs.bxrc: Página 4 de 27 Universidad Nacional de la Matanza Sistemas Operativos Junto con Bochs pueden encontrar un archivo bochs.bxrc de ejemplo con comentarios detallando el funcionamiento de cada opción. Si el programa se encuentra instalado en /usr/local/bin/ entonces este archivo de ejemplo se puede encontrar en /usr/local/share/doc/bochs/bochsrc-sample.txt. INSTALACIÓN DE LA MÁQUINA BOCHS EN WINDOWS La versión utilizada de “Bochs For Windows” es la 2.6.6 (la que utiliza SODIUM en la máquina virtual actualmente es la 2.5.1). La misma se encuentra adjuntada en la carpeta "BochsForWindows" dentro de la carpeta “Documentación”. Se adjunta también en la carpeta el archivo de recursos bochsrc.bxrc que debe colocarse dentro del directorio de instalación de Bochs. La imagen utilizada de SODIUM (también incluida) debe colocarse también dentro del directorio de instalación de Bochs con el nombre "sodium_fat12.img" ya que es el nombre con el que se encuentra en el archivo de recursos, en caso de querer utilizar otro, debe cambiarse el archivo de recursos y colocar en la línea correspondiente el nombre de la imagen deseada. Con esto, ya podemos ejecutar el Bochs recién instalado, por sí mismo leerá el archivo de configuración debido a que el nombre utilizado en el mismo es el que utiliza el Bochs por defecto. Y al darle a "start", ejecutará y deberemos utilizar el “Putty”, en modo RAW con dirección "localhost" y puerto "12345". El valor del puerto puede cambiarse dentro del archivo de recursos en la última línea. Página 5 de 27 Universidad Nacional de la Matanza Sistemas Operativos Transmisión de datos en modo real ● Para comenzar a comprender este tema haremos una breve de descripción sobre el “modo real” y la diferencia con el “modo protegido”: El modo real (también llamado modo de dirección real en los manuales de Intel) es un modo de operación del 8086 y posteriores CPUs compatibles de la arquitectura x86. El modo real está caracterizado por 20 bits de espacio de direcciones segmentado (significando que solamente se puede direccionar 1 MB de memoria), acceso directo del software a las rutinas del BIOS y el hardware periférico, y no tiene conceptos de protección de memoria o multitarea a nivel de hardware. Todos los CPUs x86 de las series del 80286 y posteriores empiezan en modo real al encender el computador; los CPUs 80186 y anteriores tenían sólo un modo operacional, que era equivalente al modo real en chips posteriores. La arquitectura 286 introdujo el modo protegido, permitiendo, entre otras cosas, la protección de la memoria a nivel de hardware. Sin embargo, usar estas nuevas características requirió instrucciones de software adicionales innecesarias previamente. Puesto que una especificación de diseño primaria de los microprocesadores x86 es que sean completamente compatibles hacia atrás con el software escrito para todos los chips x86 antes de ellos, el chip 286 fue hecho para iniciarse en ' modo real ' - es decir, en un modo que tenía apagadas las nuevas características de protección de memoria, de modo que pudieran ejecutar sistemas operativos escritos para microprocesadores más viejos. Al día de hoy, incluso los más recientes CPUs x86 se inician en modo real al encenderse, y pueden ejecutar el software escrito para cualquier chip anterior. De la misma manera, SODIUM también arranca en modo real siguiendo el siguiente esquema: Es durante la ejecución de Sodium.bin donde cambia el modo de operación. Por tanto, esa es la ubicación elegida para realizar el envío y recepción de texto utilizando el puerto serie. ● Respecto a la utilización del puerto serie en modo real: Existen dos formas de comunicarse con el puerto serie: 1) Usar las funciones del BIOS. Permite abrir el puerto COM1 y enviar datos utilizando la interrupción del BIOS, INT 0x14. Hay ciertas interrupciones designadas para que programas de usuario se comuniquen con el sistema de software para acceder a diversos servicios estándar como el acceso a la unidad de disquete, disco duro, vga, reloj, etc. Si el programador no usa estos servicios entonces debe entender muy bien los detalles del hardware que está manipulando, como por ejemplo qué controlador particular se está usando y cómo funciona. Para Página 6 de 27 Universidad Nacional de la Matanza Sistemas Operativos evitar esto y proporcionar interoperabilidad es que se provee esta interfaz de software para dispositivos de hardware básicos. Esta interfaz básica para el hardware se llama BIOS (Basic Input Output Service). Cuando el ordenador está encendido, el BIOS toma el control en una dirección específica. Los mensajes en pantalla al momento del arranque que muestran la versión del BIOS, la detección de hardware, etc. son de este código. BIOS tiene la responsabilidad de poner a prueba el hardware básico incluyendo video, teclado, unidad de disquete, disco duro, etc. y un programa especial para arrancar. Bootstrap significa cargar el sistema operativo desde el disco duro y de a partir de allí el SO toma el control y procede a cargar sus componentes y mostrar un símbolo del sistema en el final. Hay dos programas importantes; BIOS y sistema operativo. Los servicios del sistema operativo son de alto nivel y se basan en los servicios de la BIOS. Los servicios de BIOS son de muy bajo nivel. Un nivel más inferior, hace referencia a la siguiente opción, el control sólo directamente el hardware. 2) Usar las instrucciones de I/O para acceder directamente a los registros de la UART (a la dirección 0x3f8 para el COM1). Aunque, en teoría, el diseño original de la PC permite a los diseñadores de sistemas implementar la comunicación con el puerto serie utilizando cualquier hardware que deseen, la mayor parte del software de hoy en día realiza esta tarea comunicándose de forma directa con la UART. Esto presenta los mismos problemas de compatibilidad que se tienen al dialogar directamente con el hardware del puerto paralelo. Sin embargo, mientras el BIOS proporciona una excelente interfaz para el puerto paralelo, el soporte de serie no es tan bueno. Por lo tanto, es una práctica común eludir las funciones de interrupción del BIOS (INT 14h) y controlar la UART directamente para que el software puede acceder a cada bit de cada registro. Quizás un problema aún más importante con la BIOS es que no soporta interrupciones. Por esto cualquier software que requiera utilizar interrupciones necesitará trabajar directamente con la UART y evitar BIOS de cualquier manera. Manipular el puerto serie no es difícil pero sí contiene varios registros para proveer las diversas características. Por lo tanto, se necesita una gran cantidad de código para controlar todas las funciones del chip. Esta fue la opción utilizada. Página 7 de 27 Universidad Nacional de la Matanza Sistemas Operativos Práctica Introducción práctica al tema a tratar En nuestro trabajo se ven involucrados los varios conceptos relacionados con la programación del puerto serie y la configuración típica del hardware que lo compone: El puerto SERIE (RS-232) o COM (puerto de comunicación) es un adaptador asíncrono utilizado para poder intercomunicar dos terminales (DTE/DCE) entre sí. El puerto envía y recibe información a través de un cable, y dentro de las terminales la misma es tratada a través del driver de comunicación SERIE. Los puertos serie dependen de un chip especial como controlador, el Universal Asynchronous Receiver/Transmitter (UART), para funcionar correctamente. La UART es un circuito integrado diseñado para implementar la comunicación serie y es el encargado de manejar la transmisión de datos a través del puerto serie, cuyas funciones principales son manejar las interrupciones como también la conversión de datos de serie a paralelo y viceversa (lo veremos con más profundidad más adelante). UART En el interior de puerto serie hay un chip para la entrada y salida de caracteres y para la conversión de palabras de datos en las correspondientes señales del puerto serie: lo que se denomina UART (Universal Asynchronous Receiver Transmitter-Emisor y Receptor Asíncrono Universal). El UART dispone de 10 registros accesibles desde el exterior (vía software) y de registros adicionales accesibles sólo internamente, tales como el Receiver Shift Register y el Transmitter Shift Register, fundamentales en la emisión y recepción de caracteres. Si la UART recibe un caracter, los diferentes bits que se van recibiendo se amontonan primero en el Receiver Shift Register hasta que se completa una palabra de datos. Si no aparece ningún fallo, el byte es transferido al Receiver Data Register desde donde puede ser leído vía software. En sentido contrario, el software escribe primero la palabra de datos a enviar en el Transmitter Holding Register. En ese punto la UART lo traslada al registro interno Transmitter Shift Register para, desde ahí, transmitir los diferentes bits, uno detrás del otro, a través de la línea. Página 8 de 27 Universidad Nacional de la Matanza Sistemas Operativos La falta de buffer habría limitado el funcionamiento del chip en ratios de baudios elevados. Ya que era frecuente que un carácter recién llegado al Receiver Data Register fuera eliminado por la sobrescritura del siguiente carácter dándose así un Overrun Error, teniéndose que reducirse el ratio de baudios, de modo que funcionase la comunicación entre el emisor y el receptor. A partir del 16550A (UART) se disponen de buffer: Receiver Buffer Register (recepción) y el Transmitter Holding Register (envío). Ambos buffers trabajan bajo el principio FIFO (First in first out). El de envío juega un papel secundario pues el ordenador, al enviar, puede determinar por sí mismo la cadencia del envío, con lo que apenas existe la posibilidad de autoexigirse en exceso. El buffer de recepción representa una gran ayuda, aunque vía software se tendrá que realizar la inicialización del UART y la estructuración de la rutina para la lectura de caracteres. En el modo de funcionamiento por Polling, se consulta primero el Line Status Register para saber si hay algún carácter disponible en el RBR. Si es así, se lee el carácter y a continuación se inicia el proceso de nuevo. Si todavía no hay caracteres preparados en el buffer interno, la UART, inmediatamente después de la lectura del carácter del RBR, activará de nuevo el bit correspondiente del Line Status Register de modo que este carácter sea automáticamente recogido en el próximo bucle. Es un bucle de este tipo lo primero que falta en la mayoría de administradores de interrupciones de puertos serie, pues, mientras la UART no tiene ningún carácter en un buffer interno, es suficiente con leer una vez el RBR al llamar a la interrupción y entonces esperar a la siguiente llamada a una interrupción para recibir el siguiente carácter. Al instalar el buffer tiene que implementarse en cambio en el administrador de interrupciones un bucle en cuyo proceso continuamente se lee un carácter del RBR hasta que el Line Status Register indica que ya no hay más caracteres en el RBR para ser leídos. En este momento se han leído todos los caracteres del buffer interno pues, por su parte, la UART habría empujado el resto de caracteres que todavía se encontrasen en el buffer, tras la lectura de sus precedentes, hacia el RBR. Página 9 de 27 Universidad Nacional de la Matanza Sistemas Operativos Para continuar siendo compatible con sus antecesores el 16550A desactiva su buffer interno mientras no se le diga explícitamente lo contrario. Para ello existe un nuevo registro el Interrupt ID Register. Mientras que el Interrupt ID Register sólo puede ser leído, el nuevo registro del 16550 para el funcionamiento en FIFO sólo puede ser escrito. Con ello es posible dividir la dirección entre uno y otro registro con lo que en función del tipo de acceso, el UART diferencia a qué registro se quiere acceder. Esta es la estructura del FCR - FIFO Control Register: Control de Flujo El control de flujo proporciona la capacidad para detener e iniciar la transmisión de datos en función de la capacidad (libre y ocupada) de los búferes. El objetivo del control de flujo es evitar que se llenen los búferes, ya que esto puede causar la pérdida de datos. Control de flujo por hardware y software Existen dos tipos de control de flujo: por hardware y por software. ● Control de flujo por hardware El control de flujo de hardware en el puerto serie funciona así: Se utilizan dos pines, el RTS (Request to send - Solicitud de envío) y CTS (Clear to send - Libre para enviar). Cuando el equipo está preparado para recibir datos confirma RTS, poniendo una señal positiva en el pin RTS (que significa "Solicitud para enviarme"). Cuando el equipo detecta que un búfer está al 90% de su capacidad no es capaz de recibir más bytes, se niega RTS poniendo una tensión negativa en el pin diciendo: "Dejar de enviarme". Página 10 de 27 Universidad Nacional de la Matanza ● Sistemas Operativos Control de flujo por software El control de flujo por software al detectar que un búfer está al 90% de su capacidad, y envían caracteres especiales en la secuencia de datos para detener el flujo de datos. Cuando la capacidad del búfer baja hasta el 20%, envía caracteres especiales en la secuencia de datos para reiniciar el flujo de datos. El problema del control de flujo por software es que los caracteres utilizados para detener (<Ctrl>Q) e iniciar (<Ctrl>S) el flujo de datos pueden aparecer de forma natural en dicho flujo. La activación del control de flujo por software indica al módem que reconozca y actúe cuando aparezcan estos caracteres, incluso si no han sido enviados para controlar el flujo de datos. El uso del control de flujo por software puede resultar satisfactorio si sólo se transfieren archivos de texto. El comando para iniciar se denomina XON (activar transmisión) y para detener XOFF (desactivar transmisión). Resumen de modificaciones Funciones 1) /fuente/kernel/system.c Función modificada: ● int iInicializarConfiguracionKernel(char* stBufferConfiguracion) Descripción: Al habilitar nuevas opciones de seteo en el archivo de configuración, agregamos nuevas líneas para que las mismas puedan ser tomadas y cargadas en las variables del sistema. 2) /fuente/usr/sodshell.c Función modificada: ● int main() Descripción: En esta función se agregaron las líneas que permiten la utilización de las nuevas funciones: - pr_fifo: Creada para vaciar el buffer FIFO que implementamos. - cfg_serie: Nos permite consultar la configuración del puerto serie y configurar la misma pasando parámetros. - activarlogserie: Función que al ser ejecutada activa el logueo de datos, si se desea apagar se vuelve a ejecutar. 3) /fuente/kernel/drivers/com.c Funciones modificadas: ● u8 bFnInicializarCom(int iPuerto, int iFlags) ● void vFnComEnviarBufferPolling(int iPuerto, unsigned char *buffer, int iTamanio) ● void vFnComEnviarBufferIRQ(int iPuerto, unsigned char *buffer, int iTamanio) ● void vFnLeerByteCom(int iPuerto) ● int vFnSetBaudios(int iPuerto, int iBaudios) Página 11 de 27 Universidad Nacional de la Matanza Sistemas Operativos ● void ISRCOMC(int iPuerto) Descripción: - bFnInicializarCom Se modificaron parámetros de los registros y ahora las modificaciones tanto en el LCR como en FCR, se realizan por medio de variables, las cuales pueden ser modificadas utilizando la función cfg_serie. - vFnComEnviarBufferIRQ Se respeta el funcionamiento anterior, agregando control de flujo por software y hardware. - vFnLeerByteCom Se agregó el control de flujo por software, es decir controla la llegada de caracteres de control. - vFnSetBaudios Se modificó un divisor el cual tenía un valor erróneo y generaba problemas con las transmisiones a 9600 y 11200 baudios. - void ISRCOMC(int iPuerto) Incluimos en la función 4 sectores que manejan los distintos tipos de interrupción de forma específica: a. Recepción de datos con FIFO b. Recepción de datos sin FIFO c. Envío de datos d. Manejo de errores A partir del manejo de interrupciones, que se mejoró en cuanto a la cantidad de interrupciones que nos informa, se agregaron la carga de buffer y los controles de flujo correspondientes. 4) /fuente/kernel/sodium.asm Se realizaron modificaciones para que sea posible el envío y la recepción en modo real. El procedimiento que permite realizar esta tarea lo encontramos en la etiqueta LogCadenaSerie. a. ConfiguraPuertoSerie Configura el puerto serie estableciendo valores: Velocidad = 9600 Largo de palabra = 8 bits Habilita FIFO Umbral de Interrupciones = 1 Deshabilita interrupciones b. LogCadenaSerie Enviar cadenas de string en el puerto serie y espera en respuesta un caracter en particular para continuar con la carga del sistema operativo. c. RecibirCaracterSerie Realiza una espera activa aguardando la recepción del caracter “c” para continuar con la ejecución de SODIUM. Resumen de agregados Funciones 1) /fuente/kernel/scrap.c Funciones agregadas: Página 12 de 27 Universidad Nacional de la Matanza Sistemas Operativos ● void vFnImprimirConfiguracionComSerie(int iParametroPasado1, int iParametroPasado2) ● void vFnImprimirSerieTestFifo() ● void vFnChatSodium() Descripción: - void vFnImprimirConfiguracionComSerie: Esta función nos permite mostrar por pantalla la configuración actual del puerto serie y, por medio de parámetros, modificar la configuración actual. El comando es cfg_serie y con el parámetro “-a” nos va a mostrar la ayuda con todas las configuración que se pueden realizar. - void vFnImprimirSerieTestFifo() Esta función es para limpiar el buffer, se utiliza durante las pruebas. - void vFnChatSodium() Esta función permite realizar un chat entre el SODIUM y el Putty. Lo que se escriba en SODIUM saldrá en el terminal remoto y lo que se escriba en el terminal remoto, saldrá en SODIUM. Se finaliza al ingresar '$' en alguna de las 2 sesiones. Variables 1) fuente/include/drivers/com.h Se agregan nuevas variables globales: ● char stBufferFifoComEscritura[COM_TAMANIO_BUFFER]; ● char stBufferFifoComLectura[COM_TAMANIO_BUFFER]; ● int iComBufferFifoEntrada; ● int iComBufferFifoSalida; ● int iComBufferFifoTamanio; ● int iComBufferFifoTamanioMin; ● int iComBufferFifoTamanioMax; ● int iModoFifoSerie; ● int iCantidadTriggerLevel; ● int iModoControlDeFlujo; ● int iEstadoControlDeFlujoSoftwareEntrada; ● int iEstadoControlDeFlujoSoftwareSalida; ● int iEstadoControlDeFlujoHardwareEntrada; ● int iEstadoControlDeFlujoHardwareSalida; ● int iSeteoCantidadBitsSerie; ● int iSeteoParidad; ● int iSeteoBitParada; Parches a bajar al SDK La única modificación requerida fue una actualización de los repositorios. El archivo modificado fue source.list, que sirve para actualizar las direcciones de los repositorios de la versión Ubuntu que está en el SodiumDevkit. El link donde está alojado el archivo es: https://drive.google.com/file/d/0B6rrzgz2LrrfVENfTnFNOWdOLU0/edit?usp=sharing Página 13 de 27 Universidad Nacional de la Matanza Sistemas Operativos Documentación de las funciones y programas –del Doxygen-. Doxygen es un generador de documentación para C++, C, Java, Objective-C, Python, IDL (versiones Corba y Microsoft), VHDL y en cierta medida para PHP, C# y D. Dado que es fácilmente adaptable, funciona en la mayoría de sistemas Unix así como en Windows y Mac OS X. Qué hacen Doxygen ayuda de tres formas distintas: 1. Puede generar documentación disponible en línea (HTML) y/o manuales de referencia (in ) a partir de un conjunto de archivos de código fuente bien documentado. También brinda soporte para generar salidas en RTF (MS-Word), PostScript, PDF, HTML comprimido, y páginas de manual de Unix (man pages). La documentación es enteramente extraída de las fuentes, lo que facilita mantenerla actualizada y consistente con el código fuente. 2. Puede configurar Doxygen para extraer la estructura del código de los archivos de origen indocumentados. Esto es muy útil para extraer la estructura de todo aquel código que no haya sido documentado. También resulta útil para ubicarse rápidamente dentro de funciones que tienen gran cantidad de código fuente. Doxygen permite visualizar las relaciones entre elementos a través de gráficos de dependencias, diagramas de herencia y diagramas de colaboración que se general automáticamente. 3. Puede usar Doxygen para crear documentación normalmente. Qué devuelven Se obtiene el documento de información en alguno de los formatos indicados anteriormente. Qué parámetros lleva La estructura que debe darse es la siguiente: /* * @brief * @params NomParam1 descr * @params NomParam2 descr * @returns * @author * @date */ 1. 2. 3. 4. 5. @brief: Descripción de la función @params: Explicación de los parámetros que recibe @returns: Explicación del valor devuelto @author: Nombre del Autor @date: Fecha de la creación o última modificación importante Cómo se usa (con un ejemplo) Ejemplo visto en la función vFnComEnviarBufferIRQ de com.c: /** * @brief Envía datos del puerto serie con interrupciones. * @param iPuerto puerto serie utilizado. * @param buffer para enviar el texto. Página 14 de 27 Universidad Nacional de la Matanza Sistemas Operativos * @param piTamanio Longitud de lo que se va a enviar. * @date 20/10/2013 */ Forma de uso de los comandos pr_series Permite enviar datos desde la consola remota hacia SODIUM. Para su utilización escribir en SODIUM: Cmd> pr_series En SODIUM podrá ver el siguiente mensaje: “Por favor escriba cualquier caracter en la terminal cliente, o ingrese '$' para salir...” Y en la consola remota: “Por favor escriba cualquier caracter para mostrar en el SODIUM, o ingrese '$' para dejar de enviarlos...” A partir de este momento podrá introducir texto en la consola remota el cual será visualizado en SODIUM. Debe presionar la tecla ‘$’ para finalizar y volver al prompt (Cmd>). pr_fifo Vacía el buffer de lectura interno a la vez que muestra los datos eliminados. Para su utilización escribir en SODIUM: Cmd> pr_fifo SODIUM presentará el siguiente mensaje “--VACIADO DE BUFFER DE LECTURA--” y a continuación se mostrarán línea por línea los caracteres eliminados. La ejecución termina con “--FIN VACIADO DE BUFFER DE LECTURA--” y retorna automáticamente al prompt. cfg_serie Este comando imprime por pantalla la configuración actual (previa al cambio) del puerto serie y permite, a través del envío de distintos parámetro, cambiar la configuración del mismo. Para su utilización escribir en SODIUM: Cmd> cfg_serie [-a|-b|-c|-d|-f|-m|-p] [parámetro_de_configuración] Opciones: 1) cfg_serie Muestra la configuración del puerto serie: el modelo de la UART, la dirección del puerto COM, la velocidad de transmisión, el modo de operación (interrupciones o polling), el largo de la palabra, la configuración de paridad, los bits de parada, si está o no habilitada la FIFO y cuál es el umbral de interrupciones, si está usando control de flujo y si es por hardware o por software. Página 15 de 27 Universidad Nacional de la Matanza Sistemas Operativos 2) cfg_serie -a Introducir el parámetro “a” muestra la ayuda, un resumen de las opciones de uso. Las siguiente opciones cambian valores de la configuración del puerto, por ello, al finalizar se reinicia el COM. El valor indicado en el segundo parámetro indica la nueva configuración, pero si el mismo no pertenece a las opciones listadas a continuación se omite la operación. 3) cfg_serie -b [600|1200|2400|4800|9600|19200|38400|56000|112000] Permite cambiar la velocidad de transmisión. 4) cfg_serie -c [0|1|2] Permite cambiar la configuración del control de flujo. a. 0 - Indica control de flujo desactivado b. 1 - Indica control de flujo por hardware c. 2 - Indica control de flujo por software 5) cfg_serie -d [1|2] Permite cambiar los bits de stop. a. 1 - 1 bit de stop b. 2 - 2 bits de stop (1,5 en palabras de 5 bits) 6) cfg_serie -f [1|4|8|14] Permite cambiar la configuración del FIFO2. a. 1 - Habilita el FIFO con 1 byte de umbral de interrupciones b. 4 - Habilita el FIFO con 4 bytes de umbral de interrupciones c. 8 - Habilita el FIFO con 8 bytes de umbral de interrupciones d. 14 - Habilita el FIFO con 14 bytes de umbral de interrupciones 7) cfg_serie -m [1|2] Permite cambiar el modo de trabajo. a. 1 - Interrupciones b. 2 - Polling 8) cfg_serie -p [0|1|2|3|4] Permite cambiar la configuración de la paridad. a. 1 - Sin paridad b. 2 - Paridad par c. 3 - Paridad impar d. 4 - Marca de paridad e. 5 - Espacio activarchat Permite mantener un diálogo entre SODIUM y la consola remota. Es útil para verificar el correcto funcionamiento del puerto serie. 2 Cabe destacar que la FIFO UART 16550A, la utilizada en este caso, tiene una capacidad de 16 bytes, dicho esto, el umbral de interrupciones (trigger level) hace referencia al punto en el cual se dispara la interrupción. Página 16 de 27 Universidad Nacional de la Matanza Sistemas Operativos Para su utilización escribir en SODIUM: Cmd>activarchat En SODIUM podrá ver los siguientes mensajes: “--INICIO TEST CHAT SERIE --” “Por favor escriba cualquier caracter en la terminal cliente, o ingrese '$' para salir...” Y en la consola remota: “Escriba lo que desea enviar a SODIUM y recibirá lo que se escriba en el, o ingrese '$' para dejar de enviarlos…” A partir de este momento se podrá introducir texto en ambas terminales simultáneamente. Para terminar se deberá presionar la tecla ‘$’ indistintamente en SODIUM o en la consola remota. Se mostrará el mensaje “--FIN CHAT TEST SERIE--” y se regresará al prompt (Cmd>). activarlogserie Habilita o deshabilita el logueo por pantalla para controlar el funcionamiento del flow control y de FIFO. Para su utilización escribir en SODIUM: Cmd> activarlogserie El resultado es: si loguear está desactivado, lo activa; si loguear está activado, lo desactiva. Caso de ejemplo Entrada (Caso de prueba) - Comando: cfg_serie -b 11200 Resultado esperado: Se espera que cambie la velocidad de transmisión del puerto serie. Se puede verificar ejecutando nuevamente el comando cfg_serie sin parámetros. Proceso (Forma de ejecutarlo) - El comando es interpretado por usr/sodshell.c El mismo dispara la ejecución de un callgate que, a partir de kernel/syscall.c termina derivando en la función que lo trata. La función se encuentra en kernel/scrap.c y se llama “vFnImprimirConfiguracionComSerie”. La función comienza por mostrar la configuración actual del puerto y luego pregunta por el valor del parámetro 1. Página 17 de 27 Universidad Nacional de la Matanza - - Sistemas Operativos Al detectar como primer parámetro una “b” entra a una porción de código que compara el segundo parámetro con valores específicos esperados para la configuración de velocidad. Luego de validar el parámetro, modifica la variable iVelocidadOperacion que será utilizada en el siguiente paso. Antes de finalizar llama a una función de kernel/drivers/com.c que reinicializa el puerto COM con la nueva configuración, la función es “bFnInicializarCom”. Salida (¿Es la esperada?) - Podemos verificar si el cambio se produjo correctamente ejecutando nuevamente el comando cfg_serie pero esta vez sin parámetros. Página 18 de 27 Universidad Nacional de la Matanza Sistemas Operativos Programas utilizados Putty http://www.putty.org/ PuTTY es un emulador de terminal, un programa que permite conectar con máquinas remotas y ejecutar programas a distancia. PuTTY se conecta como cliente a múltiples protocolos, como SSH, Telnet o Rlogin. ● Configuración para conectar con SODIUM en VMware Player: - Elegir en “Connection Type” la opción “Raw”; - Introducir en “Host Name” la dirección IP asignada a la máquina virtual; - Introducir en “Port” el puerto 12345; - Si se desea, guardar la conexión introduciendo un nombre en “Saved Sessions” y hacer clic en el botón “Save”; - Abrir la conexión haciendo clic en el botón “Open”. ● Configuración para conectar con SODIUM en Windows: - Elegir en “Connection Type” la opción “Raw”; - Introducir en “Host Name” el texto “localhost”; - Introducir en “Port” el puerto 12345; - Si se desea, guardar la conexión introduciendo un nombre en “Saved Sessions” y hacer clic en el botón “Save”; - Abrir la conexión haciendo clic en el botón “Open”. Página 19 de 27 Universidad Nacional de la Matanza ● Sistemas Operativos Configuración para conectar con SODIUM en otra PC: - Elegir en “Connection Type” la opción “Serial”; - Introducir en “Serial Line” el número de puerto COM asignado; - Introducir en “Speed” la velocidad (9600); - En el menú de la izquierda como última opción aparece “Serial”, allí se puede configurar, además, el largo de la palabra, los bits de parada, la paridad y el control de flujo. - Si se desea, guardar la conexión introduciendo un nombre en “Saved Sessions” y hacer clic en el botón “Save”; - Abrir la conexión haciendo clic en el botón “Open”. Hércules http://www.hw-group.com/ Este programa incluye terminales para Puerto Serie (RS232 o RS485), UDP/IP y TCP/IP (cliente o servidor). La terminal para puerto serie implementada trabaja con puertos serie virtuales y controla todas sus líneas. Es freeware. ● Configuración para conectar con SODIUM en VMware Player: 1- Abrir Hercules.exe Modo de conexión Test Mode: Página 20 de 27 Universidad Nacional de la Matanza Sistemas Operativos 2- En la sección TCP ingresamos IP asignado por la máquina virtual y el puerto: 3-Luego tenemos dos opciones en la sección de “Send Data” podemos escribir normalmente caracter por caracter, mientras que en la sección de “Send” nos permite enviar cadenas completas. Esta última opción es muy útil para realizar las pruebas del FIFO. ● Configuración para conectar con SODIUM en otra PC: 1- Abrir Hercules.exe Modo de conexión TCP Cliente: Página 21 de 27 Universidad Nacional de la Matanza Sistemas Operativos 2- En donde dice TCP se ingresa la IP y el Puerto: Le damos Connect. 3- Escribimos cadenas de caracteres en la sección de “Send”: SublimeText http://www.sublimetext.com/ Sublime Text es un editor de código que se destaca por lo ligero y simple, y por su aspecto visual sencillo. Lo elegimos como opción al Eclipse debido a que éste consumía muchos recursos de la máquina virtual y dificultaba el trabajo. Meld http://meldmerge.org/ Meld es una herramienta visual para hallar diferencias y para fusionar documentos. Ayuda a comparar archivos, directorios y proyectos de control de versiones. Proporciona la posibilidad de comparar dos y hasta tres vías de archivos y directorios, y tiene soporte para muchos sistemas de control de versiones populares. Lo utilizamos principalmente en la primera etapa del trabajo para fusionar las dos versiones “Puerto Serie” y “Programación Segura”. Página 22 de 27 Universidad Nacional de la Matanza Sistemas Operativos Conclusiones En el transcurso del desarrollo de las funcionalidades solicitadas encontramos algunos puntos del TP que requirieron revisión: 1) Configurar.sh. - Fue un cambio importante dado que errores en el código forzaban a que, para obtener un Makefile.cfg correcto, fuera necesario seguir un orden específico al elegir las opciones. Este punto fue solventado y nuevas opciones para configurar el puerto serie fueron agregadas al menú: 2) Se halló un problema en la configuración de los parámetros del puerto, en particular en el valor asignado al divisor para las velocidades de transmisión. El mismo fue corregido y así mismo se agregó la posibilidad de elegir una velocidad máxima extra para la transmisión (112000 baudios) 3) En la primera entrega se solicitó la unificación de dos proyectos de grupos anteriores, Puerto Serie y Programación Segura. Para que estos logren compilar sin inconvenientes y funcionar, al menos en la máquina virtual, hubo que realizar modificaciones en los siguiente archivos: consola.c y floppy.c. Igualmente a pesar de funcionar en la máquina virtual al utilizar la imagen en la máquina real para probar nos daba error. Así mismo se agregaron algunos puntos extras: 1) El comando cfg_serie que bajo el uso de parámetros permite configurar los distintos valores del puerto, sin la necesidad de volver a ejecutar el script configurar.sh y recompilar el SODIUM. Mediante la opción cfg_serie -a se puede acceder a la ayuda: Página 23 de 27 Universidad Nacional de la Matanza Sistemas Operativos 2) En la versión original de Puerto Serie solo se utilizaba el valor de velocidad para configurar la transmisión. Adicionalmente a eso se requiere establecer otros parámetros para lograr una comunicación exitosa, estos son: longitud de palabra, paridad, bit de stop, y la habilitación de la FIFO con el correspondiente umbral de interrupciones. Se agregó la posibilidad de configuración y ciertos valores por default para cada uno de los ítems. Mejoras propuestas ● Mejorar el funcionamiento del modo Polling. Proponemos realizar un fork que esté chequeando continuamente el LCR para verificar si hay información para ser leído. ● Modularizar aún más el contenido de com.c de modo de aumentar la comprensión del código, facilitar la modificación del mismo, etc. ● Analizar por qué en la función iFnObtenerComando de sodshell.c trata de manera diferente a los dos parámetros que recibe junto con el comando: 1) *iArgumento = iFnHtoi (stArg); 2) *iArgumento2 = iFnCtoi (stArg); Página 24 de 27 Universidad Nacional de la Matanza Sistemas Operativos Referencias Las páginas consultadas: ● ● ● ● ● ● ● ● http://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Programming http://www.tldp.org/HOWTO/Serial-HOWTO-18.html#ss18.3 http://www.lammertbies.nl/comm/info/serial-uart.html http://www.moxa.com/resource_file/509820091121333.pdf http://en.wikipedia.org/wiki/Software_flow_control http://es.tldp.org/COMO-INSFLUG/COMOs/Serie-Como/Serie-Como.html#toc12 https://www.freebsd.org/doc/en/articles/serial-uart/ http://members.tripod.com/mi_red/trabajos1.html La bibliografía consultada: ● ● ● ● “TP Puerto Serie – SODIUM.doc”: Documentación generada por el grupo que desarrolló la versión original del “Puerto Serie”. “PC16550D Universal Asynchronous Receiver/Transmitter with FIFOs”: Hoja de datos de la UART 16550D de Texas Instruments. “PC16552D Dual Universal Asynchronous Receiver/Transmitter with FIFOs”: Hoja de datos de la UART 16552D de Texas Instruments. “The NS16550A: UART Design and Application Considerations”: Copyright de National Semiconductor Corporation. Página 25 de 27 Universidad Nacional de la Matanza Sistemas Operativos Anexo A En la primera etapa del trabajo el objetivo fue unificar dos versiones de SODIUM que se venían trabajando en cuatrimestres anteriores, “Programación Segura” y “Puerto Serie”. La intención era continuar la segunda parte del TP usando esta integración para poder aprovechar las mejoras realizadas en Programación Segura. Pero dado a errores en ambas versiones se decidió continuar el trabajo tomando como base la versión original de Puerto Serie. La integración se realizó de la siguiente manera: ● Se comenzó distinguiendo las diferencias entre ellos utilizando la aplicación Meld para comparar los directorios. A grandes rasgos los resultados fueron: → Raíz (4 archivos) 1. boot (reemplazado por “solo” en Programación Segura) 2. build (1 archivo) 3. common (4 archivos) 4. docs (sin diferencias) 5. herramientas (2 archivos) 6. include 1.1. common (4 archivos) 1.2. kernel (11 archivos) 1.2.1. drivers (11 archivos + 1 archivo que solo existe en Puerto Serie) 1.2.2. fs (2 archivos) 1.2.3. interfaz (1 archivo) 1.2.4. mem (2 archivos) 1.2.5. planif (1 archivo) 1.3. usr (1 archivo + 1 que solo existe en Programación Segura + 2 archivos que solo existen en Puerto Serie) 1.3.1. bin (sin diferencias) 1.3.2. lib (sin diferencias) 1.3.3. tst (sin diferencias) 7. kernel (11 archivos) 1.1. drivers (11 archivos + 1 archivo que solo existe en Puerto Serie) 1.1.1. teclado (sin diferencias) 1.2. fs (2 archivos) 1.3. interfaz (1 archivo) 1.4. mem (2 archivos) 1.5. planif (1 archivo) 8. solo (reemplazado por “boot” en Puerto Serie) 9. usr (3 archivos + 1 archivo que solo existe en Programación Segura + 3 archivos que solo existen en Puerto Serie) 1.1. bin (1 archivo + 1 archivo que solo existe en Programación Segura + 1 archivo que solo existe en Puerto Serie) 1.2. lib (5 archivos) 1.3. tst (1 archivo + 1 archivo que solo existe en Programación Segura + 1 archivo que solo existe en Puerto Serie) Página 26 de 27 Universidad Nacional de la Matanza Sistemas Operativos ● En resumen se hallaron las siguientes diferencias: → Archivos con diferencias: 82 → Archivos existentes solo en un proyecto (sin distinción): 15 ● Luego de la unificación, que se llevó a cabo dividiendo la lista anterior entre los integrantes, comenzó la etapa de pruebas para identificar los posibles errores. ● Archivos que tuvimos que modificar: - usr/sodshell.c include/kernel/gdt.h kernel/gdt.c (faltaban parámetros en 2 llamadas a funciones (buscar "por SH")) kernel/system_asm.asm (un conflicto y una etiqueta puesta por demás) kernel/system.c (buscar "por SH") kernel/drivers/usbhub.c (un error en una variable, agregado un “if” para la función iFnCopiaCadena) kernel/drivers/lusb.c (faltaban parámetros en una función) kernel/interfaz/consola.c (faltaba parámetro en una función, revisar uso de funciones Copia(…)valores e Imprime(…)valores) kernel/mem/sodheap_kernel.c (errores en el pasaje desde Programación Segura) kernel/fs/fat12.c (se agregó el 0 como parámetro “propiedad” en todas las llamadas a funciones vFnLog) kernel/system_asm.asm (errores de transcripción) kernel/drivers/lsusb.c kernel/drivers/usbhub.c Página 27 de 27