Download TP Puerto Serie - Parte 3

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