universidad de alcalÁ escuela universitaria … · universidad de alcalÁ escuela universitaria...

UNIVERSIDAD DE ALCALÁ

Escuela Universitaria Politécnica

INGENIERÍA TÉCNICA DE TELECOMUNICACIONES

Especialidad en Sistemas Electrónicos

Trabajo Fin de Carrera

Diseño de una interfaz basada en DSP para el acceso vía radio a una red local (II)

Autor: D. Roberto López Díaz

Director: D. José Manuel Villadangos Carrizo

TRIBUNAL:

Presidente: D. Pedro Martín Sánchez

Vocal 1º: D. Raúl Mateos Gil

Vocal 2º: D. José Manuel Villadangos Carrizo

CALIFICACIÓN:

FECHA:

Diseño de una Interfaz basada En DSP para el acceso vía radio a una red local II

Página 2 de 156

ÍNDICE

Página

1. RESUMEN................................................................................................................................................... 7

2. INTRODUCCIÓN....................................................................................................................................... 8

3. OBJETIVOS ................................................................................................................................................ 9

3.1. DESCRIPCIÓN DEL PROYECTO ....................................................................................................... 10

4. RED LOCAL INALÁMBRICA ............................................................................................................... 13

4.1. TOPOLOGÍA DE LA RED.................................................................................................................... 13 4.1.1. TOPOLOGÍA EN ESTRELLA ....................................................................................................... 14 4.1.2. TOPOLOGÍA EN ANILLO............................................................................................................ 15 4.1.3. TOPOLOGÍA EN ÁRBOL ............................................................................................................. 16 4.1.4. TOPOLOGÍA COMPLETA........................................................................................................... 16 4.1.5. TOPOLOGÍA DE RED INALÁMBRICA AD-HOC....................................................................... 17 4.1.6. TOPOLOGÍA DE RED INALÁMBRICA INFRAESTRUCTURE.................................................. 18 4.1.7. TOPOLOGÍA DE RED ADOPTADA............................................................................................ 19

4.2. PROBLEMA DE COLISIONES ............................................................................................................ 20 4.3. ALGORITMO DE TIEMPOS DE ESPERA ALEATORIOS ................................................................ 20

4.3.1. CÁLCULO DEL TIEMPO DE ESPERA ALEATORIO ................................................................. 22 4.3.1.1. TIEMPO DE RETARDO EN CONMUTACIÓN DE LOS TRANSCEPTORES.................................... 22 4.3.1.2. NÚMERO MÁXIMO DE USUARIOS E ÍNDICE DE OCUPACIÓN.................................................... 22 4.3.1.3. TIEMPO DE ESPERA PARA EL GATEWAY....................................................................................... 24

4.4. DIRECCIONAMIENTO IP.................................................................................................................... 24 4.5. PROTOCOLO RPP ................................................................................................................................ 25

4.5.1. BYTE 0. SINCRONIZACIÓN ........................................................................................................ 27 4.5.2. BYTE 1. IDENTIFICADOR DE INICIO DE TRAMA RPP........................................................... 27 4.5.3. BYTES 2 Y 3. LONGITUD DE LA TRAMA................................................................................... 28 4.5.4. BYTE 4. DIRECCIÓN ORIGEN.................................................................................................... 28 4.5.5. BYTE 5. DIRECCIÓN DESTINO.................................................................................................. 29 4.5.6. BYTES 6 Y 7. CHECKSUM O SUMA DE COMPROBACIÓN..................................................... 29 4.5.7. FUNCIONAMIENTO GENERAL DEL PROTOCOLO RPP ........................................................ 29

4.5.7.1. EN TRANSMISIÓN................................................................................................................................. 29 4.5.7.2. EN RECEPCIÓN...................................................................................................................................... 31

4.6. VELOCIDADES DE TRANSFERENCIA PUNTUAL Y TASA DE TRANSFERENCIA MÁXIMA 32 4.6.1. SUPUESTO 1: TRANSMISIÓN ÚNICA DEL GATEWAY ............................................................ 33 4.6.2. SUPUESTO 2: N ESTACIONES SIN GATEWAY ......................................................................... 33 4.6.3. SUPUESTO 3: N ESTACIONES CON GATEWAY ....................................................................... 34

4.7. LIMITACIONES AL NÚMERO MÁXIMO DE USUARIOS .............................................................. 37

5. DISPOSITIVO DE COMUNICACIONES EN LINUX .......... ............................................................... 38

5.1. INTRODUCCIÓN A LINUX................................................................................................................. 38 5.2. CARACTERÍSTICAS DE LINUX ........................................................................................................ 39

5.2.1. DISTRIBUCIONES ....................................................................................................................... 40 5.3. DISPOSITIVOS DE COMUNICACIONES EN LINUX....................................................................... 41

5.3.1. DEFINICIÓN DE CONCEPTOS .................................................................................................. 41 5.3.1.1. DISPOSITIVO O INTERFAZ.................................................................................................................. 41 5.3.1.2. PROTOCOLO .......................................................................................................................................... 41 5.3.1.3. ENLACE .................................................................................................................................................. 42 5.3.1.4. SK-BUFF.................................................................................................................................................. 42

5.3.2. IMPLEMENTACIÓN DE LOS SK-BUFF..................................................................................... 42 5.3.2.1. skb_dequeue()........................................................................................................................................... 43 5.3.2.2. skb_queue_head()..................................................................................................................................... 43


Página 3 de 156

5.3.2.3. skb_queue_tail() ....................................................................................................................................... 43 5.3.2.4. skb_unlink().............................................................................................................................................. 43 5.3.2.5. skb_insert() Y skb_append().....................................................................................................................44 5.3.2.6. alloc_skb() ................................................................................................................................................ 44 5.3.2.7. kfree_skb .................................................................................................................................................. 44 5.3.2.8. skb_clone.................................................................................................................................................. 44 5.3.2.9. skb_copy() ................................................................................................................................................ 44

5.3.3. RUTINAS DE SOPORTE DE ALTO NIVEL ................................................................................. 44 5.3.3.1. sock_queue_rcv_skb() .............................................................................................................................. 44 5.3.3.2. sock_alloc_send_skb().............................................................................................................................. 45

5.3.4. DISPOSITIVOS DE RED.............................................................................................................. 45 5.3.5. ESTRUCTURA BÁSICA................................................................................................................ 45 5.3.6. DENOMINACIÓN DE LOS DISPOSITIVOS DE RED................................................................. 46

5.4. PROGRAMACIÓN DEL DISPOSITIVO EN LINUX .......................................................................... 47 5.4.1. INICIALIZACION ......................................................................................................................... 47 5.4.2. ACTIVACION Y DESACTIVACION ............................................................................................. 52 5.4.3. TRANSMISION ............................................................................................................................. 53

5.4.3.1. BÚFFER DE TRANSMISION................................................................................................................. 53 5.4.4. RECEPCION................................................................................................................................. 54

5.4.4.1. BÚFFER CIRCULAR.............................................................................................................................. 55 5.4.5. INTERRUPCION TEMPORAL ..................................................................................................... 57

5.4.5.1. CONTROL DE RECEPCIÓN.................................................................................................................. 57 5.4.5.2. CONTROL DE TRANSMISIÓN............................................................................................................. 58

5.4.6. DIRECCIÓN RPP ......................................................................................................................... 59 5.4.7. INTERRUPCIÓN DE LA UART.................................................................................................... 60 5.4.8. AÑADIR EL DRIVER AL NÚCLEO DE LINUX........................................................................... 60

5.5. DISPOSITIVO DE ENRUTAMIENTO DE LINUX ............................................................................. 64 5.5.1. CONFIGURACIÓN DEL DISPOSITIVO DE ENRUTAMIENTO................................................. 65

5.5.1.1. LISTA DE ENCAMINAMIENTO DE UN USUARIO ........................................................................... 66 5.5.1.2. LISTA DE ENCAMINAMIENTO DEL GATEWAY ............................................................................. 66

6. DISEÑO DE LA INTERFAZ BASADA EN DSP................................................................................... 68

6.1. CARACTERÍSTICAS GENERALES.................................................................................................... 68 6.2. DESARROLLO HARDWARE DE CADA BLOQUE .......................................................................... 69

6.2.1. ORDENADOR PERSONAL .......................................................................................................... 70 6.2.2. ALIMENTACIÓN .......................................................................................................................... 70

6.2.2.1. CIRCUITO INTEGRADO MC7805 ........................................................................................................ 72 6.2.3. INTERFAZ RS – 232 ..................................................................................................................... 73

6.2.3.1. CIRCUITO INTEGRADO MAX 232 ...................................................................................................... 74 6.2.4. DSP 56002 .................................................................................................................................... 74

6.2.4.1. SEÑALES PARA EL BLOQUE DE MEMORIA.................................................................................... 77 6.2.4.2. SEÑALES PARA EL BLOQUE DE INTERFAZ RS – 232 .................................................................... 78 6.2.4.3. SEÑALES PARA EL BLOQUE DAC/ADC ........................................................................................... 78 6.2.4.4. SEÑALES PARA EL BLOQUE TX/RX ................................................................................................. 79 6.2.4.5. SEÑALES DE ALIMENTACIÓN........................................................................................................... 79

6.2.5. MEMORIA .................................................................................................................................... 79 6.2.5.1. CIRCUITOS INTEGRADOS 6206 Y 27C256......................................................................................... 81

6.2.6. DAC / ADC.................................................................................................................................... 82 6.2.6.1. CIRCUITO INTEGRADO CS 4215 ........................................................................................................ 84

6.2.7. TX / RX.......................................................................................................................................... 86 6.2.7.1. RECEPCIÓN............................................................................................................................................ 89 6.2.7.2. TRANSMISIÓN....................................................................................................................................... 90

6.2.8. TRANSCEPTOR............................................................................................................................ 90 6.2.8.1. TIPOS DE TRANSCEPTORES COMERCIALES .................................................................................. 90 6.2.8.2. CARACTERÍSTICAS GENERALES...................................................................................................... 91 6.2.8.3. CONCLUSIONES.................................................................................................................................... 93

6.3. SOFTWARE A EJECUTAR POR EL DSP ........................................................................................... 94 6.3.1. FUNCIONES SOBRE LA SEÑAL A TRANSFERIR ...................................................................... 95

6.3.1.1. EN TRANSMISIÓN................................................................................................................................. 95 6.3.1.1.1. RECEPCIÓN DE DATOS DEL PC .............................................................................................. 95


Página 4 de 156

6.3.1.1.2. MODULACIÓN DE LA SEÑAL .................................................................................................. 95 6.3.1.1.3. ENTREGA AL CS 4215................................................................................................................ 99

6.3.1.2. EN RECEPCIÓN...................................................................................................................................... 99 6.3.1.2.1. RECEPCIÓN DE DATOS DESDE EL CODEC ........................................................................... 99 6.3.1.2.2. DEMODULACIÓN DE LA SEÑAL........................................................................................... 100 6.3.1.2.3. ENTREGA AL PC DE LOS BYTES RECIBIDOS..................................................................... 103

6.3.2. FUNCIONES SOBRE EL HARDWARE DEL SISTEMA............................................................. 103 6.3.2.1. GESTIÓN DEL PROPIO DSP............................................................................................................... 103

6.3.2.1.1. CARGA DE SOFTWARE........................................................................................................... 103 6.3.2.1.2. PUERTO SCI............................................................................................................................... 105 6.3.2.1.3. PUERTO SSI ............................................................................................................................... 105 6.3.2.1.4. PUERTO H .................................................................................................................................. 105 6.3.2.1.5. CIRCUITO DE RELOJ................................................................................................................ 106 6.3.2.1.6. INTERRUPCIONES.................................................................................................................... 106

6.3.3. ORGANIGRAMA COMPLETO DEL SOFTWARE ..................................................................... 107

7. MANUAL DE USUARIO ....................................................................................................................... 109

7.1. IDENTIFICACIÓN DE LA INTERFAZ ............................................................................................. 109 7.2. INSTALACIÓN DEL HARDWARE................................................................................................... 111 7.3. INSTALACIÓN DEL SOFTWARE Y CONFIGURACIÓN............................................................... 112

7.3.1. INCLUSIÓN DEL DISPOSITIVO EN EL NÚCLEO DE LINUX................................................112 7.3.2. CONFIGURACIÓN DE LAS PROPIEDADES DE RED ............................................................ 114 7.3.3. CONFIGURACIÓN DE LAS APLICACIONES .......................................................................... 114

7.4. APLICACIONES SOPORTADAS ...................................................................................................... 115 7.5. ALCANCE DE LA RED LOCAL........................................................................................................ 115

8. PRESUPUESTO...................................................................................................................................... 116

8.1. COSTES DE PERSONAL.................................................................................................................... 116 8.1.1. COSTES UNITARIOS ................................................................................................................. 116 8.1.2. COSTES POR PERSONA............................................................................................................ 117

8.2. COSTES DE MATERIAL.................................................................................................................... 118 8.3. TOTAL PRESUPUESTO..................................................................................................................... 119

9. CONCLUSIONES ................................................................................................................................... 121

10. BIBLOGRAFÍA....................................................................................................................................... 122

11. DIRECTORIO INTERNET ................................................................................................................... 123

ANEXO A. LISTADO COMPLETO DEL SOFTWARE ............. ................................................................ 124

ANEXO B. INTERFAZ FSK ........................................................................................................................... 145

B.1. CARACTERÍSTICAS GENERALES.................................................................................................... 145 B.2. DIAGRAMA DE BLOQUES................................................................................................................. 145

B.2.1. FUENTE DE ALIMENTACIÓN...................................................................................................... 146 B.2.2. RS – 232 ..........................................................................................................................................147 B.2.3. MODULADOR / DEMODULADOR............................................................................................... 147 B.2.4. TX / RX............................................................................................................................................ 149

B.3. ESQUEMA ELÉCTRICO COMPLETO................................................................................................ 151 B.4. MODIFICACIONES A EFECTUAR SOBRE EL SOFTWARE........................................................... 152

ANEXO C. HOJAS DE CARACTERÍSTICAS ............................................................................................. 156


Página 5 de 156

ÍNDICE DE FIGURAS

Página

Figura 1. Diagrama de bloques del sistema completo a realizar en este proyecto ............................................. 10 Figura 2. Topología en estrella ........................................................................................................................... 14 Figura 3. Topología en anillo .............................................................................................................................. 15 Figura 4. Topología en árbol............................................................................................................................... 16 Figura 5. Topología en estrella ........................................................................................................................... 17 Figura 6. Esquema de LAN inalámbrica con configuración AD-HOC ................................................................ 18 Figura 7. Esquema de LAN inalámbrica con configuración INFRAESTRUCTURE............................................ 18 Figura 8. Topología de la red inalámbrica presentada....................................................................................... 19 Figura 9. Algoritmo de tiempo de espera aleatorio............................................................................................. 21 Figura 10. Cabecera del protocolo RPP ............................................................................................................. 26 Figura 11. Trama de confirmación del protocolo RPP....................................................................................... 32 Figura 12. Tasas de velocidades en nuestra red.................................................................................................. 36 Figura 13. Esquema simplificado del proceso de recepción de una trama ......................................................... 43 Figura 14. Estructura de un dispositivo de red para LINUX............................................................................... 45 Figura 15. Nomenclatura de los dispositivos de comunicaciones en LINUX ...................................................... 47 Figura 16. Código de inicialización del dispositivo ............................................................................................ 50 Figura 17. Código de inicialización de la interrupción temporal del dispositivo ............................................... 51 Figura 18. Código de inicialización de la UART................................................................................................. 52 Figura 19. Código de las funciones de activación y desactivación ..................................................................... 52 Figura 20. Código de la transmisión de un paquete............................................................................................ 53 Figura 21. Estructura de listas enlazadas ........................................................................................................... 54 Figura 22. Función de entrega de paquetes en recepción ................................................................................... 55 Figura 23. Función de escritura del búffer circular ............................................................................................ 55 Figura 24. Función de lectura del búffer circular ............................................................................................... 56 Figura 25. Código de la interrupción temporal................................................................................................... 57 Figura 26. Control de recepción.......................................................................................................................... 58 Figura 27. Control de transmisión.......................................................................................................................59 Figura 28. Modificaciones sobre el archivo Makefile ......................................................................................... 61 Figura 29. Modificaciones sobre el archivo Config.in ........................................................................................ 61 Figura 30. Modificaciones sobre el archivo Space.c........................................................................................... 62 Figura 31. Diagrama de bloques de la interfaz basada en DSP.......................................................................... 69 Figura 32. Fuente de alimentación del sistema ................................................................................................... 71 Figura 33. Condensadores de filtro. Deben situarse cercanos a los circuitos correspondientes ........................ 72 Figura 34. Circuito integrado MC 7805.............................................................................................................. 72 Figura 35. Circuito de la interfaz RS – 232......................................................................................................... 73 Figura 36. Circuito integrado MAX 232.............................................................................................................. 74 Figura 37. Circuito eléctrico del bloque del DSP................................................................................................ 75 Figura 38. Circuito eléctrico del reloj del DSP................................................................................................... 76 Figura 39. Circuito eléctrico del RESET del DSP............................................................................................... 76 Figura 40. Circuito de la inicialización de modo de trabajo del DSP................................................................. 77 Figura 41. Esquema del conexionado de la memoria.......................................................................................... 80 Figura 42. Mapa de memoria ..............................................................................................................................81 Figura 43. Esquema eléctrico del bloque ADC / DAC ........................................................................................ 82 Figura 44. Sincronización de las comunicaciones DSP – CODEC..................................................................... 84 Figura 45. Estructura interna del circuito integrado CS 4215............................................................................ 86 Figura 46. Conmutación TX / RX. Modo 1 .......................................................................................................... 87 Figura 47. Conmutación TX / RX. Modo 2 .......................................................................................................... 87 Figura 48. Conmutación TX / RX. Modo 3 .......................................................................................................... 88 Figura 49. Esquema completo del bloque TX / RX .............................................................................................. 89 Figura 50. Rangos de frecuencias de trabajo de los transceptores ..................................................................... 91 Figura 51. Tipos de modulación de los transceptores ......................................................................................... 92


Página 6 de 156

Figura 52. Potencia de transmisión máxima para los transceptores................................................................... 92 Figura 53. Interrupción SCI_RX..........................................................................................................................95 Figura 54. Modulación QAM...............................................................................................................................96 Figura 55. Funciones I y Q.................................................................................................................................. 97 Figura 56. Modulación ........................................................................................................................................ 98 Figura 57. Interrupción SSI_TX ..........................................................................................................................99 Figura 58. Interrupción SSI_RX ........................................................................................................................ 100 Figura 59. Demodulador QAM.......................................................................................................................... 100 Figura 60. Demodulación .................................................................................................................................. 102 Figura 61. Interrupción SCI_TX........................................................................................................................ 103 Figura 62. Modos de inicialización del DSP 56002 .......................................................................................... 104 Figura 63. Interrupción temporal ...................................................................................................................... 106 Figura 64. Software cargado en el DSP ............................................................................................................ 108 Figura 65. Vista frontal de la interfaz................................................................................................................ 109 Figura 66. Vista trasera de la interfaz............................................................................................................... 110 Figura 67. Instalación hardware de la interfaz ................................................................................................. 111 Figura 68. Hipótesis para el cálculo de los costes unitarios ............................................................................. 116 Figura 69. Coste diario del personal ................................................................................................................. 117 Figura 70. Cantidad de días trabajados por cada persona ............................................................................... 117 Figura 71. Coste total de personal .................................................................................................................... 118 Figura 72. Coste de material técnico................................................................................................................. 118 Figura 73. Coste de material de redacción........................................................................................................ 119 Figura 74. Coste de ejecución material del proyecto ........................................................................................ 119 Figura 75. Coste de ejecución total del proyecto .............................................................................................. 120 Figura 76. Diagrama de bloques de la interfaz basada en el CI TCM 3105 ..................................................... 145 Figura 77. Circuito de la fuente de alimentación del diseño ............................................................................. 146 Figura 78. Circuito de la interfaz RS – 232 del diseño...................................................................................... 147 Figura 79. Circuito del modulador / demodulador............................................................................................ 148 Figura 80. Circuito del driver del transceptor................................................................................................... 150 Figura 81. Esquema eléctrico completo de la interfaz basada en el TCM 3105 ............................................... 152


Página 7 de 156

1. RESUMEN

Se presenta en este proyecto el diseño de un sistema de comunicaciones IP inalámbrico, mediante la implementación de una tarjeta basada en el DSP 56002 de Motorola.

Para su presentación, este proyecto ha sido dividido en dos partes. En la primera parte “Diseño de una interfaz basada en DSP para el acceso vía radio a una red local (I)”, realizada por Francisco Valencia Arribas, se estudiaron los conceptos de comunicaciones mediante protocolos IP, las características de los distintos medios físicos por los que se podrán transmitir las señales, las propiedades de distintos tipos de modulaciones digitales, y se hizo un estudio del DSP 56002 de Motorola. Así mismo, se estudió el diagrama de bloques de la interfaz que ahora se desarrollara

En esta segunda parte, se analizará la implementación práctica de esta aplicación. Será presentado el diseño de la interfaz, y se preparará un dispositivo de comunicaciones bajo el sistema operativo LINUX.

Este dispositivo será probado mediante la construcción de una pequeña aplicación, consistente en un módem FSK que, a una velocidad de transferencia de 1.200 bits por segundo, y utilizando transceptores de radioaficionado en la banda de 27 MHz, permitirá establecer comunicaciones digitales entre varias estaciones, e incluso se permitirá el acceso a redes externas, configurando una de estas estaciones como si se tratase de un router.


Página 8 de 156

2. INTRODUCCIÓN

Las Redes de Área Local (LAN) presentan numerosas ventajas a las comunicaciones dentro de un mismo grupo de trabajo, eso es bien sabido por todos. Pero también es cierto que presentan dos problemas que, en ocasiones, pueden ser complicados de resolver.

El primero de ellos es la incomodidad de tener que atravesar toda la infraestructura de un edificio con el cableado de la red, y el segundo, y no menos importante, es que es prácticamente inviable el conectar dos edificios separados en la misma red local, dadas las complicaciones que supone el obtener una licencia para efectuar la obra civil de unirlos por cable.

El proyecto que se presenta es, básicamente, la implementación de una red de área local, que es capaz de conectar a un número reducido de usuarios mediante el uso de señales radioeléctricas, usando para ello transceptores de radioaficionados como nivel físico en la escala OSI.

Para la realización de la idea presentada, se ha diseñado un sistema capaz de mantener la comunicación descrita, a una velocidad de hasta 9600 bits por segundo entre un máximo de 254 usuarios. El proyecto, mantiene la comunicación en los niveles físico y de enlace en la escala OSI, dejando al protocolo IP y a las aplicaciones el resto de la tarea.

El sistema trabajará bajo el sistema operativo LINUX, ya que dadas sus excepcionales cualidades para las comunicaciones y su liberalidad de adquisición, lo hacen idóneo para esta aplicación.

En esta segunda parte se diseñará el circuito completo de la interfaz de comunicaciones, y se desarrollará un dispositivo de comunicaciones bajo el sistema operativo LINUX. Con el fin de probar el funcionamiento, se diseñará y construirá una pequeña interfaz FSK con la que se podra comprobar el acceso a distintas redes.


Página 9 de 156

3. OBJETIVOS

Mediante la realización de este proyecto, se pretende completar algunas de las materias que no han sido del todo vistas durante la realización de los estudios de Ingeniería y que, sin embargo, serán de mucha utilidad en el futuro profesional. Básicamente estas pueden ser englobadas en tres bloques:

• Conocimientos de redes de datos

- Conocimientos del funcionamiento de los protocolos IP, ya que han alcanzado, gracias a Internet, una gran importancia en todas las telecomunicaciones, de hecho, todas las comunicaciones según las entendemos hoy en día tienden a una integración que las hará ser todas transportadas en paquetes IP. Así, el futuro próximo va a estar basado en Voz sobre IP, videoconferencia a través de Internet, domótica, etc.

- Adquirir conocimientos en cuanto al direccionamiento y ruteado de estos protocolos se refiere, viendo como los dispositivos encaminadores (routers) dirigen los datos a una u otra dirección a fin de alcanzar la mayor velocidad (camino más corto) y la mayor calidad (camino con menos tráfico) posible.

- Adquirir conocimientos generales acerca de las redes de datos según las ve el usuario final, es decir, analizar el funcionamiento de las redes de área local (LAN).

- Ampliar conocimientos en un sistema operativo cada vez más implantado en el mundo de las telecomunicaciones: el LINUX, ya que su parecido a UNIX añadido a su gran modularidad lo hacen idóneo para este tipo de aplicaciones.

• Conocimientos de sistemas digitales

- Aunque si que ha sido tratado durante los estudios, se pretende aumentarlos en lo que a técnicas de tratamiento digital de señales se refiere.

- El funcionamiento de los procesadores digitales de señales (DSP’s), para lo que se estudiara concretamente la familia de DSP’s 56000 de Motorola.

• Técnicas de modulación

- Se realizara un estudio de distintas modulaciones digitales, tanto unidimensionales (ASK, FSK, PSK) como multidimensionales (QAM, CAP y DMT).

En este proyecto se va a unificar todas estas áreas para estudiar, diseñar, desarrollar y poner en marcha un sistema que, a demás de instructivo, pueda resultar práctico en determinadas ocasiones.


Página 10 de 156

3.1. DESCRIPCIÓN DEL PROYECTO

En este apartado se va a hacer una descripción general de la interfaz a realizar, para que queden más claros cuáles son los objetivos perseguidos y el camino que se ha optado seguir para conseguirlos

Como se ha comentado, el proyecto consistirá en una interfaz capaz de establecer una comunicación digital entre varias estaciones (hosts o redes de área local) por medio de señales de radiofrecuencia. El diagrama de bloques de todo el sistema, que será estudiado en la segunda parte del proyecto, será representado a continuación:

Figura 1. Diagrama de bloques del sistema completo a realizar en este proyecto

A continuación se va tratar de comentar las funciones que han sido asignadas a cada uno de los bloques. Cabe destacar del diagrama anterior que algunos de ellos son puramente desarrollados por hardware, mientras que otros son tan sólo software programado.

• PC

- Aplicaciones de usuario: En este grupo se incluyen los programas de usuario ajenos a este proyecto, que se encuentran por encima del nivel 2 en la escala OSI. Se esta hablando de aplicaciones tales como TELNET, FTP, PING, exploradores de INTERNET, etc. Ya que el sistema debe ser transparente al usuario, podrá usarse cualquier software que esté preparado para trabajar con protocolos IP. Esto incluye la inmensa mayoría de programas de comunicaciones que se encuentran hoy en el mercado. Cabe destacar que, ya que nos encontramos en el sistema operativo LINUX, la mayoría de estos programas son de libre adquisición, pudiendo aprovechar con menos inconvenientes la potencia que se desarrolla en las nuevas aplicaciones.


Página 11 de 156

- Driver de Módem: Este driver se instalará directamente en el núcleo del sistema operativo LINUX, y su función será introducir los paquetes IP dentro del protocolo propietario desarrollado en este proyecto (RPP). Así mismo, “desempaquetará” la información IP contenida en los paquetes RPP que reciba para entregárselos al sistema operativo. Será misión suya la generación íntegra del protocolo, corrección de errores, enrutamiento de paquetes en función de las direcciones origen y destino, etc.

- Interfaz RS - 232: Se usara la UART 8250 (o compatible, ya que ésta es la versión básica) incluida en los PC para establecer las comunicaciones con nuestra tarjeta. Ésta debe ser configurada correctamente en cuanto a velocidad, bits de inicio y parada, paridad, interrupciones, etc. Esta configuración será efectuada por el mismo software que implementa el driver de módem.

• INTERFAZ

- Interfaz RS - 232: Los datos deberán atravesar un circuito adicional que cambiará los niveles de tensión RS 232 a TTL.

- Módem: Este bloque está basado en un circuito procesador de señales (DSP), que tendrá la función de, a partir de una señal digital de entrada, obtener una señal analógica en su salida y viceversa.

- Driver TX / RX: Es simplemente un pequeño circuito que selecciona el modo de transmisión o recepción del transceptor en función del momento en el que sea preciso transmitir.

• TX / RX: Este es un equipo transceptor de los habitualmente utilizados por los radioaficionados. La frecuencia de comunicación no es crítica, siempre y cuando sea la misma para todas las estaciones (como es lógico). El modo de modulación tampoco lo es, pero por características de relación señal/ruido, se recomienda el modo FM. De las cualidades de potencia de transmisión, y sensibilidad de recepción, dependerá gran parte de la calidad de las comunicaciones. Cabe destacar que en principio, estos equipos disponen de un ancho de banda de 3 KHz aproximadamente, pero el sistema basado en DSP, debido a que se pretende transmitir un mayor número de bits por segundo, precisa de un ancho de banda superior (aproximadamente 4.8 KHz), con lo que será necesario atacar al modulador de la emisora directamente, sin pasar por los filtros. En recepción sucede lo mismo, siendo necesario extraer la señal de la etapa detectora. Muchos de estos equipos disponen ya de una entrada preparada para este fin, en el que se dispone de un ancho de banda típico de unos 8 KHz.


Página 12 de 156

• Antena: De las características de este elemento va a depender la distancia máxima a la que se podran separar dos estaciones. Es necesario para el proyecto que todas las estaciones de la red tengan una perfecta conectividad entre ellas vía radio, por lo que habrá que dimensionar este elemento (junto con la potencia de transmisión y la ganancia en recepción de los equipos), para que se obtenga esta conectividad. Sería posible implementar “repetidores” en las mismas estaciones, de forma que los paquetes de información fueran desplazándose de una estación a otra hasta llegar a su destino, como si se trataran de routers, pero esta aplicación no será implementada en este proyecto.


Página 13 de 156

4. RED LOCAL INALÁMBRICA

Como se ha dicho antes, el objetivo de este proyecto es diseñar y construir una red de área local inalámbrica, que permita establecer comunicaciones digitales entre varios ordenadores provistos de este sistema.

El objeto de este punto es definir las características con las que contará la red local inalámbrica resultante, con la finalidad de más tarde desarrollar el sistema de comunicaciones bajo el sistema operativo LINUX y la interfaz basada en el DSP 56002 de Motorola.

Concretamente, las características que se encuentran al alcance de diseñar son:

- Topología de la red.

- Problema de colisiones.

- Algoritmo de los tiempos de espera aleatorios.

- Direccionamiento IP.

- Protocolo RPP.

- Velocidades de transferencia puntual y tasa de tran sferencia media.

- Limitaciones al número máximo de usuarios.

Como es evidente, y como se vera en los puntos siguientes, las limitaciones debidas a las características de los transceptores que se usaran, marcarán de una manera importante los parámetros globales del sistema.

4.1. TOPOLOGÍA DE LA RED

A la hora de decidir la topología con la que contará la red, se ha tenido que analizar las posibilidades de que disponían las estudiadas en la primera parte de este proyecto. A partir de las dos topologías estandarizadas para redes IP inalámbricas (Ad-Hoc e Infraestructure) se ha creado una que cumpliera con nuestras exigencias.

A continuación se va a recordar las características principales de estas topologías, razonando los motivos por los que han sido descartadas. Cabe destacar que las condiciones con las que debe contar esta topología para que fuera útil en nuestro proyecto son las siguientes:

- Es preciso contar con una máquina que sirviera de g ateway entre nuestra red y el exterior. Este equipo debe disponer de un interfaz que le enlace con nuestra red y otra que le permita transferir datos a cualquier otra red. La


Página 14 de 156

configuración básica sería la de disponer de una tarjeta de red Ethernet y una red con salida a Internet.

- El tráfico generado dentro e nuestra red debe ser e l mínimo posible , ya que la limitada velocidad haría que el retardo de la red fuera excesivo.

- Es preciso contar con algún sistema que permita evi tar o cuanto menos reducir el problema de las colisiones , consistente en que dos o más estaciones traten de transmitir en el mismo instante de tiempo.

4.1.1. TOPOLOGÍA EN ESTRELLA

En este tipo de topología (ver figura), existe un ordenador central que sería el encargado de decidir el orden de transmisión de las estaciones. Esta solución conseguiría evitar completamente el riesgo de choques entre ellas, pero por el contrario, esto supondría una serie de desventajas que influirían negativamente en el rendimiento general de la red:

Figura 2. Topología en estrella

El protocolo que se implementaría en este tipo de topología consistiría en que el servidor (ordenador central) debería disponer de una lista que relacionase todas las estaciones que se encuentran en la red, y debería, además de servir de puerta de enlace a redes externas, ir indicando qué estación debe transmitir en cada momento.

Una de las ventajas más importantes que supondría este tipo de topología es que sería posible mantener la red inalámbrica incluso si las estaciones no pudieran recibirse entre ellas, bastaría con que todas pudieran mantener comunicación con la estación base u ordenador central, y él se podría encargar, por ejemplo, de servir de repetidor para todas las estaciones.

Por el contrario, la desventaja más importante es que se generaría mucho tráfico en la red, ya que cada paquete debe transmitirse dos veces, todas las


Página 15 de 156

estaciones, al entrar en la red, deberían transmitir la información que necesita la estación base para agregarlos en su listado, y además la estación base debe transmitir siempre para indicar a qué estación le corresponde el turno.

Como se ha visto en el apartado anterior, las condiciones de velocidad de la red son deficientes, por lo que se decidió no apostar por esta tecnología.

4.1.2. TOPOLOGÍA EN ANILLO

Este tipo de topología, a diferencia de la anterior, no precisa de ninguna estación base que coordine el tráfico de la red. Simplemente, una de las estaciones conectadas en el anillo, serviría de gateway para salida a otras redes. La forma de transmisión sería circular, es decir, transmite una de ellas (el primero sería el gateway), y a partir de ahí van transmitiendo siguiendo el orden establecido en el anillo.

Figura 3. Topología en anillo

La ventaja es que se garantiza la ausencia de colisiones en las transmisiones, y que también sería capaz (en decremento de la velocidad media de la red) repetir los paquetes de aquellas estaciones que no se reciban, bastaría con que cada una de ellas escuchara a la que tiene justo delante y a la que tiene justo detrás. Si una de estas dos estaciones desapareciese, sería necesario reorganizar el anillo. A pesar de esto, no fue adoptada esta topología por las siguientes desventajas que aportaba:

- Todas las estaciones precisaban disponer de una lista conteniendo las estaciones que hay en la red y su posición en el anillo, con lo que, cada vez que una nueva estación ingresara, debería transmitir su lista (solo ella), y todas las demás deberían propagar la nueva lista recibida.


Página 16 de 156

- Si una estación se desconecta súbitamente, el anillo se rompe, con lo que la siguiente debe disponer de la inteligencia suficiente como para decidir que esta estación desapareció, volviendo a transmitir, de nuevo, toda la lista.

- El gateway, que será, seguramente, la máquina que más tráfico genere, tendría exactamente las mismas posibilidades de transmisión que las demás, con lo que su búffer de entrada de la red externa, debería ser lo suficientemente grande como para poder soportar todo el tráfico. El resultado sería que se formaría un cuello de botella, y tendrían que despreciarse paquetes, lujo que nuestra red no puede permitirse.

4.1.3. TOPOLOGÍA EN ÁRBOL

Este tipo de topología, basada en una arquitectura padre – hijo consistiría en que, partiendo de un padre total (ordenador de gateway), éste iría entregando el permiso de transmisión a cada uno de sus hijos, y éstos, a su vez, a los suyos, de forma que si el padre total tiene dos hijos (ordenadores) colgando de él, le daría permiso al primero de ellos, y no le daría permiso al segundo hasta que el primero notificase que toda su rama ha terminado de transmitir. La complejidad de implementación de este algoritmo (todas las estaciones deben tener la lista completa para saber quien es su padre y quienes son sus hijos), la redundancia de transmisiones (un padre transmite tantas veces como hijos tenga) y el retardo que supone recorrer todo el árbol, han sido decisivos a la hora de descartar esta tecnología. En la figura siguiente se representa gráficamente este tipo de red:

Figura 4. Topología en árbol

4.1.4. TOPOLOGÍA COMPLETA

Esta es una topología similar a la adoptada en nuestro proyecto, ya que se ha considerado que es la que más se adapta a nuestras necesidades. Por supuesto tiene una serie de inconvenientes, como que no pueden ser retransmitidos los paquetes de estaciones que pierdan conexión, y esto obliga a diseñar la estructura física de la red y de los equipos de transmisión de tal forma que se garantice, con adversas condiciones de ruido, la conexión entre todas las estaciones. La ventaja


Página 17 de 156

principal es que no es necesaria la distribución de listas de las estaciones que se encuentran en la red, y la desaparición o entrada de nuevas estaciones no supone ningún tráfico especial.

Figura 5. Topología en estrella

Un problema que presenta esta tecnología es que sí cabe la posibilidad de producción de choques, es decir, puesto que no se rige de ninguna manera a quién le corresponde transmitir, podría darse el caso de que dos, o más, o todas las estaciones intentaran transmitir de manera simultánea. Para evitar, o al menos minimizar, este problema, se ha implantado un algoritmo basado en tiempos de espera aleatorios y en “escucha antes de hablar” que han sido explicados en la primera parte de este libro. Más adelante se vera como han sido aplicados estos conceptos en nuestra red y en el protocolo RPP.

4.1.5. TOPOLOGÍA DE RED INALÁMBRICA AD-HOC

Como se ve en la figura, este tipo de topología es similar a la topología completa, pero el medio físico es el aire. El problema de esta topología para nuestra red, es que no existe un punto de conexión a una red de medio físico fijo, es decir, implementar esta topología literalmente, tal como la define el estándar, no nos permitiría salir al exterior de nuestra red. La topología adoptada es idéntica a ésta, con la salvedad de que uno de los equipos debe disponer de una conexión a una red local inalámbrica, para permitir accesos a redes externas o a Internet.


Página 18 de 156

Figura 6. Esquema de LAN inalámbrica con configuración AD-HOC

4.1.6. TOPOLOGÍA DE RED INALÁMBRICA INFRAESTRUCTURE

En esta topología sí que existen puntos de acceso a redes fijas. El problema que presenta esta topología es que cada estación inalámbrica precisa de una estación fija distinta.

Figura 7. Esquema de LAN inalámbrica con configuración INFRAESTRUCTURE


Página 19 de 156

4.1.7. TOPOLOGÍA DE RED ADOPTADA

Tras el estudio de todas las posibles topologías existentes, se ha creado una que, como ya se ha dicho, se comportará como una topología completa o Ad-Hoc si se mira desde el lado inalámbrico, y como una tecnología Infraestructure si se mira desde el lado de red local fija (cableada). Es decir, será una conexión punto a punto entre todos los elementos de la red, y además, uno de ellos pertenecerá a otra red (normalmente a una LAN, pero podría tratarse de un acceso remoto telefónico, RDSI, WAN. MAN, etc). Esta máquina servirá como puerta de enlace entre nuestra red y el exterior, haciendo las funciones de router.

En la figura siguiente se representa de forma gráfica esta topología. Hay que tener en cuenta que la línea punteada indica la intersección del radio de acción (o cobertura) de cada una de las estaciones, es decir, la zona donde se garantiza que todos los equipos son capaces de recibir al resto:

Figura 8. Topología de la red inalámbrica presentada

El ordenador que dispone de conexión con nuestra red y con la red Ethernet, servirá como puerta de enlace (o gateway), asumiendo también las funciones de router, con la finalidad de encaminar cada paquete que venga de la red exterior al ordenador correspondiente de la red inalámbrica.


Página 20 de 156

4.2. PROBLEMA DE COLISIONES

El problema principal asociado con la topología elegida es el tomar, de forma dinámica, la decisión de qué estación debe transmitir en cada instante de tiempo. Puesto que los transceptores que se utilizan trabajan en modo half-duplex (es decir, no pueden transmitir y recibir de manera simultánea), cabría la posibilidad de que dos o más estaciones pretendieran transmitir en el mismo instante de tiempo, provocando que ninguna otra que está escuchando recibiera los paquetes con la suficiente claridad como para ser interpretados, y la consecuente necesidad de volver a retransmitir el mensaje.

Para evitar parte de este problema, podría implementarse un algoritmo de “escucha antes de hablar”, consistente en que todas las estaciones que desearan transmitir escucharan la línea si se está transmitiendo actualmente algún mensaje. Al finalizar ese mensaje, podrían transmitir el suyo. Pero esto supone que, al terminar un mensaje correcto, todas las estaciones que desearan transmitir lo harían al mismo, tiempo, con lo que no se solucionaba el problema completamente. Para poder minimizar considerablemente este error, se ha implementado lo que se ha decidido en llamar algoritmo de tiempos de espera aleatorios, que se pasa a explicar en el siguiente apartado.

4.3. ALGORITMO DE TIEMPOS DE ESPERA ALEATORIOS

Este algoritmo ha sido basado en el CSMA/CD, que es el usado por las redes de tipo Ethernet en entornos de área local, como queda documentado en la primera parte del proyecto. Gráficamente, se representa este algoritmo en el diagrama de la siguiente figura, que luego se pasara a comentar:


Página 21 de 156

Escuchar

¿Hay alguna transmisión?

Esperar a que finalice

Calcular tiempo

aleatorio

¿El tiempo ha

terminado?

¿Hay datos para

transmitir?

Transmitir datos

Calcular tiempo

aleatorio

SI

NO

NO

SI

NO

SI

Figura 9. Algoritmo de tiempo de espera aleatorio

Como se ve en la figura, una estación que acaba de ingresar en la red, lo primero que hace es calcular un tiempo aleatorio, quiera o no transmitir, y esté o no transmitiendo alguna otra estación. El motivo de éste cálculo inicial es que, en el caso de que no haya otras estaciones que deseen transmitir información en ese momento, o no haya ninguna otra estación en la red, pueda transmitirse finalizado el tiempo.

Una vez calculado el tiempo, se mantendrá a la escucha, por si otra estación transmite, tanto si los paquetes que se transmiten son para la estación propia (caso en que se gestionarán y serán entregados al sistema operativo como si no lo son (en este caso sólo serán leídos, pero no entregados al sistema). En el que caso de que otra estación transmita un paquete, y una vez finalizado éste, se volverá a calcular un nuevo tiempo aleatorio.


Página 22 de 156

Al no oírse ninguna otra estación y finalizado el tiempo aleatorio calculado, ya podrán transmitirse los datos que se encuentren en el búffer de datos de transmisión. En el caso de que no se dispongan datos en ese instante, el permiso para transmitir quedaría habilitado hasta que otra transmisión ajena nos hiciera recalcular el tiempo aleatorio.

El tiempo aleatorio requiere disponer de una serie de características, ya que ha de estar cuantificado y limitado entre unos márgenes. En el siguiente apartado se vera porqué y su cálculo.

4.3.1. CÁLCULO DEL TIEMPO DE ESPERA ALEATORIO

El cálculo de este tiempo ha sido realizado en función de dos parámetros principalmente:

- Tiempo de conmutación de los transceptores.

- Número máximo de usuarios en la red e índice de ocu pación.

4.3.1.1. TIEMPO DE RETARDO EN CONMUTACIÓN DE LOS TRANSCEPTORES

El tiempo de retardo en conmutación es el tiempo que precisan los transceptores para conmutar del modo de recepción al modo de transmisión y viceversa. En función del tipo de transceptor que se emplee, este tiempo puede variar entre unos márgenes, pero ha sido establecido para esta aplicación un tiempo de 100 milisegundos, suficiente para que cualquier a transceptor de calidad media - baja le dé tiempo a efectuar dicha conmutación.

Puesto que el tiempo de conmutación máximo de los transceptores que pueden ser utilizados es de 100 milisegundos, no se puede establecer cuentas menores de esta cantidad para el tiempo aleatorio de las estaciones, ya que podría darse el caso de que una estación, (que no escucha ninguna otra transmisión, tiene información para transmitir y su tiempo de espera ha finalizado) comience a transmitir en un momento determinado y, por ejemplo, 50 milisegundos después comienza otra. Esta situación sería inevitable con cuentas de espera menores de 100 milisegundos, ya que la segunda estación no puede escuchar a la primera justo en el momento de transmitir. El resultado sería, lógicamente, una colisión, que supone una pérdida de ambos paquetes.

Como ya se ha dicho, los saltos entre las distintas cuentas posibles de tiempos aleatorios han de ser de 100 milisegundos, ya que es el tiempo que tarda el dispositivo de transmisión en conmutar.

4.3.1.2. NÚMERO MÁXIMO DE USUARIOS E ÍNDICE DE OCUPACIÓN

Se define el índice de ocupación de la red al porcentaje de usuarios que en un mismo momento tratan de acceder ala red, es decir, el número de ellos que desea transmitir información a otras estaciones de manera simultánea.


Página 23 de 156

Para el cálculo, nos hemos basado en el supuesto de que el índice de ocupación será del 10% de las estaciones. El número máximo de estaciones en la red (como se vera más adelante) es de 254 usuarios, por tanto habrá como máximo 25 estaciones que desee transmitir de manera simultánea.

Cabe decir que el valor de los tiempos que se calculara será estático, es decir no variará de manea dinámica para un número menor de estaciones presentes en la red (ya que una estación no sabe cuántas estaciones más existen en la red) y, como además, el caso normal es que no se alcance este valor de 254 usuarios, el índice de ocupación permitido será bastante mayor.

La finalidad perseguida es encontrar un número de cuentas tal que sea difícil que dos estaciones asuman el mismo valor de tiempo, aunque lo verdaderamente importante es que no coincidan con el tiempo más bajo y que además quieran transmitir. Para asegurar que esta probabilidad sea baja, se han impuesto tantas cuentas posibles de tiempos como estaciones desean transmitir como máximo (teniendo en cuenta el número máximo de 254 y el 10% de índice de ocupación), es decir, 25 cuentas distintas.

De esta forma, cada estación, al terminar de recibir un paquete (puede ser el suyo), calculará un número comprendido entre 0 y 24, y éste número, multiplicado por el tamaño de la cuenta (100 milisegundos), será el período que tendrá que esperar la estación para poder transmitir, añadiendo, por supuesto, el retardo de la emisora.

Es decir, para que una estación transmita, deberá esperar un tiempo mínimo de:

0 x 100 ms + 100 ms = 100 milisegundos

Que es justo el tiempo que precisa la emisora para transmitir. El tiempo máximo, en cambio, será de:

24 x 100 ms + 100 ms = 2’5 segundos

Pero este último sería el caso de que todas las estaciones asumieran el tiempo aleatorio máximo, caso improbable, pero catastrófico, ya que, además de la pérdida de velocidad efectiva que supondría tener dos segundos y medio de inactividad, se produciría un choque, que haría que ningún paquete enviado fuera útil.

Existe una excepción en este cálculo, y es la del ordenador que servirá de gateway de nuestra red. Para él se realiza un cálculo distinto:


Página 24 de 156

4.3.1.3. TIEMPO DE ESPERA PARA EL GATEWAY

El ordenador que sirva de gateway, precisa un cálculo distinto para calcular sus tiempos aleatorios, ya que la operación normal de funcionamiento de la red será generar tráfico que provenga del exterior de la red local (por ejemplo, al visitar una página WEB, el usuario transmite una simple solicitud y recibe del gateway toda la página).

Por ello, se decidió dar prioridad al gateway, para que pudiera transmitir un número mayor de veces que el resto de los usuarios. En un principio, parece que con brindarle el doble de prioridad, no se verá tan afectada la velocidad dentro de la red local y, además las transmisiones exteriores se verán mejoradas.

Por ello, en lugar de encontrar un número de tiempo aleatorio entre 0 y 24, lo hará entre 0 y 12. De esta forma, su tiempo mínimo de espera de transmisión será, al igual que cualquier otra estación de:

0 x 100 ms + 100 ms = 100 milisegundos

Mientras que su tiempo de espera máximo será de:

12 x 100 ms + 100 ms = 1’3 segundos

4.4. DIRECCIONAMIENTO IP

Es necesario identificar a cada una de nuestras estaciones con una dirección IP, a fin de que los protocolos superiores sean capaces de transferir la información a cualquier otra máquina que se encuentre en una red con este mismo protocolo.

El protocolo IP, como se ha visto en la primera parte de este proyecto, utiliza 4 bytes para designar a las estaciones (o hosts) presentes en la red. En nuestro caso, se utilizaran direcciones pertenecientes a una clase “C”, y de carácter privado, con la finalidad de poder dar servicio a un máximo de 254 máquinas, y que no exista la posibilidad de entrar en conflicto con otras redes.

Para entenderse, se llamara de la siguiente manera al direccionamiento de la red:

- Dirección de red: x.y.z.0

- Máscara de red: 255.255.255.0

De esta forma, las direcciones que podrían asignarse irían desde la x.y.z.0 hasta la x.y.z.255, y su organización será tal y como sigue:

- La dirección x.y.z.0 identifica a la red como tal, y no puede ser asignada a ninguna estación, para evitar entrar en conflicto con protocolos de nivel superior.


Página 25 de 156

- La dirección x.y.z.255 es una dirección de broadcast, utilizada por algunos protocolos para enviar mensajes de, por ejemplo búsqueda de servidor DHCP, y tampoco debe usarse.

- EL gateway, normalmente asume la primera o la última dirección útil, en nuestro caso asumirá la última, siendo ésta la x.y.z.254.

- Las direcciones que van desde la x.y.z.1 hasta la x.y.z.253 podrían pertenecer a los usuarios normales, con lo que nuestra red se limitaría, según este direccionamiento a 253 usuarios.

Podría haberse definido un pool de direcciones más grande, por ejemplo una clase B, que permitiría hasta 65.536 direcciones, pero dadas las características de velocidad de nuestra red, sería inviable mantener a un número de usuarios tan elevado.

En el siguiente apartado se vera que tanto el direccionamiento como el ruteado del protocolo propietario RPP está muy ligado a las direcciones IP asignadas a los host de la red, por lo que es importante mantener este plan de direccionamiento.

4.5. PROTOCOLO RPP

El protocolo RPP (Radio Packet Protocol), de diseño propio, es una manera simple de obtener al tiempo seguridad y velocidad de la transmisión.

La primera de ellas ha sido implementada mediante la agregación de una información (CRC) que indica el resultado total de la suma de todos los bytes transmitidos en el paquete. Si el receptor, al sumar los bytes del paquete, comprueba que la suma es incorrecta, descarta inmediatamente el paquete, teniendo que volver a ser transmitido de nuevo por el emisor. Esta comprobación de seguridad se suma a la que el protocolo TCP incorpora en sus mensajes, de forma que lo que se ha conseguido es fijar un nivel de seguridad que se encuentra en la capa 2 de la escala OSI (ver primer libro de este proyecto), y otro, fijado por TCP, en la capa 3.

En cuanto a la característica buscada de velocidad, nuestra única alternativa era añadir poca información de control al paquete a transmitir, de tal forma que la cabecera de un paquete encapsulado en un protocolo RPP tan sólo añade ocho bytes al tamaño total de éste.


Página 26 de 156

Es necesario tener en cuenta que, a pesar de agregar un nuevo nivel de seguridad a la información contenida en el paquete, el medio de comunicación que se emplea dispone de una calidad cualitativamente menor que las habituales en redes de datos. La numerosa cantidad de emisiones que se efectúan en las frecuencias a las cuales se va a poder trabajar (radioaficionados) hace que la transmisión de datos sea complicada. Si se emplean transceptores de baja calidad, también influirá negativamente en la comunicación de nuestra red.

Con todo ello, se debera entonces, asegurarnos que la transmisión va a ser efectuada manteniendo unas condiciones de señal y ruido aceptables, modificando los parámetros de transmisión, tales como diseño y polarización de las antenas, potencia empleada, modo de modulación en alta frecuencia, ganancia del receptor, distancia de separación de las estaciones y, si fuera necesario, disponer de otros equipos de transmisión de una mayor calidad.

El formato de la cabecera que se va a añadir en cada transmisión, puede verse en la figura siguiente, a continuación pasaré a explicar la utilidad y funcionamiento de cada uno de los bytes que la integran:

NÚMERO DE BYTE VALOR SIGNIFICADO

0 FFh Sincroniza el puerto serie para evitar errores

1 D8h Byte que identifica el comienzo de una trama RPP

2 Byte bajo Tamaño total del paquete

3 Byte alto Tamaño total del paquete

4 Entre 1 y 254 Dirección RPP origen

5 Entre 1 y 254 Dirección RPP destino

6 Byte bajo Suma de comprobación (CRC)

7 Byte alto Suma de comprobación (CRC)

Figura 10. Cabecera del protocolo RPP

Ya se encuentra resumido en la figura anterior, pero a pesar de todo, creo conveniente hacer una explicación más extensa del significado y utilidad de cada uno de los bytes de esta cabecera:


Página 27 de 156

4.5.1. BYTE 0. SINCRONIZACIÓN

El interfaz de comunicaciones RS – 232, precisa, en estado de reposo, un nivel alto en sus entradas. Con este byte puesto completamente a “1’s”, se puede establecer el nivel lógico que estará presente en este puerto justo antes de comenzar la transmisión. De esta forma, se asegura que no existirán errores de sincronización debidos a este efecto en los primeros bits, o incluso bytes, de la transmisión. Este byte no siempre es recibido, ya que al inicio, no tiene porqué encontrarse el puerto receptor sincronizado con la transmisión, con lo que a la hora de recibir un paquete nuevo, este byte será considerado ruido.

4.5.2. BYTE 1. IDENTIFICADOR DE INICIO DE TRAMA RPP

Este byte sirve de identificador, a fin de que el software esté atento ante la recepción de un nuevo paquete. Al recibir este byte, las “esperanzas” de aquellas estaciones que se encontraban a la espera de poder transmitir un nuevo paquete, desaparecen, y ahora tendrán que esperar a que finalice para poder volver a calcular su nuevo tiempo aleatorio.

El hecho de que el valor de este byte sea D8h no es crítico, y ha sido escogido al azar, siendo la única condición el que todas las estaciones lo reconozcan como byte de inicio de trama.

Cuando una estación reciba este byte, esperará a recibir el resto del encabezado, así podrá comprobar el tamaño del paquete, el destino y su CRC. Si el destino coincide con su dirección, esperará a finalizar de recibir tantos bytes como se indica en la cabecera y calculará si la suma de todos los bytes coincide con la suma de CRC. En el caso de que no coincida, simplemente será desechado. Si la suma coincide, el paquete será desencapsulado del formato RPP y entregado al sistema operativo, que lo tratará consecuentemente.

Con respecto a este byte pueden suceder dos casos:

- Que el byte se reciba como parte de los datos de un paquete: En este caso, y puesto que el host se encuentra recibiendo la cantidad de datos que se marcaron en la cabecera correspondiente, será interpretado como datos, sin que sea analizado su valor.

- Que el byte se reciba como ruido, sin que haya sido transmitido por otra estación: En este otro caso, se tratará como si realmente se tratara de un paquete, pero al comprobar la cantidad de datos (debe estar entre unos márgenes), el CRC, y analizar la suma, se desechará sin más. Podría darse el caso en el que se recibiera este byte y se comenzara a leer un inexistente paquete lleno de errores, y que mientras se recibe éste, se transmitiera otra cabecera real. Este problema es solucionado porque, al recibir un byte D8h perteneciente a un paquete erróneo, los datos no serán desechados, sino que continuarán analizándose byte a byte en un búffer circular hasta encontrar el siguiente byte D8h.


Página 28 de 156

4.5.3. BYTES 2 Y 3. LONGITUD DE LA TRAMA

En estos dos bytes, se identifica el tamaño de que dispone este paquete, ya que es variable en función de la cantidad de información que se desee transmitir. El número total de bytes que componen la trama es almacenado en estos dos bytes como se indica en la figura, es decir, el valor bajo se escribiría en el byte 2 y el alto en el byte 3.

Por cuestiones que se veran más adelante, ha sido fijado el tamaño máximo del paquete en nuestra red a 2048 bytes, que es la longitud que se considera que mejor se adaptaba a nuestras necesidades, para hacer despreciable el tiempo de conmutación de los transceptores, pero que, en caso de error, no supusiera un retardo de la red elevado.

Puesto que el rango posible de paquetes oscilaría entre 8 (la cabecera sin contar el byte FFh y al menos un byte de datos) y 2048, y ya que el rango que pueden comprender dos bytes es desde 0 hasta 65535, nunca van producirse situaciones de overflow sobre estos dos bytes. Este límite marcará otra fuente de detección de un byte D8 erróneo.

A la hora de cargar este valor, no es incluido el byte de sincronismo o byte 0, ya que no es detectado por el ordenador como un byte, sino como lo que es, una señal de sincronismo.

4.5.4. BYTE 4. DIRECCIÓN ORIGEN

La dirección RPP de las estaciones de nuestra red se corresponde siempre con el valor del último byte de la dirección IP, siempre que la red sea la x.y.z.0 con máscara 255.255.255.0 (nuestra dirección de red).

En el caso en que no coincida la dirección de red destino con ésta, el mensaje será enviado a la dirección RPP 254, que es la correspondiente al gateway, para que él pueda transferir el mensaje a redes externas.

El valor cero se entiende como la dirección de red, y sólo es usada en términos de nomenclatura de la red, y para aplicar máscaras sobre ella. El valor 255 es la denominada dirección de broadcast, que se usa por determinadas aplicaciones de la familia de protocolos TCP/IP, tales como identificar a un posible servidor DHCP para que se asigne dirección (protocolo BOOTP). En nuestro caso, esta dirección no va a ser utilizada.

Esto nos deja disponibles las direcciones desde la “1” hasta la “254” para nuestras estaciones, de las cuales la “254” ya está reservada para el gateway (normalmente, estos dispositivos pueden adquirir la primera o la última, pero no es un valor crítico mientras que todas las estaciones conozcan su dirección de puerta de enlace).


Página 29 de 156

Todas estas direcciones, serán acumuladas en este byte para indicar a la red la procedencia del paquete.

4.5.5. BYTE 5. DIRECCIÓN DESTINO

Este byte es análogo al anterior, pero en él lo que se indica es la dirección a la cual irá destinado el paquete.

Cabe destacar que, mientras un paquete se dirija a la dirección de red x.y.z.0 (nuestra dirección de red), se enviará directamente a la estación correspondiente, pero si el paquete va destinado a cualquier otra red, esta trama será dirigida al gateway, para que los sistemas de ruteo IP de que disponga lo encaucen hasta su destino (como se indicó en la primera parte de este proyecto).

4.5.6. BYTES 6 Y 7. CHECKSUM O SUMA DE COMPROBACIÓN

En estos dos bytes se almacenará una información que será usada para comprobar la integridad de la trama enviada. El procedimiento consiste en sumar todos los bytes de la trama, a excepción del byte 0 de sincronismo y de estos dos bytes 6 y 7 de suma. Los 8 bytes más bajos de la suma serán almacenados en el byte 6 y los 8 bytes siguientes en el byte 7. Como es lógico, en este caso sí que podrá existir overflow, ya que la suma de todos los bytes puede resultar mayor que 65.535, pero la probabilidad de que existan errores en la trama, y que, a pesar de ello, coincidan estos dos bytes es muy baja o incluso nula.

Si se recibe un paquete con una suma distinta a la calculada, se despreciará, no enviando la confirmación correspondiente y, el emisor reenviará este paquete de nuevo hasta un máximo de cinco veces. Si la confirmación sigue sin ser recibida, el paquete será descartado y será entonces responsabilidad de los protocolos de nivel superior su reenvío.

4.5.7. FUNCIONAMIENTO GENERAL DEL PROTOCOLO RPP

Se va a explicar de manera simple en qué consiste el protocolo RPP, teniendo en cuenta que siempre que una estación vaya a transmitir un paquete de este tipo deberá esperar su turno, según se ha marcado en el apartado de "Algoritmo de tiempos de espera aleatorios". Esta norma se incumple para el caso de las confirmaciones, según se vera a continuación.

4.5.7.1. EN TRANSMISIÓN

Cuando una estación desea transmitir, se parte de un búffer entregado por el sistema operativo con el paquete IP y se encapsula este paquete en formato RPP. Para ello, se colocan en un búffer uno a uno todos los bytes que compondrán la trama, de la siguiente manera:


Página 30 de 156

- Posición 0: FFh (Byte de sincronismo)

- Posición 1: D8h (Byte de inicio)

- Posiciones 2 y 3: Tamaño del búffer entregado por el sistema operativo más siete (nuestra cabecera sin el byte de sincronismo). Se realizará la operación pertinente para cargar el byte bajo en la posición 2 y el byte alto en la posición 3.

- Posición 4: Dirección RPP origen (Coincide con el último byte de la dirección IP)

- Posición 5: Dirección RPP destino (Si los tres primeros bytes de la dirección IP destino son los tres primeros de nuestra red se pondrá el último byte en este valor, en caso contrario, se pondrá 254)

- Posiciones 6 y 7: Se sumarán todos los bytes del paquete entregado por el sistema operativo, más las posiciones 1, 2, 3, 4 y 5 de esta cabecera. Se hará el cálculo pertinente para dejar el byte más bajo en la posición 6 y el segundo en la posición 7. Si hubiera más bytes a escribir, serán rechazados.

- A partir de la posición 8: Se concatenará el paquete entregado por el sistema operativo.

Una vez formado el paquete, se han de esperar a que se cumplan las condiciones necesarias para poder transmitirlo según se explicó en el algoritmo de los tiempos aleatorios (no se escucha ninguna otra transmisión y nuestro tiempo de espera ha finalizado). Si es así, se transmite el paquete a través del puerto serie del ordenador, y la interfaz se encargará de entregarlo a la red.

Una vez finalizada la transmisión, se esperará el tiempo total de los siguientes conceptos:

- Conmutación del transceptor: 100 milisegundos . Este tiempo es solapado por la conmutación del transceptor remoto. Es decir, mientras que el nuestro pasa a recepción, el remoto (que ha de enviarnos la confirmación de forma inmediata) para a transmisión.

- Envío de la trama de confirmación: 5 bytes a 9600 bps = 4.16 milisegundos

- Total de tiempo a esperar: 150 milisegundos (Las interrupciones temporales definidas en el software son cada 50 milisegundos)

Una vez esperado el tiempo suficiente, se analizará el búffer de recepción, y se comprobará si existe la trama de confirmación, que es como sigue:

D8h - D9h - DAh - Dirección RPP propia

EL paquete de confirmación que se transmite incorpora además el byte de sincronismo FFh, pero, como ya se ha explicado, este byte es ignorado en recepción.


Página 31 de 156

Si ha recibido esta trama de confirmación, el paquete que fue enviado se considera correcto, y por lo tanto se eliminará de la cola de transmisión del puerto, dando paso al siguiente que nos haya entregado el sistema operativo, y volviendo a ejecutar de nuevo el proceso.

En caso contrario, el paquete no será eliminado y volverá a enviarse en la siguiente oportunidad que se tenga (según el algoritmo de tiempos aleatorios). En este estado se estara hasta que el paquete haya sido enviado un total de cinco veces, en cuyo caso el paquete será eliminado tanto si ha sido recibida su confirmación como si no.

Para el caso crítico de haber enviado incorrectamente el mismo paquete cinco veces, se pueden entender dos casos:

- Que el receptor no exista: Es posible que la estación receptora haya sido desconectada de la red, o, incluso, que jamás se conectara a la misma.

- Que el nivel de ruido se haya incrementado: Al utilizar bandas de radioaficionado, sería posible que otra transmisión en la misma frecuencia esté afectando a nuestra red, hasta el punto de desmantelarla. Si el problema persistiera, sería conveniente modificar los parámetros de transmisión (aumentar la potencia, modificar la frecuencia, etc. para tratar de solucionarlo.

4.5.7.2. EN RECEPCIÓN

La recepción en nuestra red está basada en el análisis periódico y continuado del búffer circular de recepción, que se va llenando cada vez que el puerto serie del PC interrumpe por la recepción de un nuevo byte entregado por nuestra interfaz.

Este búffer se lee en cada interrupción temporal del software (cada 50 milisegundos) y se analiza byte a byte, de forma que:

- Al leer, todos los bytes se irán eliminando hasta encontrar el byte de inicio de trama (D8h)

- Si se está esperando una confirmación, se analizará si los siguientes bytes son D9h,DAh y la dirección RPP propia. Si es así, se dará el paquete por confirmado. Y se continuará leyendo hasta el siguiente byte de inicio D8h.

- En caso contrario, se analizará si se trata de un paquete, comparándolo con la cabecera RPP. Si lo es, se comprueba si el paquete es para la propia estación y si el cheksum del mismo es correcto. Entonces se liberará el búffer, para seguir leyendo de él, se generará el paquete de confirmación (ver figura) y se enviará inmediatamente.


Página 32 de 156

Figura 11. Trama de confirmación del protocolo RPP

- Si el byte D8h que se recibió no se corresponde con ninguno de los dos casos, se ignorará y se continuará leyendo el búffer.

Es importante destacar que, en cada interrupción temporal, el búffer debe quedar completamente vacío, a no ser que en el momento del análisis, exista un paquete que no haya sido recibido completamente. En este caso, se quedará almacenado sólo desde el byte de inicio correspondiente hasta el final. La finalidad es garantizar que este búffer nunca sea sobrepasado, con la consiguiente pérdida de información.

Una vez que el paquete ha sido recuperado del búffer de recepción, y ha sido enviada la trama de confirmación del mismo a la estación origen, se eliminará del mismo la cabecera RPP y se entregará al sistema operativo, que lo tratará como sea conveniente en función de la información almacenada en los protocolos de nivel superior.

4.6. VELOCIDADES DE TRANSFERENCIA PUNTUAL Y TASA DE TRANSFERENCIA MÁXIMA

La velocidad máxima que puede alcanzar nuestro sistema es, como ya se ha dicho antes, de 9.600 bits por segundo, pero existen una serie de parámetros que van a colaborar en reducir de manera considerable la velocidad real de la red. Estos parámetros son los siguientes:

- Se debe transmitir en modo half-duplex: Los transceptores no pueden recibir y transmitir de manera simultánea, ya que trabajan en modo half-duplex. Esto supone que sólo una estación de la red puede encontrarse transmitiendo en el mismo instante de tiempo.

- Tiempo de conmutación relativamente alto: Los transceptores precisan de un tiempo más o menos elevado (100 milisegundos) para conmutar del estado de recepción al de transmisión o viceversa. Durante este período de tiempo se debe guardar inactividad en la red.

- Tiempo de espera aleatorio: El protocolo RPP, a fin de evitar choques entre las estaciones, debe conservar un tiempo de espera aleatorio. El periodo de inactividad será el más bajo calculado por cada una de ellas, pero a pesar de ello, es un retardo a considerar.

- Número de estaciones en red: El número de estaciones en la red supondrá que la probabilidad de que una de ellas transmita un paquete disminuye, ya que las otras desearán también transmitir.


Página 33 de 156

En la práctica, estos datos afectarán al rendimiento general de la red. A continuación, se hara un pequeño análisis para poder calcular, en varios casos supuestos, la velocidad efectiva de la red.

4.6.1. SUPUESTO 1: TRANSMISIÓN ÚNICA DEL GATEWAY

Este caso se corresponde con la siguiente idea: Una estación de la red ha solicitado de una red exterior (por ejemplo Internet) la descarga de una gran cantidad de información (por ejemplo una página WEB de gran tamaño, o una descarga FTP). El resto de las estaciones no existen o se encuentran inactivas.

Para el cálculo, se supondra que el tiempo aleatorio es constante y se mantiene en la mitad de las posibilidades. De esta forma, se acercara a la realidad, ya que en algunas ocasiones será superior y en otras inferior a éste. Como ya se explicó, las cuentas del tiempo aleatorio para el gateway pueden oscilar entre 0 y 12, con lo se considerara 6.

- El gateway espera el tiempo aleatorio: 6 * 100 = 600 ms

- El gateway conmuta su transceptor: 100 ms

- El paquete es enviado: 2.048 * 8 * 1.000 / 9.600 = 1706.67 ms (recordando que el tamaño máximo del paquete es de 2.048 bytes)

- Ambos transceptores conmutan: 100 ms

- El usuario manda su confirmación: 5 * 8 * 1.000 / 9.600 = 4.16 ms (El tiempo que tarda el gateway en comprobar esto es de una interrupción temporal) = 50 ms

- Incluso aunque el tiempo aleatorio haya sido nulo, el usuario conmutará su transceptor al modo de recepción al mismo tiempo que el gateway al modo de transmisión, con lo que no hay una espera adicional.

Con todo esto, el tiempo total que se ha tardado en enviar 2.048 bytes ha sido de:

600 + 100 + 1.707 + 100 + 50 = 2.557 ms = 2'557 segundos

Y la velocidad real:

V = 2.048 * 8 / 2'557 = 6.407'5 bps

4.6.2. SUPUESTO 2: N ESTACIONES SIN GATEWAY

Este caso se corresponde con la siguiente idea: Existen varias sesiones abiertas entre los usuarios de la red, pero ninguno de estos accesos es hacía el exterior.


Página 34 de 156

Para el cálculo, se supondra que el tiempo aleatorio es constante y se mantiene en la mitad de las posibilidades. De esta forma, se acercara a la realidad, ya que en algunas ocasiones será superior y en otras inferior a éste. Como ya se explicó, las cuentas del tiempo aleatorio para los usuarios pueden oscilar entre 0 y 24, con lo se considerara 12.

Se considera estación A a la que puntualmente desea mandar un paquete, y estación B a la que debe recibirlo.

- La estación A espera el tiempo aleatorio: 12 * 100 = 1.200 ms

- La estación A conmuta su transceptor: 100 ms


- Ambos transceptores (estaciones A y B) conmutan: 100 ms

- La estación B manda su confirmación: 5 * 8 * 1.000 / 9.600 = 4.16 ms (El tiempo que tarda el gateway en comprobar esto es de una interrupción temporal) = 50ms


Con todo esto, el tiempo total que se ha tardado en enviar 2.048 bytes ha sido de:

1200 + 100 + 1.707 + 100 + 50 = 3.157 ms = 3'157 segundos

Este mismo cálculo se repetirá para cada estación en la red, con lo que se multiplicará por N.

La velocidad real para cada estación será entonces de:

V = 2.048 * 8 / (N * 3'157) = 5.189'7 /N bps

Para 2 estaciones: 2.594'8 bps

Para 253 estaciones: 20'51 bps

4.6.3. SUPUESTO 3: N ESTACIONES CON GATEWAY

Este caso se corresponde con la siguiente idea: Existen varias sesiones abiertas entre los usuarios de la red, y algunas (o todas) ellas son con redes externas.


Página 35 de 156

Para el cálculo, se supondra que el tiempo aleatorio es constante y se mantiene en la mitad de las posibilidades. De esta forma, se acercara a la realidad, ya que en algunas ocasiones será superior y en otras inferior a éste. Como ya se explicó, las cuentas del tiempo aleatorio para el gateway pueden oscilar entre 0 y 12, con lo se considerara 6 y para las estaciones entre 0 y 24, con lo que considerara 12. Tambien se va a considerar que el gateway siempre transmitirá cada dos estaciones.

Se considera estación A a la que puntualmente desea mandar un paquete y estación B a la que debe recibirlo.

- La estación A espera el tiempo aleatorio: 12 * 100 = 1.200 ms

- La estación A conmuta su transceptor: 100 ms


- Ambos transceptores (estaciones A y B) conmutan: 100 ms

- La estación B manda su confirmación: 5 * 8 * 1.000 / 9.600 = 4.16 ms (El tiempo que tarda el gateway en comprobar esto es de una interrupción temporal) = 50ms


- El gateway espera el tiempo aleatorio: 6 * 100 = 600 ms

- El gateway conmuta su transceptor: 100 ms


- Ambos transceptores conmutan: 100 ms

- La estación receptora manda su confirmación: 5 * 8 * 1.000 / 9.600 = 4.16 ms (El tiempo que tarda el gateway en comprobar esto es de una interrupción temporal) = 50ms

Con todo esto, el tiempo total que ha tardado una estación en enviar 2.048 bytes ha sido de:

1200 + 100 + 1.707 + 100 + 50 + 600 + 1707 + 100 + 50 = 5'614 ms = 5'614 segundos

Este mismo cálculo se repetirá para cada estación en la red, con lo que se multiplicará por N.


Página 36 de 156

La velocidad real para cada estación será entonces de:

V = 2.048 * 8 / (N * 5'614) = 2.918'4 /N bps

Para 2 estaciones: 1.459'2 bps

Para 253 estaciones: 11'53 bps

Mientras que para el gateway, el valor es independiente del número de estaciones de la red, ya que siempre transmite cada dos de ellas, siendo su velocidad de:

V = 2.048 * 8 / 5'614 = 2.918'4 bps

Los resultados de los cálculos realizados se resumen en la tabla siguiente:

SUPUESTO VELOCIDAD DE UN USUARIO

VELOCIDAD DEL GATEWAY

Descarga de un archivo desde el gateway hasta una estación

- 6.407'5 bps

Comunicaciones bidireccionales entre la red. Sin uso de redes externas o gateway.

5.189'7 / N bps 1 usuario: 5.189'7 bps 253 usuarios: 20.51 bps

-

Comunicaciones bidireccionales entre la red. Con uso de redes externas o gateway.

2.918'4 / N bps 1 usuario: 2.918'7 bps 253 usuarios: 11'53 bps

2.918'4 bps

Figura 12. Tasas de velocidades en nuestra red

De esta tabla se desprende que la velocidad de la red es muy dependiente del número de usuarios que se encuentren conectados a ella, y de si los accesos se efectúan dentro de la propia red o es necesario acceder al exterior. Otro punto a tener en cuenta es que estos datos han sido calculados suponiendo que ningún paquete se pierde durante la transmisión, siendo preciso su reenvío, lo cual es prácticamente imposible de conseguir, necesitando para ello unas excelentes cualidades de la relación Señal / Ruido en la red.


Página 37 de 156

4.7. LIMITACIONES AL NÚMERO MÁXIMO DE USUARIOS

El número máximo de usuarios que pueden encontrarse conectados en nuestra red, se encuentra limitado por determinados parámetros que ya se ha visto, pero que van a ser repasados en este apartado:

- Direccionamiento: El plan de direccionamiento RPP consta de un solo byte para designar a las estaciones, que se corresponde además con el último byte de la dirección IP de cada una de ellas. Esto limita teóricamente a 256 posibles usuarios el poder ser direccionados correctamente. Ahora bien, como ya se ha dicho, la dirección correspondiente al número cero no puede ser utilizada, ya que es usada por el protocolo IP para designar a la red como estructura. El último valor (255) tampoco puede ser usada, ya que determinadas aplicaciones sobre IP la precisan para realizar direccionamientos de broadcast. Esto limita a 254 el número máximo de usuarios, de los cuales uno (la dirección 254) es asignado al gateway (que al mismo tiempo es, por supuesto, un usuario normal con determinados privilegios).

- Velocidad: Otro parámetro que limitará el número máximo de usuarios conectados es el rendimiento en velocidad que se desee obtener de la red. En el apartado anterior se vio como este rendimiento se degradaba a medida que se conectaban más usuarios, con lo que podría realizarse el cálculo inverso y encontrar un número de usuarios máximo tal que se garantizase una velocidad de transferencia aceptable.

- Equipación: Existiría una tercera limitación al número de usuarios, que será la provocada por las instalaciones físicas de los sistemas que son necesarios para transmitir y recibir señales. Puesto que, como ya se ha dicho, éstos elementos son transceptores habitualmente usados por los radioaficionados, si se desea interconectar dos edificios y poner en cada uno de ellos un número de usuarios, las antenas deberán estar situadas en los tejados de dichos edificios. Evidentemente, no pueden situarse 128 antenas (por ejemplo), en la azotea de un edificio convencional, limitándose esta cantidad en función del espacio disponible y además asegurando tal que no se causen interferencias a otros sistemas instalados (Como la recepción de televisión, por ejemplo).


Página 38 de 156

5. DISPOSITIVO DE COMUNICACIONES EN LINUX

5.1. INTRODUCCIÓN A LINUX

A mediados de los 60 las empresas MIT, AT&T y General Electric se juntaron para realizar un gran proyecto. Se trataba de hacer un sistema operativo de gran potencia al que denominaron MULTICS. El proyecto fue un fracaso pero uno de los programadores de MIT que había trabajado en el proyecto, Ken Thompson, decidió escribir una versión en miniatura del MULTICS. Uno de los compañeros de Ken, Brian Kernigham, en tono jocoso llamó al sistema Ken Thompson UNICS.

UNICS fue un gran éxito y Ken decidió que UNIX era un nombre más atractivo que UNICS. Había nacido UNIX.

Un famoso artículo del año 1974 que describía UNIX atrajo la atención de las universidades que solicitaron el código fuente para estudiarlo y explicarlo en las aulas. Muy pronto, UNIX logró una gran aceptación en la comunidad científica y el interés por este sistema operativo comenzó a extenderse. A partir de este momento comienza una verdadera avalancha de versiones del sistema. Lo que en un principio empezó como un proyecto de investigación se convirtió más tarde en todo un negocio.

A pesar del éxito comercial de UNIX y de su aceptación como sistema operativo, el código fuente de UNIX no podía ser explicado en aulas universitarias, de modo que el desarrollo de sistemas operativos volvía a ser una ciencia restringida a un reducido grupo de empresas y personas.

Ante esta situación, el profesor Andrew Tanembaum, de la Universidad de Vrije, en Amsterdam, decidió imitar a Ken Thompson cuando escribió el código de UNIX basándose en MULTICS, e inspirándose en UNIX llevó a cabo un nuevo sistema operativo mucho más reducido, al que llamó MINIX (de Mini-UNIX). MINIX había sido desarrollado en un IBM PC y, sin embargo, ofrecía las mismas llamadas al sistema que UNIX V7. Tanembaum hizo público el código de MINIX, y su texto aún se usa en la mayoría de las universidades del planeta para enseñar la base de diseño de sistemas operativos.

En 1990, Linus Torvalds, un estudiante de la Universidad de Helsinki, en Finlandia, comenzó a desarrollar, como hobby, un proyecto basado en el MINIX de Andrew Tanembaum. Quería llevar a cabo, sobre un ordenador con procesador Intel 80386, un sistema operativo tipo UNIX que ofreciese más capacidades que el limitado MINIX, que sólo se usaba para enseñar una cierta filosofía de diseño y poco o nada podía ofrecer al usuario de a pie. Quería aprovechar la arquitectura de 32 bits, las facilidades de multitarea que proporcionaba el 386 y eliminar las barreras de direccionamiento de memoria.


Página 39 de 156

Linus empezó escribiendo el núcleo del proyecto en ensamblador, y luego comenzó a añadir código en C, lo cual incrementó la velocidad de desarrollo, e hizo que empezara a tomarse en serio su idea de hacer un “MINIX mejor que MINIX”. La primera versión, la 0.01 no tenía driver de disquete, y ni siquiera la dio a conocer. Llevaba incorporado un pequeño sistema de archivos y un driver de disco con muchos errores, pero funcionaba. En Octubre de 1991, anunció la primera versión “oficial” de LINUX, la 0.02, que ya era capaz de ejecutar el shell bash y el compilador gcc de GNU.

A partir de ese momento, LINUX comenzó a crecer, gracias a que muchos de los componentes de LINUX, como drivers, protocolos o shells salieron de otro sistema UNIX de libre distribución llamado FreeBSD, desarrollado en la Universidad de Berkeley.

5.2. CARACTERÍSTICAS DE LINUX

El sistema operativo LINUX proporciona una serie de características que lo convierten en el sistema operativo ideal para nuestra aplicación, algunas de estas características son las enumeradas a continuación.

- LINUX permite la utilización de distintos tipos de shell programables. Un shell es la interfaz, el modo de comunicación, entre el usuario y el sistema. En realidad, un shell es un lenguaje interpretado; los comandos o instrucciones que se introducen son aceptados en interpretados uno por uno. Esto proporciona una herramienta enormemente flexible, ya que, al ser continua la distribución de nuevas utilidades para el sistema, el lenguaje interpretado crece con el mismo, y con él, su potencia.

- LINUX es un sistema multitarea , es decir, está preparado para signar espacios temporales concretos a multitud de aplicaciones que se estén ejecutando de forma simultánea.

- LINUX es también multiusuario , lo que permite que muchos usuarios, físicamente separados, estén trabajando sobre la misma máquina, sin interferirse entre ellos.

- LINUX es uno de los sistemas con más seguridad de l os existentes a pesar del punto anterior, gracias a que incorpora, entre otras muchas herramientas, el sistema de contraseñas basado en el algoritmo DES, el más probado de los algoritmos de seguridad.

- Otra ventaja de LINUX es su forma de tratar a los d ispositivos , ya que éstos se encuentran almacenados en el directorio /dev del sistema, tratados como si fueran objetos en programación hoy en día. Esto supone que todos los dispositivos del sistema son tratados por igual, y que se pueden añadir tantos controladores como nuevos dispositivos se vayan añadiendo.


Página 40 de 156

- Este sistema está enormemente preparado para su tra bajo incluido en redes de ordenadores , ya que dispone de protocolos PPP, SLIP, TCP/IP, PLIP, etc. Además de las ventajas que para este punto suponen su calidad de multitarea y multiusuario.

5.2.1. DISTRIBUCIONES

LINUX es distribuido, principalmente de tres maneras:

- Slackware: La distribución Slackware ha sido quizás la que ha pasado por más ordenadores desde que surgió LINUX. Fue compilada por Patrick Volkerding, que es el que posee sus derechos de autor. Sin embargo, desde un tiempo a esta parte tanto Debian como Red Hat gozan de gran popularidad, debido quizás a la forma más compacta de distribución de sus paquetes y a la vistosidad de sus interfaces de instalación.

- Red-Hat: Esta distribución ha sido desarrollada por Red Hat Software, en EE.UU. Según su distribuidor, varias innovaciones en la instalación hacen de Red Hat la distribución de LINUX más fácilmente instalable de cuantas han surgido. En primer lugar, su instalación gráfica se realiza desde X Windows durante la mayor parte del tiempo, lo que hace mucho más amigable todo el proceso de instalación de paquetes. Por otra parte, se proporciona un script de creación de disco de arranque, que facilita la selección del disco de arranque adecuado, y guarda la información de configuración de red existente y la XF86Config, por lo que no hay que configurar ni TCP/IP ni X Windows. Además dispone de una instalación FTP que permite instalar Red Hat bajándose de la red 3 imágenes de disquetes. El resto del proceso es automático. Pero el punto más fuerte de esta distribución es el Red Hat Package Manager. El RPM permite la instalación y desinstalación de los paquetes al más puro estilo Windows, de tal forma que no quedan componentes sueltos sin desinstalar, y es aplicable incluso al núcleo. Este novedoso sistema ha sido generosamente distribuido bajolicencia GPL, y se espera que sea imitado en próximas versiones de otras distribuciones.

- Debian: La Free Software Fundation (FSF) es la creadora del sistema GNU, su futuro UNIX gratuito y de la licencia GPL. Aún no tienen un sistema operativo completo, así que, mientras tanto, ofrecen un UNIX integrado por el núcleo de LINUX y el software de GNU. Debian es el resultado de los esfuerzos voluntarios para crear una distribución LINUX no comercial de alta calidad. Debian LINUX 1.3 es un sistema operativo compatible con UNIX completamente funcional para ordenadores PC con versiones para SPARC, M68K y ALPHA. Sus ventajas son facilidad de actualización, dependencias bien definidas entre paquetes y un desarrollo abierto. Es la única distribución de LINUX que está siendo desarrollada por muchas personas cooperando a través de Internet, con el mismo espíritu de LINUX y el Free Software. Por último, hay que comentar que Debian es una distribución muy dinámica. Cada tres meses se hace una pequeña actualización y los archivos FTP son renovados diariamente.


Página 41 de 156

Este sistema, en cualquiera de sus distribuciones, sufre numerosas actualizaciones, realizadas por un grupo de expertos y en base, muchas veces, a las implementaciones que realizan sobre el sistema usuarios del mismo.

5.3. DISPOSITIVOS DE COMUNICACIONES EN LINUX

En este apartado, se vera la forma de administrar la memoria y los búffers para la gestión de los dispositivos de comunicaciones de LINUX. También serán vistos los cambios a efectuar sobre el núcleo del sistema operativo para agregar nuevos dispositivos.

5.3.1. DEFINICIÓN DE CONCEPTOS

El modelo de capas ISO aplicado a las redes, intenta crear una estructura jerárquica, como ya se ha visto en la primera parte de este proyecto. El modo de funcionamiento del núcleo del sistema operativo LINUX trabaja de una forma similar, como se vera más adelante. Puesto que se tratara habitualmente en este apartado con determinados conceptos, voy a hacer una pequeña definición de ellos, a fin de poder utilizar la misma nomenclatura en todo el texto:

5.3.1.1. DISPOSITIVO O INTERFAZ

Un interfaz de red es un dispositivo que envía y recibe paquetes. Habitualmente es un circuito hardware, como una tarjeta Ethernet, que transmite y recibe información a través de un cable, pero en ocasiones puede tratarse de un programa software, como es el caso del dispositivo denominado “loopback”, cuya misión es servir de “tarjeta de red para pruebas” y su funcionalidad permite devolver a la estación todos los paquetes que se le envían, (nunca salen del sistema, y no son tratados por ningún hardware especial).

5.3.1.2. PROTOCOLO

Un protocolo es un “idioma” utilizado para que dos máquinas puedan entenderse e intercambiarse información. Todos los protocolos podrían englobarse en tres áreas:

- Protocolos propietarios: Son aquellos desarrollados por un determinado fabricante, de manera que tan sólo los sistemas pertenecientes a ese fabricante podrán comunicarse entre sí. Dentro de este bloque podrían englobarse aquellos que intercambian máquinas dentro de un mismo sistema, sin que sea necesario que sean compartidos por ningún otro sistema nuevo, por ejemplo, el protocolo entre el circuito de mandos de un televisor y la circuitería que obedece la orden. En este grupo se identificaría nuestro protocolo RPP.


Página 42 de 156

- Protocolos de propósito general: Normalmente, este tipo de protocolos son adoptados por diversos fabricantes para sus sistemas. Suelen estar amparados bajo alguna institución (normalmente creada por los mismos fabricantes o por los gobiernos) que dictaminan todos los parámetros que deben ser adoptados, posibles modificaciones, etc.

En el sistema operativo LINUX, cada protocolo es una porción independiente de código que, por un lado brinda servicios a la capa de enlace, y por el otro ofrece información y órdenes de las capas de aplicación (que son las mismas para todos los protocolos de las capas de red).

5.3.1.3. ENLACE

Un enlace es una conexión en la red que permite la transmisión y recepción de archivos y de otra información dentro de aplicaciones de usuario. En el núcleo de LINUX, cada enlace está definido como dos estructuras distintas que representan el interfaz de nivel de enlace y el interfaz de nivel de protocolo.

5.3.1.4. SK-BUFF

Todos los búffers usados por cualquier capa de red se denominan SK-BUFF. El control de estos búffers es realizado por las rutinas disponibles en librerías localizadas en el núcleo del sistema. Estas rutinas proporcionan todas las funciones necesarias para la gestión del flujo de tráfico en ambos sentidos, necesaria en todos los protocolos de red.

5.3.2. IMPLEMENTACIÓN DE LOS SK-BUFF

La principal tarea de las funciones SK-BUFF es proporcionar un método eficiente de manipulación de los búffers para todas las capas de red, y hacer posible proveer a los SK-BUFF de niveles superiores de los protocolos correspondientes.

Un SK-BUFF es una estructura de control con una porción de memoria asignada. Existen dos conjuntos de funciones en la librería SK-BUFF:

- Funciones para manipular las uniones entre los SK-B UFF de distintos niveles

- Funciones para controlar las porciones de memoria a signadas

En definitiva, estas funciones permiten administrar los búffers que servirán para el intercambio de información entre los distintos niveles de la escala de red, es decir, para agregar protocolos de las escalas inferiores al transmitir, y eliminarlas al recibir.


Página 43 de 156

A continuación represento un pequeño listado con las funciones de LINUX que permiten estas operaciones, con la utilidad que proporcionan. Más adelante, durante el desarrollo software del dispositivo, se veran ejemplos prácticos sobre ellas, aunque ahora se van a representar en la figura un simplificado gráfico de los procesos seguidos:

Figura 13. Esquema simplificado del proceso de recepción de una trama

5.3.2.1. skb_dequeue()

Devuelve un puntero al primer búffer de una lista. Si la lista está vacía, devuelve un puntero apuntando a NULL. Esta función se usa para leer de la cola. A esta cola, se le añaden búffers mediante las funciones skb_queue_head() y skb_queue_tail().

5.3.2.2. skb_queue_head()

Coloca un búffer al inicio de una lista.

5.3.2.3. skb_queue_tail()

Coloca un búffer al final de una lista, más habitual que la anterior. El procedimiento normal de trabajar es añadir búffers con esta función y extraerlos con skb_dequeue().

5.3.2.4. skb_unlink()

Elimina un búffer de cualquier lista en la que se encuentre. El búffer no es eliminado, simplemente eliminado de la lista. Para hacer determinadas operaciones de forma más sencilla, no es necesario conocer en qué lista se encuentra el búffer, y siempre se puede llamar a la función skb_unlink(). La función implementará un algoritmo de búsqueda en todas las listas de búffers de todos los niveles de la red hasta encontrar el búffer que debe ser eliminado.


Página 44 de 156

5.3.2.5. skb_insert() Y skb_append()

Algunos protocolos complejos, como TCP, son capaces de reordenar las tramas recibidas (ya que la recepción no tiene por que ser en el mismo orden en el que fueron enviadas). Para esta labor, existen dos funciones denominadas skb_insert() y skb_append(), que colocan un búffer antes o después de otro determinado dentro de una lista.

5.3.2.6. alloc_skb()

Esta función crea un nuevo SK-BUFF y lo inicializa. El búffer que devuelve estará listo para usar y para rellenar sobre él los campos de datos y cabeceras de protocolos.

5.3.2.7. kfree_skb

Libera un búffer, a fin de ahorrar espacio en memoria.

5.3.2.8. skb_clone

Hace una copia de un SK-BUFF pero no copia el área de datos, que debe ser considerado de sólo lectura.

5.3.2.9. skb_copy()

En ocasiones es preciso disponer de una copia de los datos de un búffer, para funciones de edición, por ejemplo. En este caso, la función skb_copy() realiza la misma función que la anterior, pero copia también la zona de datos.

5.3.3. RUTINAS DE SOPORTE DE ALTO NIVEL

Todas las acciones a realizar sobre los búffers para los enlaces engloban también reglas de control de flujo. A fin de gestionar también esta parte, han sido implementadas en LINUX dos funciones:

- sock_queue_rcv_skb()

- sock_alloc_send_skb()

5.3.3.1. sock_queue_rcv_skb()

Esta función es usada para gestionar el tráfico recibido. Usa los contadores de lectura de cola de recepción para prevenir desbordamientos en la cola. Si a pesar de todo, el tamaño de ésta es superada, el resto de los datos son descartados, con lo que es misión del nivel superior leer lo suficientemente rápido de este búffer.


Página 45 de 156

En nuestro caso, puesto que el protocolo de nivel superior es FTP, no existe problema, ya que FTP transmite a la estación contraria un paquete indicando que espere antes de transmitir, puesto que tiene la cola llena. Además, a la velocidad de nuestra red, es casi seguro que jamás sucederá nada de esto.

5.3.3.2. sock_alloc_send_skb()

En la parte de transmisión, esta función permite indicar al nivel superior de la red si hay sitio en la cola de transmisión para poder ingresar más búffers.

5.3.4. DISPOSITIVOS DE RED

Todos los dispositivos de red de LINUX utilizan el mismo interface, aunque muchas funciones que se encuentran disponibles en este interface no serán necesarias para determinados dispositivos. Cada dispositivo es un objeto con una serie de funciones y variables que son almacenados en una estructura. Cada una de estas funciones debe ser llamada indicando el dispositivo sobre el que debe actuar.

Existe un archivo (drivers/net/skeleton.c) que contiene el esqueleto de un dispositivo de red. Sobre él podrá crearse un dispositivo con las funciones y características que sean precisas.

5.3.5. ESTRUCTURA BÁSICA

En la siguiente figura se puede ver la estructura básica de un dispositivo de red en LINUX:

Figura 14. Estructura de un dispositivo de red para LINUX.


Página 46 de 156

Cada dispositivo de red negocia directamente con la capa física el formato de los búffers a entregarle, y la forma en que le serán entregados, mediante los protocolos adecuados, y debe ser capaz de comprender las respuestas que el sistema hardware genera.

Las tramas recibidas son almacenadas en búffers de red, identificadas por protocolo usado y entregadas al sistema mediante la función netif_rx(). Esta función entrega entonces la trama al búffer de red del nivel superior.

Cada dispositivo proporciona un conjunto de métodos y funciones adicionales para gestionar el encapsulado de los paquetes en la capa física.

5.3.6. DENOMINACIÓN DE LOS DISPOSITIVOS DE RED

Todos los dispositivos de red de LINUX tienen una denominación única, que no está en absoluto relacionada con los nombres que los archivos de sus controladores puedan tener, y de hecho, normalmente los dispositivos de red no tienen una representación en forma de archivos, aunque podría crearse un dispositivo ligado a drivers de dispositivos.

Tradicionalmente, el nombre indica sólo el tipo de un dispositivo, no el fabricante u otra peculiaridad. Cuando existen varios dispositivos del mismo tipo, en la nomenclatura se enumeran comenzando en cero. Por ejemplo, los dispositivos Ethernet se conoce como “eth0”, “eth1”, “eth2”, etc. Este sistema de nomenclatura permite al programador identificar una tarjeta concreta sin preocuparse por su fabricante. Funcionando igual si se sustituye la tarjeta por otra.

A continuación represento algunas de las nomenclaturas más normales:


Página 47 de 156

NOMENCLATURA CONTROLADOR USO

ethn Controlador Ethernet de 10/100 Mbps Tarjeta de red de área local

trn Dispositivo Token Ring Tarjeta para redes en anillo

sln Dispositivos SLIP. Se usan en el modo AX.25 KISS

Usado para redes inalámbricas con protocolo Aereal X.25 y comunicación con la tarjeta en protocolo KISS (Keep it Simple, Stupid)

pppn Dispositivos PPP síncronos y asíncronos Enlaces punto a punto, como un módem externo

plipn Unidades PLIP. El número indica el puerto al que se conecta.

Plotters

tunln Túneles IPIP. Para configurar redes privadas virtuales (VPN)

nrn Dispositivo virtual NetROM Red virtual en memoria

isdnn Interfaces RDSI Gestiona un NT para red digital RDSI

Dummyn Dispositivo Null. No apunta a nada. Los datos que se envíen a este interfaz son desechados

lo Dispositivo loopback Los datos que se envíen a este dispositivo software son devueltos al sistema

Figura 15. Nomenclatura de los dispositivos de comunicaciones en LINUX

Nuestro dispositivo recibe el nombre de “rppn”. Puesto que lo normal es que sólo exista uno de ellos, éste se llamará “rpp0”

5.4. PROGRAMACIÓN DEL DISPOSITIVO EN LINUX

En este apartado, se creara un nuevo dispositivo en Linux, que gestionará nuestra red de comunicaciones inalámbricas. El código, que se representará completo en el ANEXO A de este libro, será analizado también en esta sección.

5.4.1. INICIALIZACION

La inicialización del dispositivo se realiza mediante la función rpp_init(). Ésta es llamada por el sistema al arrancar, pasándole como parámetros la estructura “device” que corresponde a este dispositivo. A continuación se va a explicar como se inicializan los diversos parámetros de esta estructura:

- dev->hard_start_xmit = rpp_xmit: Esto le indica a Linux que la función de transmisión es rpp_xmit.


Página 48 de 156

- dev->mtu = RPP_IP_MTU: Es el número de bytes máximo que deben tener los paquetes que Linux proporcione al driver.

- dev-irq = serie_irq[RPP_COM]: Indica la interrupción (IRQ) que va a ser utilizada por el dispositivo.

- dev->priv = kmalloc(sizeof(struct net_device_stats) ,GFP_KERNEL): Este puntero se utiliza para propósito general, en este caso para apuntar a la estructura donde se guardaran las estadísticas de comunicación.

- dev->get_stats = rpp_get_stats: Indica a Linux que la función rpp_get_stats() es la que proporciona las estadísticas.

- dev->open = rpp_open y dev->stop = rpp_close: Son llamadas cuando se activa o desactiva el driver con “ifconfig”.

- dev->tx_qeue_len = 0: Con este valor se le indica a Linux, que la cola que debe tener, a la hora de transmitir paquetes al dispositivo debe ser cero, es decir, que los paquetes que el driver rechace no sean almacenados en la cola de este dispositivo ya que no existe.

- dev->flags = IFF_NOARP: Significa que no se utilizara el protocolo ARP con este dispositivo. El protocolo ARP es el sustituido por nuestro protocolo RPP.

- dev_init_buffers(dev): Esta función inicializa el resto de parámetros de esta estructura con valores Ethernet genéricos, ya que para el funcionamiento del driver no afectan.

El resto de funciones, son inicializadas a NULL, ya que no son necesarias para el funcionamiento de este driver. Ademas este valor le indica al nucleo que estas no estan siendo utilizadas.

Los búffers y variables que utiliza todo el dispositivo también son inicializados y reservados por esta función. Esto se realiza como se puede ver en las siguientes líneas:

int rpp_init(struct device *dev) { /* Inicializa la estructura device */ int irqval; dev->hard_start_xmit= rpp_xmit; dev->irq = serie_irq[RPP_COM]; dev->priv=kmalloc(sizeof(struct net_device_stats), GFP_KERNEL); if (dev->priv == NULL) return –ENOMEM; memset(dev->priv, 0, sizeof(struct net_device_stats)); dev->get_stats = rpp_get_stats;


Página 49 de 156

dev->open = rpp_open; dev->stop = rpp_close; dev->set_multicast_list = NULL; dev->change_mtu = NULL; dev->hard_header = NULL; dev->rebuild_header = NULL; dev->set_mac_address = NULL; dev->hard_header_cache = NULL; dev->header_cache_update= NULL; dev->hard_header_parse = NULL; dev->hard_header_len = 0; /* Indica que el sistema no reserva espacio para introducir una cabecera */ dev->mtu = RPP_IP_MTU; /* Valor maximo del paquete IP */ dev->addr_len = 0; dev->type = ARPHRD_SLIP; /* Tipos de paquete a transmitir */ dev->tx_queue_len = 10; /* Numero de paquetes en cola que guardara el sistema */ dev->flags = IFF_NOARP; /* Indica que no se utilizara el protocolo ARP */ dev_init_buffers(dev); /* Inicializa los buffers del sistema */ /* Reserva memoria para la estructura rpp */ rpp = (struct rpp_data *)kmalloc(sizeof(struct rpp_data),GFP_KERNEL); if(rpp==NULL) { printk("%s: Error de memoria. rpp",dev->name); return -EAGAIN; } /* Reserva memoria para el buffer buffRX */ rpp->buffRX = (char *)kmalloc(MAX_RX,GFP_KERNEL); if(rpp->buffRX==NULL) { printk("%s: Error de memoria. buffRX",dev->name); return -EAGAIN; } /* Reserva memoria para el buffer circular */ rpp->circular_buffer = (char *)kmalloc(MAX_CIRCULAR,GFP_KERNEL); if(rpp->circular_buffer==NULL) { printk("%s: Error de memoria. circular_buffer",dev->name); return -EAGAIN; } /* El buffer TX no esta aqui porque es reservado dinamicamente */ /* Inicializa la estructura rpp */


Página 50 de 156

rpp->dev = dev; init_timer(&rpp_timer); rpp_timer.expires=jiffies+5; rpp_timer.data=0; rpp_timer.function=rpp_interrupt; add_timer(&rpp_timer); rpp->PWrite = 0; rpp->PRead = 0; rpp->buffTX_busy = 0; rpp->Uart = port_list[RPP_COM]; stats=(struct net_device_stats *)dev->priv; printk("Driver de red RPP\n"); /* Se comprueba que se puede usar la interrupcion */ irqval=request_irq(serie_irq[RPP_COM],&rpp_irq,0,cardname,NULL); if(irqval) { printk("%s: IRQ %d ya en uso\n",dev->name,dev->irq); dev->irq=0; return -EAGAIN; } else printk("%s: IRQ %d asignada\n",dev->name,dev->irq); /* Se comprueba que se pueden usar los puertos */ if(check_region(rpp->Uart,IO_EXTENT)==0) { printk("%s: Direcciones %d - %d de I/O asignadas\n",dev->name, port_list[RPP_COM],port_list[RPP_COM]+IO_EXTENT-1); request_region(rpp->Uart,IO_EXTENT,"rpp"); dev->base_addr=port_list[RPP_COM]; } else { printk("%s: Direcciones %d - %d de I/O ya en uso\n",dev->name, port_list[RPP_COM],port_list[RPP_COM]+IO_EXTENT); dev->base_addr=0; return -EAGAIN; } init_puerto(rpp->Uart); /* Inicializa el puerto */ return 0; }

Figura 16. Código de inicialización del dispositivo


Página 51 de 156

Para controlar la comunicación se inicializa un timer con la función add_timer() que proporciona el sistema, para que cada 50 milisegundos se llame a la función rpp_interrupt(). Estos 50 milisegundos son fijados mediante rpp_timer.expires = jiffies + 5 de tal manera que esta función será llamada cuando el valor de “jiffies” llegue al actual + 5, ya que la variable es incrementada por el sistema cada 1/100 segundos. Esto se realiza en el siguiente código.

init_timer(&rpp_timer); rpp_timer.expires=jiffies+5; rpp_timer.data=0; rpp_timer.function=rpp_interrupt; add_timer(&rpp_timer);

Figura 17. Código de inicialización de la interrupción temporal del dispositivo

Por último se comprueba si se pueden utilizar los puertos e interrupciones de la UART para acceder al puerto serie. En caso de estar ocupados se devuelve un error y el dispositivo no es instalado, si por lo contrario están libres, estos se reservan para que no puedan ser utilizados por ningún otro programa. Todo esto se puede ver en el código que viene a continuación.

/* Se comprueba que se puede usar la interrupción */ irqval=request_irq(serie_irq[RPP_COM],&rpp_irq,0,cardname,NULL); if(irqval) { printk("%s: IRQ %d ya en uso\n",dev->name,dev->irq); dev->irq=0; return –EAGAIN; } else printk("%s: IRQ %d asignada\n",dev->name,dev->irq); /* Se comprueba que se pueden usar los puertos */ if(check_region(rpp->Uart,IO_EXTENT)==0) { printk("%s: Direcciones %d - %d de I/O asignadas\n",dev->name, port_list[RPP_COM],port_list[RPP_COM]+IO_EXTENT); request_region(rpp->Uart,IO_EXTENT,"rpp"); dev->base_addr=port_list[RPP_COM]; } else { printk("%s: Direcciones %d - %d de I/O ya en uso\n",dev->name, port_list[RPP_COM],port_list[RPP_COM]+IO_EXTENT); dev->base_addr=0; return –EAGAIN;


Página 52 de 156

} init_puerto(rpp->Uart);

Figura 18. Código de inicialización de la UART

Para finalizar la función devuelve un cero, indicando al sistema que el driver ha sido perfectamente inicializado y que no existe ningún error.

5.4.2. ACTIVACION Y DESACTIVACION

La activación y desactivación del búffer se realiza mediante las funciones rpp_open() y rpp_close(). Estas funciones realizan los siguientes puntos:

- Presentación de un mensaje de activación o desactivación, según el caso.

- Fijan la variable open, a 1 para activar y a 0 para desactivar. Cuando esta variable se encuentra con el valor 0, el resto del driver lo detecta y queda inhabilitado.

- En la función rpp_close ademas de esto se incluye una linea que inicaliza el puerto serie, con la consecuente puesta en recepcion de la emisora.

/* * Funcion OPEN * * Es llamada al ejecutar ifconfig */ static int rpp_open(struct device *dev) { printk("Driver RPP Habilitado\n"); open=1; return 0; } /* * Funcion CLOSE * * Es llamada al ejecutar ifconfig con la opcion down */ static int rpp_close(struct device *dev) { printk("Driver RPP Deshabilitado\n"); init_puerto(rpp->Uart); open=0; return 0; }

Figura 19. Código de las funciones de activación y desactivación


Página 53 de 156

5.4.3. TRANSMISION

Para la transmisión el nivel superior llama a la función rpp_xmit() de tal forma que le proporciona un búffer SKB con los datos del paquete y un puntero a la estructura “device”.

En primer lugar se llama a la función add_buffer, la cual es la encargada de añadir el búffer a la lista de búffers, colocándolo el último en la cola de transmisión. En el caso de que la lista llegara a contener un numero de buffers máximo, la función add_buffer devolvería NULL, y se le indicaría al nivel superior que el paquete no ha sido admitido.

En caso de no rechazar el paquete, se llamara a la función rpp_add_header, la cual añadirá al búffer que contiene el paquete, la cabecera, en función de la dirección IP a la que se envía. La dirección RPP se calcula utilizando el byte mas bajo de la dirección IP. En el caso de que el resto de la dirección no coincida con la red en la que se encuentra el driver, la dirección RPP asignada será el gateway de la red RPP.

Por último, el búffer SKB que nos ha proporcionado el nivel superior será liberado, y se devolverá el valor 0.

Static int rpp_xmit(struct sk_buff *skb, struct device *dev) { struct buffers *lista; lista=add_buffer(skb); if(lista==NULL) /* Se comprueba si el búffer esta ocupado */ { dev->tbusy=1; /* Se le indica a linux que el driver esta ocupado en TX */ return 1; /* y se devuelve un error */ } dev->tbusy=0; /* Añade la cabecera al búffer */ rpp_add_header(lista->buffer,skb->len+LEN_HEAD_RPP); dev_kfree_skb(skb); /* Libera el búffer que linux nos ha proporcionado */ return(0); }

Figura 20. Código de la transmisión de un paquete

5.4.3.1. BÚFFER DE TRANSMISION

Este búffer de transmisión, es en concreto un búffer de búffers, ya que lo que hace es almacenar todos los paquetes que va mandando el nivel superior, de tal forma que no se pierdan, y el driver pueda transmitirlos.

Se basa en el sistema de listas enlazadas, por lo que es totalmente dinámico, reservando la memoria necesaria en cada momento y manteniendo un total control


Página 54 de 156

sobre el número de paquetes almacenados, y el orden en que deben ser transmitidos.

Las listas enlazadas utilizan el concepto unir estructuras mediante punteros, en las cuales se encuentran almacenados los paquetes (en concreto se encuentra almacenado un puntero al paquete) que se desean transmitir.

Figura 21. Estructura de listas enlazadas

Cada estructura contiene un puntero al paquete y un puntero a la siguiente estructura. En la última de ellas este apuntará a NULL, para poder distinguir cuándo termina la lista.

La ventaja que tiene este sistema consiste en que con un único puntero llamado first_buffer que apunta al primer búffer de la lista, se tiene acceso a toda la lista, ya que solo hay que ir accediendo a la estructura apuntada por el puntero que contiene la estructura actual, y así sucesivamente, hasta llegar a la deseada.

5.4.4. RECEPCION

En este apartado se va a explicar como se le proporciona al nivel superior un paquete que haya sido recibido.

Esto se realiza mediante la función net_up(), a la que se le proporciona el búffer recibido sin la cabecera RPP y la longitud. Para dar el paquete al nivel superior se reserva un búffer SKB y se le copian los datos del búffer, después se le dice que protocolo es el recibido y por último se le pasa este búffer mediante la función netif_rx. Esto se puede ver en las siguientes líneas:

int net_up(char *buffer, int len) { struct sk_buff *skb; skb = dev_alloc_skb(len); if (skb == NULL) { printk("%s: memory squeeze, dropping packet.\n", rpp->dev->name); return 0; } skb->dev = rpp->dev; memcpy(skb_put(skb,len), buffer, len); skb->mac.raw=skb->data; skb->protocol=htons(ETH_P_IP); netif_rx(skb);


Página 55 de 156

return 0;

}

Figura 22. Función de entrega de paquetes en recepción

5.4.4.1. BÚFFER CIRCULAR

El búffer circular esta destinado a la recepción y se utiliza para poder leer y escribir de forma que parezca que es un búffer infinito. Para esto se utilizan las funciones write_buffer() y read_buffer() que se pueden ver a continuación.

void write_buffer(unsigned char Dato) { int Paux = rpp->PWrite; if (rpp->PWrite==MAX_CIRCULAR-1) rpp->PWrite=0; else rpp->PWrite++; if(rpp->PWrite==rpp->PRead) rpp->PWrite=Paux; else

{ rpp->circular_buffer[Paux] = Dato; printk("%d ",Dato); }

}

Figura 23. Función de escritura del búffer circular


Página 56 de 156

int read_buffer(int Type, int Desp) /* Type = 0 -> No incrementa el puntero. */ /* Desp indica el desplazamiento */

/* Type = 1 -> Incrementa el puntero. */ /* Desp indica tambien el desplazamiento */ /* Type = 2 -> Devuelve el numero de bytes */ /* pendientes por leer. Desp no es utilizado */

{ int i; int Dato; int Paux = rpp->PRead; int Dif; if(Type!=2)

{ if(rpp->PRead==rpp->PWrite) return -1; if(rpp->PWrite < rpp->PRead) Dif=rpp->PWrite + MAX_CIRCULAR - rpp->Pread; else Dif=rpp->PWrite - rpp->PRead; if(Dif>=Desp)

{ Paux+= Desp; if(Paux > (MAX_CIRCULAR-1)) Paux-= MAX_CIRCULAR; Dato = rpp->circular_buffer[Paux]; if(Type==1) rpp->Pread=Paux; }

else Dato=-1; }

else { if(rpp->PRead > rpp->PWrite) Dato = rpp->PWrite + MAX_CIRCULAR - rpp->PRead; else Dato = rpp->PWrite – rpp->PRead; }

return Dato; }

Figura 24. Función de lectura del búffer circular

La posición de escritura y de lectura se controlan mediante dos punteros que se van incrementando según la operación que se realice sobre el búffer. Estos punteros dan vueltas al búffer indefinidamente, teniendo siempre la precaución de que no se solapen.

En el caso de que el puntero de lectura alcance al puntero de escritura, éste primero no debe de aumentar más, ya que no puede sobrepasarle. Si se intenta leer en esta circunstancia se dará un error indicando con ello que el búffer esta vacío.

Si lo que ocurre es que el búffer de escritura alcanza al búffer de lectura, este primero debe quedarse una posición antes, ya que si lo igualara como en el caso anterior se entendería que el búffer esta vacío, cuando esta ocurriendo todo lo contrario. En este caso si se intenta escribir en el búffer no se dará ningún error, pero se desecharan todos los bytes que se intentan escribir.


Página 57 de 156

5.4.5. INTERRUPCION TEMPORAL

La interrupción temporal, como ya se ha explicado anteriormente, se produce cada 50 milisegundos. Es la encargada de controlar la transmisión y la recepción llamando a las funciones rx_control() y tx_control().

void rpp_interrupt(unsigned long data) { cli(); if(TX_Flag==0) rx_control(); /* Si no se esta transmitiendo se controla la recepción */ tx_control(); /* Controla la transmisión */

/* Timer */ rpp_timer.expires=jiffies+5; add_timer(&rpp_timer); }

Figura 25. Código de la interrupción temporal

5.4.5.1. CONTROL DE RECEPCIÓN

La recepción se controla mediante la función rx_control(), la cual sólo es llamada si no se está trasmitiendo. Ésta primero llama a la función packet_rx() que se encarga de leer del búffer circular comprobando si ha llegado un paquete entero, devolviendo un puntero al búffer de recepción en caso afirmativo y NULL en caso contrario. A continuación se puede observar la función rx_control().


Página 58 de 156

Char *packet_rx(char *buffer) { int estado; estado = comp_init_rpp(); /* comprueba que ha llegado el inicio de un paquete */ if(estado==-1) return NULL; comp_conf(); Stop_Count=1; Estado = comp_total_rpp(); /* comprueba que el paquete ha llegado entero */ If(estado==-1) return NULL; If(estado==-2) {Stop_Count=0; return NULL;} Stop_Count = 0; Estado = check_CRC(); /* comprueba la integridad del paquete mediante el CRC */ If(estado==-1) /* En caso de no ser correcto elimina el paquete */ { del_rpp_packet(); return NULL; } buffer = copy_rpp_packet(); /* Copia el paquete en el búffer de recepcion */ del_rpp_packet(); return buffer; }

Figura 26. Control de recepción

Cuando se empieza a recibir un paquete se fija un nuevo tiempo aleatorio y además se inhibe la cuenta atrás de éste, para que nunca se llegue a la condición de transmisión, la cual es indicada cuando este valor llega a cero.

En esta función también se controla que el paquete que se ha recibido sea una confirmación. En este caso se comprobará si esta es para esta máquina, en cuyo caso se eliminará del búffer circular al igual que se eliminará el primer paquete en la lista de transmisión, ya que la confirmación indica que este paquete ha sido recibido.

5.4.5.2. CONTROL DE TRANSMISIÓN

Al igual que en la recepción la transmisión la controla una función llamada tx_control(). Esta función primero comprueba que el tiempo de espera de transmisión ha llegado a cero, en ese caso, si existe un búffer para transmitir, se llama a la función TX_On(), la cual conmuta la emisora a transmisión y por último se hace una llamada a la función Init_TX(), que empezará a transmitir datos 100 milisegundos después.

En esta función tambien se controla si la cuenta inversa del tiempo aleatorio debe detenerse, al igual que se comprueba si existe un time_out en la recepción

La función tx_control() se puede observar a continuación.


Página 59 de 156

Int tx_control(void) { if(Stop_Count==0) /* Indica el tiempo de espera antes de tranmitir */ /* Este es fijado aleatoriamente */ { tx_delay_time--; if(tx_delay_time<0) tx_delay_time=0; } if(Stop_Count==1 && jiffies > rx_delay_time+50) /* Comprueba que la recepción no */ /* tiene un time_out */ { del_rpp_packet(); Stop_Count=0; } if(tx_delay_time==0 && TX_Flag==0) /* Si ya es posible transmitir, */ /* y no se esta transmitiendo ya, */ /* se pone la emisora en transmisión */ if(rpp->buffTX_busy==1) TX_On(PACKET); if(TX_Flag>1) { TX_Flag++; /* Con este contador se espera el tiempo de conmutacion de la emisora */ Init_TX(TX_Mode); } return 0; }

Figura 27. Control de transmisión

5.4.6. DIRECCIÓN RPP

La dirección RPP se obtiene del ultimo byte de la dirección IP, esta se fija de forma estatica mediante varibables del preprocesador de la siguiente manera:

IP_ADDR0 10 /* Dirección 10.21.211.2 */ IP_ADDR1 21 IP_ADDR2 211 IP_ADDR3 2

Al estar de forma jifa en el sistema, si se realiza un cambio en la dirección IP del sistema, se deben de cambiar tambien estas lineas del driver, y por lo tanto recompilar el nucleo.

Debido a que el sistema utiliza solo el ultimo byte de la dirección IP, para obtener la dirección RPP, si solo se analizara esta, no se podrian distinguir la direcciones IP que tuvieran el byte bajo con el mismo valor.


Página 60 de 156

Por ejemplo, la direccion 2.0.0.5 seria igual a la 10.2.12.5

Para solucionar este problema, se tienen en cuenta los otros tres bytes, de tal forma que si no coinciden con la dirección IP fija del driver, el paquete sera enviado a la dirección RPP 254, la cual es el gateway de la red RPP.

� Ejemplo:

La dirección RPP esta fijada como 10.0.0.5

Se envia un paquete dirigido a la dirección 2.0.0.5

� 2.0.0.5 IP � 254 RPP

Como se puede obsservar sera enviado a la dirección RPP 254 y no a la 5 como en principio cabria suponer.

5.4.7. INTERRUPCIÓN DE LA UART

La UART (Unidad de Transmición y Recepción Asíncrona) es la encargada de trasmitir y recibir los datos por el puerto serie. Ésta debe programarse para ajustarla a la velocidad que se requiere, activar las interrupciones de TX y RX, etc.

Para realizar todo esto se han seguido los siguientes pasos:

- outb(0x83,Addr+3): Programa la UART para acceder al divisor.

- outb(DIVISOR & 0xff,Addr): Escribe el byte bajo del divisor.

- outb(DIVISOR >> 8,Addr+1): Escribe el byte alto al divisor.

- outb(0x03,Addr+3): Pone la UART en funcionamiento normal y fija la comunicación a 8 bits de datos, 1 bit de stop y sin paridad.

- outb(0x01,Addr+1): Activa la interrupción de recepción.

- outb(0x08,Addr+4): Permite la generación de interrupciones.

Para calcular cual es el divisor se debe seguir la siguiente formula:

DIVISOR = 1843200 / (16 * BAUDIOS)

Donde BAUDIOS es la velocidad en bits/s (En nuesto caso será de 9.600) y 1843200 es la frecuencia de reloj de la UART.

5.4.8. AÑADIR EL DRIVER AL NÚCLEO DE LINUX

Para poder incluir el driver en el núcleo de LINUX, es necesario que al compilarlo, éste pueda encontrar el driver, compilarle, y además lo introduzca en la


Página 61 de 156

estructura device que contiene el sistema. Esta estructura es utilizada para que LINUX pueda hacer referencia al driver y así poder llamar a todas las funciones relacionadas con el.

Para que el núcleo pueda ser compilado con el driver, se debe incluir en el archivo Makefile, que se encuentra en el directorio, /usr/src/linux/drivers/net las siguientes líneas:

Ifeq ($(CONFIG_RPP),y) L_OBJS += rpp.o Endif

Figura 28. Modificaciones sobre el archivo Makefile

CONFIG_RPP es la variable del preprocesador que indica que todo lo relativo al driver RPP debe ser compilado.

En este archivo se debe añadir una última línea que se puede ver a continuación. Debe ser añadida al final del archivo.

� rpp.o: rpp.c

El siguiente paso a realizar (ya que con incluir esta línea todavía no es suficiente) consiste en añadir al archivo de configuración, donde se seleccionan que se quiere compilar las siguientes líneas:

Este archivo se llama Config.in y se encuentra en el directorio /usr/src/linux/drivers/net

bool 'Radio Packet Protocol' CONFIG_NET_RPP if [ "$CONFIG_NET_RPP" = "y" ]; then tristate 'RPP support' CONFIG_RPP fi

Figura 29. Modificaciones sobre el archivo Config.in

Esto conseguirá que en el programa de configuración, con el que se selecciona qué opciones del núcleo se van a compilar, se vea lo siguiente:

[X] Radio Packet Protocol

[X] RPP support

La segunda opción solo se verá si la primera es seleccionada. La palabra tristate, significa que se pueden elegir tres opciones: compilar, no compilar, o añadir como módulo.


Página 62 de 156

A continuación, se le debe indicar al sistema cual es la función de inicialización del driver. Todo esto es indicado en el archivo Space.c que se encuentra en /usr/src/linux/drivers/net.

#ifdef CONFIG_RPP extern int rpp_init(struct device *dev); static struct device rpp_dev = { "rpp0", 0x0, /* recv Fin memoria */ 0x0, /* recv Inicio memoria */ 0x0, /* Fin memoria */ 0x0, /* Inicio memoria */ 0x0, /* direccion I/O base */ 0, /* IRQ */ 0,0,0, /* flags */ NEXT_DEV, /* Siguiente dispositivo */ rpp_init /* Puntero a la funcion init */ };

#undef NEXT_DEV #define NEXT_DEV (&rpp_dev) #endif

Figura 30. Modificaciones sobre el archivo Space.c

Como se puede ver en éstas líneas de código, se define la estructura device que corresponde a este dispositivo. Se inicializan todos los campos con cero excepto tres:

- El nombre que identifica al dispositivo, en este caso rpp0

- El puntero a la siguiente estructura device del sis tema. Esto se realiza con variables del preprocesador, de tal forma que se va creando una lista dinámica, antes de compilar

- Un puntero a la función rpp_init, que será llamada cuando el sistema arranque y comience a llamar a todas las funciones de inicialización de los drivers.

Después de modificar todos los archivos, e incluir el programa rpp.c, se debe proceder a recompilar el núcleo. Esto es un proceso un poco mas complicado y peligroso, ya que puede llevar a que el sistema no arranque adecuadamente.

Como primer punto se debe de entrar en el programa de configuración, para seleccionar las opciones a instalar. Este programa puede variar mucho en función de la distribución de LINUX que se tenga, e incluso existir varios programas diferentes dentro de una misma distribución.


Página 63 de 156

Los más llamativos podrían ser los interfaces gráficos que se pueden ver en distribuciones como Red Hat. En cualquier caso el resultado siempre va a ser el mismo.

En este caso, para compilar el driver, se utilizó la distribución Slackware, por lo que la configuración no era mediante gráficos, sino texto, pero se cuenta con un sistema de menús, que nos ayudan bastante a la hora de movernos por la gran cantidad de opciones.

Una vez seleccionadas las opciones a compilar, entre las cuales deben estar al menos incluidos el driver RPP, la pila de protocolos TCPIP y el soporte para redes, se debe proceder a la compilación del núcleo, realizando los siguientes pasos:

- Entrar en el directorio donde se encuentra el codigo fuente del nucleo

� cd /usr/src/linux

- Crear el archivo de dependencias

� make dep

- Limpiar los subdirectorios de archivos anteriormente compilados

� make clean

- Compilar el nucleo

� make zImage

Despues de realizar todos estos pasos, si no se produce ningún error, se debería de haber creado una imagen del núcleo en un archivo llamado zImage. Ésta se encuentra en el directorio /usr/src/linux/arch/init/boot .

En último lugar se debe de decidir como se quiere que arranque LINUX la próxima vez:

- Mediante loadlin. Programa que se ejecuta sobre MS-DOS y carga la imagen.

- Mediante un disco de arranque , para lo cual se debe de ejecutar el siguiente comando:

� makebootdisk

- Mediante lilo. Este es un programa que se graba en el MBR (Master Boot Record) y se puede configurar de tal forma que se decida que sistema operativo se quiere cargar (en el caso de que haya más de uno). La siguiente orden graba la imagen en el MBR.


Página 64 de 156

� lilo

5.5. DISPOSITIVO DE ENRUTAMIENTO DE LINUX

El router de LINUX es un “demonio” (software cargado de forma residente en la memoria del PC durante el inicio del sistema, y que no es gestionado por ningún otro proceso) denominado “routed”. Su función es enviar las tramas de la cola de transmisión a los distintos dispositivos, en función de una lista de enrutamiento, que será analizada en el siguiente apartado.

Routed utiliza un protocolo que es capaz de reconocer y trabajar con numerosos tipos de direccionamiento, pero la forma más habitual de usarlo es con direccionamiento IP, por su extensión.

Routed soporta el protocolo RIP, consistente (como se vio en la primera parte de este proyecto) en intercambiar las listas de acceso con otros dispositivos de encaminamiento adyacentes, para que la situación de las redes a las que brinda servicios sea distribuida.

Cuando se inicia este software, detecta qué dispositivos se encuentran activos en el sistema (ignorando el dispositivo loopback). Si existen varios dispositivos activos, interpreta que el sistema va a trabajar como un router entre redes. Entonces, transmite un paquete de broadcast a cada uno de los interfaces, con la finalidad de esperar respuesta de otros encaminadores conectados en estas redes.

Cuando se recibe un paquete de respuesta a esta señal de broadcast, el dispositivo contesta dando información de sus tablas de enrutamiento.

Los otros dispositivos a los que se haya conectado, enviarán a éste sus propias tablas, que serán añadidas a la original.

Este proceso se repite de forma periódica o cada vez que sea añadida una nueva ruta en su configuración. Puesto que en nuestra red no existe ningún otro dispositivo encaminador entre redes, este proceso no cargará nuestra red, siendo en la línea Ethernet donde se transporten estas informaciones.

Routed proporciona, además de su funcionamiento básico, una serie de servicios, en función de los parámetros que le sean entregados a la hora de iniciarlo:

- Habilitar informes de log , que indicarán estadísticas del tráfico tratado, como paquetes erróneos, por ejemplo.

- Indicar una dirección donde se han de enviar todos aquellos paquetes cuyo destino no figure en la tabla de listas de acceso , es decir, indicar el gateway por defecto.


Página 65 de 156

- Dar información acerca de qué protocolos tienen acc eso a través de él , y cuales de ellos son o han sido usados.

- Imprimir en la salida estándar (normalmente el moni tor, pero podría ser una impresora) todos los paquetes que son enviados y/o recibidos .

- Almacenar un archivo en el disco duro del ordenador , en el que indiquen todas las acciones que routed realiza (envío y recepción de paquetes, modificación de configuraciones, etc.)

Además de todas estas características, routed entiende el concepto de distancia (según se vio en la primera parte del proyecto) para dictaminar cual será la mejor ruta de un paquete si se configuran algoritmos de ruteo dinámicos.

Puesto que debe haber un camino, si no se trata de una red local sin conexión a otras redes, con la red ARPANET, Routed también soporta el protocolo EGP (ver primer libro), que permite a todos los dispositivos de red encontrar las rutas estáticas que hayan sido configuradas en otros gateways para poder alcanzar esta red usando el mejor camino.

5.5.1. CONFIGURACIÓN DEL DISPOSITIVO DE ENRUTAMIENT O

En este apartado se va a ver cómo se crea la tabla de enrutamiento que precisa el dispositivo encaminador de LINUX. Para ello, se va primero a repasar el direccionamiento que había sido asignado a nuestra red:

- Usuarios de la red: Rango de la x.y.z.1 a la x.y.z.253

- Gateway: Dirección x.y.z.254

- Dirección de loopback de cada estación: 127.0.0.0 con máscara 255.0.0.0, esto es, cualquier dirección cuyo primer byte sea 127.

Cualquier otra dirección estará bien en la red Ethernet a la que se conectará el gateway, o bien a la salida de su puerta de acceso.

Con todo esto, se podra establecer la lista de enrutamiento de cada uno de los usuarios, y la del gateway. Han de definirse, en estas listas de acceso, los siguientes parámetros:

- Dirección de red destino.

- Máscara de la dirección de red destino.

- Dirección de gateway o puerta de enlace.

- Dispositivo al que enviar el paquete.


Página 66 de 156

5.5.1.1. LISTA DE ENCAMINAMIENTO DE UN USUARIO

Un usuario normal de nuestra red, necesitará establecer la siguiente lista de encaminamiento:

- Si el destino del paquete es la misma estación, deberá ser enviado al dispositivo de loopback, sin gateway.

- Si el destino es cualquier otro de la red x.y.z.0, deberá ser enviado a nuestro dispositivo (rpp0) sin configuración de gateway.

- Si el destino es cualquier otra red, se enviará, a través del dispositivo rpp0, pero configurando como dirección de gateway la x.y.z.254 (gateway de nuestra red)

En la práctica, habrá que incluir las siguientes líneas:

� ifconfig rpp0 x.y.z.a netmask 255.255.255.0

donde a será la dirección de rpp0, es decir, la asignada a la propia estación. Esta línea inicializa el dispositivo, asignándole la dirección IP especificada.

� route add –net 127.0.0.0 netmask 255.0.0.0 lo

� route add –net x.y.z.0 netmask 255.255.255.0 rpp0

� route add default gw x.y.z.254

5.5.1.2. LISTA DE ENCAMINAMIENTO DEL GATEWAY

En el caso especial del gateway, se precisará que:

- Si el destino del paquete es la misma estación, deberá ser enviado al dispositivo de loopback, sin gateway.

- Si el destino es cualquier otro de la red x.y.z.0, deberá ser enviado a nuestro dispositivo (rpp0) sin configuración de gateway.

- Si el destino pertenece a la red conectada directamente al dispositivo que nos enlazará con el exterior, se enviará directamente a ese host, sin configuración de gateway.

- Si el destino es cualquier otra red, se enviará, a través del dispositivo eth0 (o el dispositivo que establezca enlace con la red externa), configurando como dirección de gateway la que tenga el encaminador que asu vez enlace esa red con el exterior.


Página 67 de 156

En la práctica, habrá que incluir las siguientes líneas:

� ifconfig rpp0 x.y.z.a netmask 255.255.255.0

donde a será la dirección de rpp0, es decir, la asignada al gateway. Esta línea inicializa el dispositivo, asignándole la dirección IP especificada.

� route add –net 127.0.0.0 netmask 255.0.0.0 lo

� route add –net x.y.z.0 netmask 255.255.255.0 rpp0

� route add –net [Red Ethernet] netmask [Máscara Ethe rnet] eth0

Red Ethernet: Dirección de la red a la que se encuentre conectado

Máscara Ethernet: Máscara de la misma red Ethernet

Eth0: Será el dispositivo que le conecte con esta red Ethernet

� route add –net default gw [Gateway Ethernet]

Gateway Ethernet: Será la dirección del dispositivo que enlace la red Ethernet con el exterior.


Página 68 de 156

6. DISEÑO DE LA INTERFAZ BASADA EN DSP

Es objeto de este apartado el diseñar el circuito completo de la interfaz basada en DSP que se introdujo en la primera parte de este proyecto.

Para ello, se hara una introducción de las características que debe disponer la interfaz, para pasar posteriormente a desarrollar el hardware de cada uno de los bloques de la misma.

Por último, se hará una descripción del esquema eléctrico completo, y del diagrama de flujo del software que será cargado en su memoria y ejecutado por el DSP.

6.1. CARACTERÍSTICAS GENERALES

La interfaz a diseñar debe cumplir con una serie de características para que sea válida a la hora de poder ser aplicada en nuestro sistema completo de comunicaciones IP inalámbricas.

Los requisitos fundamentales con los que debe cumplir son:

- Alimentación en corriente continua a 12 voltios , con la finalidad de que la fuente de alimentación utilizada para alimentar el transceptor pueda ser también usada para la interfaz.

- Comunicación con el Ordenador Personal (PC) a travé s de una interfaz serie tipo RS – 232. Deben ser utilizadas únicamente las señales RXD y TXD de dicha interfaz.

- Modulación de las señales de entrada por la interfaz RS – 232 y demodulación de la señal entregada por el transceptor a una velocidad de 9600 bits por segundo .

- Control de la conmutación del modo de recepción al de transmisión y viceversa del transceptor . Deberá poder seleccionarse el modo de conmutación entre los dos tipos más habitualmente usados:

- Activación mediante puesta a masa de una señal, y entrada de señal por otra línea independiente.

- Activación mediante reducción de la impedancia de entrada de la línea de entrada de señal.

A partir de estas características, se comenzara entonces el diseño de la interfaz. Primeramente, se recordara el diagrama de bloques que se presentaba en la primera parte de este proyecto, pero profundizando más en cada uno de los bloques, hasta conseguir un concreto circuito eléctrico para cada uno de ellos.


Página 69 de 156

6.2. DESARROLLO HARDWARE DE CADA BLOQUE

El diagrama de bloques del sistema completo fue ya mostrado en la primera parte de este libro. En este apartado retornaremos este mismo diagrama apara poder realizar el diseño de cada uno de los bloques.

El diagrama de bloques de la interfaz se presenta en la siguiente figura:

Figura 31. Diagrama de bloques de la interfaz basada en DSP

Los circuitos integrados que formarán el centro activo de cada uno de estos bloques, serán objeto de estudio en los siguientes apartados:

- Interfaz RS - 232: MAX 232

- DSP: DSP 56002

- Fuente de alimentación: MC 7805

- Memoria: RAM 6206, EPROM 27 C 256

- DAC / ADC: CODEC CS 4215

- TX / RX: MC 33078


Página 70 de 156

6.2.1. ORDENADOR PERSONAL

El ordenador personal que se requiere para esta aplicación deberá disponer, como mínimo de las siguientes características:

- Microprocesador 486 a 50 MHz o superior.

- Mínimo 4 MB de memoria RAM.

- Sistema operativo LINUX. Deben encontrarse instalados todos los elementos de red IP.

- Puerto serie tipo RS – 232 disponible, provisto de una UART 8250 o superior.

- Software de comunicaciones (aplicaciones de HTML, FTP, TELNET, etc.)

- Para el gateway, tarjeta de red Ethernet u otro dispositivo de enlace a otra red externa.

Sobre esta máquina, se instalará el dispositivo de comunicaciones que ha sido diseñado en el apartado anterior, y deberán configurarse las aplicaciones para que todas las capas de red asuman el direccionamiento IP asignado, y la dirección de la puerta de enlace.

Así mismo, deberá configurarse el dispositivo de enrutamiento según se describió anteriormente.

6.2.2. ALIMENTACIÓN

Uno de los parámetros importantes a tener en cuenta en cualquier circuito electrónico, como ya es sabido, es la alimentación del mismo. En nuestro caso, aunque se podría haber establecido una alimentación de corriente continua con una amplitud de 5 voltios, se ha optado por incorporar a la tarjeta un regulador de tensión, cuya misión es reducir la tensión de 12 a 5 V. El motivo de esta decisión es que, para que nuestra tarjeta sea útil, es preciso que exista un transceptor y, la mayoría de estos equipos son alimentados con una tensión de 12 V. y una corriente elevada. De esta forma, se podra utilizar la misma fuente de alimentación que el transceptor y evitar tener que adquirir otra especial de pequeña corriente para la tarjeta.

El centro activo de este circuito está basado en el circuito integrado regulador 7805. Básicamente, es un circuito que mantiene su salida a 5 V. con un amplio margen de tensiones de entrada. El circuito de este bloque es el que se representa a continuación:


Página 71 de 156

Figura 32. Fuente de alimentación del sistema

El funcionamiento de este circuito es muy simple. La alimentación de 12 voltios es aplicada al conector P3 y la corriente de todo el circuito atraviesa el interruptor S2. El diodo D4 ha sido colocado para evitar daños en el sistema en caso de una polaridad errónea en la entrada. Los condensadores C37 y C38 filtrarán las variaciones de la tensión en baja y alta frecuencia, respectivamente.

Esta tensión, de aproximadamente 11’4 voltios, es aplicada a la entrada del regulador U11. A su salida estará presente una tensión muy estable de 5 voltios de amplitud. Con el filtro en pi realizado con los condensadores C39 y C40 y la bobina L1, se asegura una mayor estabilidad de la tensión, a la vez que se evitan variaciones bruscas de la corriente que se aplica al circuito. La resistencia R20 y el diodo LED D3 indicarán que existe tensión en la tarjeta.

Dentro de este bloque, se incluira también otro circuito que estará compuesto por un número determinado de condensadores de 100 nanofaradios situados físicamente al lado de cada componente activo. Estos condensadores filtrarán posibles interferencias que hayan sido inducidas en las pistas del circuito impreso.

El circuito de conexionado de todos estos elementos es el que se representa en la siguiente figura:


Página 72 de 156

Figura 33. Condensadores de filtro. Deben situarse cercanos a los circuitos correspondientes

Como se ve en la figura, se insertarán 6 condensadores para el elemento central, el DSP 56002. Estos condensadores, deberán reunir cada uno de los seis grupos de pines de alimentación descritos en la primera parte de este proyecto, y deberán situarse físicamente cercanos al DSP, de tal manera que las pistas de alimentación y masa tengan el mínimo recorrido posible entre estos condensadores y el propio DSP.

Para el elemento analógico / digital, el circuito integrado CS 4215, se insertarán cuatro condensadores, cada uno de los cuales se situará en cada uno de los cuatro lados del circuito, y agruparán a los pines de alimentación del circuito integrado.

Para el resto de los circuitos integrados de la interfaz (MAX 232, 74 LC 157, MC 33078, 6206, 27 C 256 y 74 LC 00) se pondrá un solo condensador, situado, al igual que todos, lo más cerca posible de los pines de alimentación del circuito integrado en cuestión.

6.2.2.1. CIRCUITO INTEGRADO MC7805

El circuito integrado MC 7805 se trata de un simple regulador de tensión encapsulado en un formato TO-220, como se muestra en la figura siguiente:

Figura 34. Circuito integrado MC 7805


Página 73 de 156

Este componente, debidamente disipado, es capaz de mantener una corriente de 1 Amperio y una tensión de salida de 5 Voltios aplicando a su entrada una tensión comprendida entre 7.5 y 35 voltios.

6.2.3. INTERFAZ RS – 232

La misión de este bloque es únicamente adecuar las señales digitales de niveles RS–232 a niveles TTL o viceversa. Sólo se precisará actuar sobre las señales de TXD y RXD (Transmisión y recepción de datos), ya que las señales RTS y CTS del puerto serie no van a ser utilizadas.

Puesto que el DSP 56002 de Motorola dispone de una interfaz serie interna (puerto SCI), bastaría con conectar directamente éstas señales a las entradas y salidas correspondientes de este bloque.

El circuito completo del interfaz RS – 232 de nuestra tarjeta se muestra bajo estas líneas:

Figura 35. Circuito de la interfaz RS – 232

Como se ve en la figura, las señales RXD y TXD pertenecientes al puerto SCI del DSP 56002, con niveles TTL, son aplicadas directamente al circuito integrado MAX 232. De éste salen otras dos conexiones, que son aplicadas a las señales RXD y TXD de la interfaz RS – 232 del PC. En esta interfaz se encuentran estas señales con niveles RS 232 (+12 voltios para un “cero” y –12 voltios para un “uno”).

Sólo cabe destacar que estas señales se encuentran cruzadas, es decir, la señal RXD del DSP se aplica a la señal TXD del PC, y viceversa ya que, lógicamente, la señal que uno transmite debe ser recibida por el segundo.


Página 74 de 156

6.2.3.1. CIRCUITO INTEGRADO MAX 232

Este es un circuito integrado encapsulado en un formato DIP de 16 patillas, tal como se muestra en al figura.

Su configuración es muy simple. En los pines marcados como C1+, C1

-, C2+ y

C2- se conectarán cuatro condensadores, según se ve en la figura del circuito. En los

pines Vcc y GND se conectará la alimentación, de cinco voltios, y entonces las señales R1IN y T1IN se podrán aplicar señales que serán entregadas, una vez convertidas de nivel, por los pines R1OUT y T1OUT.

Los pines marcados como V+ y V-, se conectarán también a la alimentación de cinco voltios.

Figura 36. Circuito integrado MAX 232

6.2.4. DSP 56002

Las características del conexionado del DSP 56002 de Motorola ya fueron comentadas durante el primer libro de este proyecto. Ahora, se vera el esquema eléctrico de dicha conexión, y se comentaran los aspectos más importantes del mismo:


Página 75 de 156

Figura 37. Circuito eléctrico del bloque del DSP

Dentro de este bloque han sido incluidos aquellos circuitos que, por sus características funcionales, se encuentran ligados al funcionamiento del DSP, tales como el circuito de reloj, el de reset o el de inicialización.

• Circuito de reloj: Este circuito, como puede verse en la figura siguiente, está compuesto simplemente por un cristal de cuarzo, dos condensadores y una resistencia. La función del oscilador es realizada internamente por el propio DSP. El fabricante fija los valores de los componentes de este circuito, de manera que el valor de la resistencia R será de 680 ohmios, y el los condensadores C de 20 picofaradios. El cristal de cuarzo será colocado de 4 MHz, y si fuera necesaria más velocidad de proceso, podrá efectuarse mediante la utilización del circuito multiplicador del PLL (tal como se explica en la primera parte de este proyecto), hasta un máximo de 40 MHz, que será la velocidad máxima del DSP.


Página 76 de 156

Figura 38. Circuito eléctrico del reloj del DSP

• Circuito de reset: El circuito de reset del circuito es el que se muestra en la figura siguiente. Ha sido incorporado el circuito integrado MC 34064, que permite resetear inmediatamente al DSP en el caso de que la tensión de alimentación caiga por debajo de un cierto umbral, de esta forma, se evitarán daños en el software que esté ejecutando el DSP debidos a que la tensión de los datos lógicos sean interpretados como niveles bajos, en lugar de altos. El fabricante indica los valores de los componentes C y R para un funcionamiento óptimo. Éstos son R = 9.2 K ohm y C = 1uF.

Figura 39. Circuito eléctrico del RESET del DSP


Página 77 de 156

• Circuito de selección del modo de trabajo: Ahora se estudiara el circuito que se encargará de inicializar los pines necesarios con la finalidad de que el DSP adquiera, durante su proceso de RESET, el modo de trabajo que será utilizado, tal y como se explicó en la primera parte de este proyecto, durante el estudio del DSP. Allí se vio que, en nuestro caso, durante el RESET deberán estar las señales MODA = 1, MODB = 0 y MODC = 0, mientras que tras el reset, estas tres señales deberán permanecer en nivel alto en ausencia de interrupciones hardware. Puesto que para nuestro diseño este tipo de interrupciones no van a ser implementadas, el circuito puede ser tan simple como el que se ve en la figura. Según el fabricante, las resistencias deberán ser de 15 K ohm, y los diodos del tipo MBD 301, que es un diodo del tipo Schottky de alta velocidad.

Figura 40. Circuito de la inicialización de modo de trabajo del DSP

El resto de las señales del DSP irán distribuyéndose por todos los demás bloques, ya que, como se ha dicho, se trata del bloque encargado de gestionar al resto. Por ello, se va a clasificar estas señales en los bloques a los que irán asignadas, para una mejor comprensión del circuito.

6.2.4.1. SEÑALES PARA EL BLOQUE DE MEMORIA

El bus de datos del puerto A, se dirigirá al bloque de memoria, y a través de él se transportarán los datos tanto de la memoria RAM (24 bits) como los de programa cargados en la memoria EPROM (Sólo los 8 bits de menor peso).


Página 78 de 156

Estas líneas pueden encontrarse en estado de alta impedancia, pero no es necesario conectar a ellas resistencias de pull-up o pull-down dado que, cuando va a efectuarse un acceso de lectura a memoria, el mismo chip de memoria fijará los niveles correspondientes a la señal del dato direccionado, mientras que si el acceso es de escritura, será el DSP quien fije estos valores.

Otro bus conectado al mismo bloque de memoria, será el bus de direcciones, que consta de 16 bits, y será utilizado para establecer la dirección de memoria donde se efectuará el acceso de lectura o escritura. En cuanto a este direccionamiento, intervendrán también otras señales, como se verá cuando se analice este bloque.

Por último, se dirigirán a este bloque de memoria aquellas señales de control del mismo puerto A, es decir, las señales WR, RD y X/Y.

En nuestro modo de utilización de la memoria, no serán utilizadas las señales DS y PS, que identifican si el acceso se está efectuando a zona de memoria de datos o de programa, y, debido a que tampoco existirá un dispositivo que se encargue de gestionar los buses a parte del propio DSP 56002, tampoco serán empleadas las señales dedicadas a esta tarea, tales como BN, BR, BG, BD y BW (en la primera parte del proyecto se explica su misión).

Estas líneas no conectadas, deberán dejarse desconectadas, o conectadas a alguna resistencia de pull-down o pull-up, tal como se muestra en la figura anterior, y se explicó durante la primera parte de este proyecto.

6.2.4.2. SEÑALES PARA EL BLOQUE DE INTERFAZ RS – 232

Al interfaz RS – 232 se conectará únicamente las líneas de transmisión y recepción de datos del puerto SCI del DSP (RXD y TXD), que permitirán establecer comunicación entre el DSP y el ordenador personal.

6.2.4.3. SEÑALES PARA EL BLOQUE DAC/ADC

Al bloque encargado de convertir las señales analógicas en digitales y viceversa, deberán conectarse básicamente las señales del puerto SSI, ya que el chip CS 4215 trabaja como un dispositivo serie síncrono. De esta forma, la conexión es como sigue:

- Las señales SRD y STD serán por las que se transfiera la información, vía serie, entre los dos dispositivos. A parte de señales de control, viajarán los valores digitales correspondientes a las muestras de la señal analógica, tanto las generadas por el DSP para ser transmitidas, como las obtenidas por este bloque para su recepción.


Página 79 de 156

- La señal SC1 será usada como pin de propósito general del DSP, y se empleará para resetear el chip CS 4215, del bloque ADC / DAC

- La señal SC2 será configurada con fines de sincronización. Cuando se activa esta señal, se indica el comienzo de una trama de datos.

- La señal SCK será usada como fuente de reloj en las transmisiones serie.

- La señal del pin PC2, se usará para indicar si la transferencia corresponde a datos o a señales de control.

A parte de las señales del puerto SSI, a este bloque se dirige otra señal que no pertenece directamente a este puerto. Ésta es la señal CKOUT, que proporcionará una señal de reloj al CODEC.

6.2.4.4. SEÑALES PARA EL BLOQUE TX/RX

Las señales que conectan al bloque del DSP con el bloque del interfaz RS –232, son únicamente dos, que se corresponden con la transmisión y la recepción de datos del puerto SCI (RXD y TXD)

6.2.4.5. SEÑALES DE ALIMENTACIÓN

Como se ha analizado anteriormente, el bloque de alimentación se encargará de generar todas las tensiones necesarias para el funcionamiento del circuito. De esta forma, habrá que enviar a este bloque los pines que, según fueron estudiados en la primera parte de este proyecto, precisan de una señal continua de alimentación.

6.2.5. MEMORIA

En este bloque se situará el circuito correspondiente a la memoria, tanto RAM como EPROM, que precisará el interfaz para trabajar correctamente. Los procesadores digitales de señal, ya disponen de puertos específicos para direccionar memoria, tanto de datos (RAM) como de programa (EPROM).

De esta forma, bastaría con dimensionar correctamente estos dos bloques de memoria, y cargar sobre la memoria EPROM (27C256) el software apropiado.


Página 80 de 156

Figura 41. Esquema del conexionado de la memoria

Como se ve en la figura, han sido dispuestos tres circuitos integrados de memoria RAM (circuito integrado 6206), conectados de tal manera que al acceder a una dirección de la misma, se obtiene una palabra de 24 bits de longitud, que es exactamente la longitud del bus de datos del DSP 56002.

En la figura puede verse el modo de direccionar que ha sido empleado para acceder a los datos presentes en memoria externa. Puesto que los chips escogidos disponen de 15 líneas para direcciones, y no 16 como el bus, se usa esta última línea para distinguir entre memoria de datos y memoria de programa, de tal forma que cuando la línea ADDR15 se encuentra habilitada, los chips correspondientes a memoria RAM son desactivados, y, si además se activa la señal de acceso a memoria X, se accederá a memoria EPROM de programa. La figura siguiente muestra como quedará entonces el mapa de memoria que verá el DSP:


Página 81 de 156

Figura 42. Mapa de memoria

6.2.5.1. CIRCUITOS INTEGRADOS 6206 Y 27C256

Estos son los circuitos integrados de memoria que se colocarán en el circuito. Sus características son las comunes para este tipo de integrados:

• CIRCUITO INTEGRADO 6206: Se trata de una memoria de tipo RAM estática, de 32 k* 8 bits, que dispone de las siguientes señales:

- 15 bits en el bus de direcciones.

- 8 bits en el bus de datos.

- Chip Enable (CE), que habilita o inhabilita el chip.

- Output Enable (OE), si este bit se activa, se obtendrá el dato seleccionado en el bus de datos, en caso contrario, este bus permanecerá en estado de alta impedancia (comportándose como entrada).

- Write (WR), habrá que seleccionar este pin para poder escribir un dato en la memoria.

• CIRCUITO INTEGRADO 27C256: Se trata de una memoria de tipo EPROM, de 32 k* 8 bits, que dispone de las siguientes señales:

- 15 bits en el bus de direcciones.

- 8 bits en el bus de datos.


Página 82 de 156

- Chip Enable (CE), que habilita o inhabilita el chip.

- Output Enable (OE), si este bit se activa, se obtendrá el dato seleccionado en el bus de datos, en caso contrario, este bus permanecerá en estado de alta impedancia.

- Señal de programación (VPP), habrá que introducir una tensión elevada sobre este pin para programar el chip.

6.2.6. DAC / ADC

Este bloque será el encargado de generar una señal analógica a partir de las muestras digitales que le serán entregadas por el DSP. También hará la tarea opuesta, es decir, muestreará la señal analógica recibida y entregará sus muestras al DSP en tramas digitales.

Su centro activo lo conforma el circuito integrado CS 4215, que se trata, como se vera más adelante, de un conversor de audio de 16 bits.

El circuito eléctrico de este bloque es el que se representa en la siguiente figura. Tras su observación, se analizara el funcionamiento:

Figura 43. Esquema eléctrico del bloque ADC / DAC


Página 83 de 156

El análisis del circuito no resulta conceptualmente difícil. En su parte analógica, se encontrara el circuito integrado MC 33078, que está formado por dos amplificadores operacionales con unas características de señal y ruido que los hacen ideales para este tipo de aplicación.

En la entrada de señal procedente del transceptor (línea LIN), ha sido empleado uno de estos amplificadores configurado de tal manera que proporciona un filtrado de la señal de entrada, permitiendo además aumentar la relación señal / ruido en la entrada al CODEC. El otro amplificador ha sido configurado para servir de amplificador de ganancia unidad en la salida del conversor. La red RC asociada a éste permite minimizar el efecto del muestreo, en la señal analógica de salida (LOUT).

El CS 4215 es estéreo, pero ha sido utilizado un solo canal (en este caso el izquierdo) para nuestra aplicación, ya que no se precisa el uso de dos canales. Para anular el canal sobrante, la entrada ha sido llevada a un condensador, que evitará el ingreso de ruido por ella, mientras que la salida no es conectada a ningún punto.

En lo que respecta a su control, este bloque está unido al DSP por las siguientes líneas:

- SRD: A través de esta línea, el CODEC enviará al DSP la trama de bits correspondiente al muestreo de la señal analógica de entrada. Serán tramas de forma sincronizada con el muestreo y digitalización de la señal. También le enviará datos de control que el DSP pueda solicitar del CODEC.

- STD: Esta línea cumple la función análoga a la anterior, pero en este caso el tráfico partirá del DSP y será entregado al CODEC. Al realizar los cálculos de modulación de la señal por el DSP, éste le mandará al CODEC la información digital correspondiente a las muestras de la señal analógica, para que éste la genere y la envíe a través de su salida.

- RST: Esta señal se corresponde con un pin del DSP que ha sido configurado como entrada / salida de propósito general. Permitirá, por software, hacer un RESET sobre el CODEC (obligado, por ejemplo, tras el reset del DSP).

- SYNC: Esta señal sirve para sincronizar las transmisiones de datos entre el DSP y el CODEC. Cuando esta señal se pone a nivel alto, y vuelve de nuevo a nivel bajo (flanco de bajada), comenzará la transmisión, bien de entrada o bien de salida, de datos desde o hacia el CODEC. De manera gráfica, en la siguiente figura se puede ver un cronograma de este protocolo.


Página 84 de 156

Figura 44. Sincronización de las comunicaciones DSP – CODEC

- SCK: Esta es la señal SCLK que aparece en la figura. Es una señal de reloj, generada por el DSP, que sincroniza la transmisión de bits entre ambos dispositivos.

- D/C: Mediante esta señal, el DSP indica al CODEC que el acceso es para transferir datos que deberán ser convertidos a una señal analógica o un acceso de control, para seleccionar el funcionamiento del CODEC.

- CKOUT: Señal de reloj que sincronizará generada por el DSP que sincronizará la velocidad del muestreo de los datos con las operaciones del DSP.

6.2.6.1. CIRCUITO INTEGRADO CS 4215

Como ya he dicho, el circuito integrado CS 4215 se trata de un conversor analógico / digital y digital / analógico (CODEC), que tiene las siguientes características:

- Permite muestrear señales a una frecuencia de hasta 50 KHz, lo que le permite ser capaz de capturar y generar señales para todo el espectro que el oído humano percibe.

- Soporta las codificaciones en ley A, ley µ, y lineales de 8 y 16 bits.

- Dispone de ganancia programable para las entradas analógicas.

- Dispone de atenuación programable para las salidas analógicas.

- Entradas preparadas para micrófono y línea.

- Salidas preparadas para auriculares, altavoces y línea.


Página 85 de 156

- Filtros Anti-Aliasing / Smoothing internos.

- Interface serie digital.

- Estéreo, es decir, dispone de dos canales para cada una de las entradas y salidas, y es capaz de procesar ambos canales con la misma calidad.

En la figura siguiente se puede ver la arquitectura interna de este chip. Realizando un pequeño análisis sobre la misma no es difícil conocer el funcionamiento del chip. En su parte analógica, la circuitería está duplicada, para soportar los dos canales, pero se va a ver el funcionamiento de tan sólo uno de ellos:

Las entradas de señal (LIN y MIN) son multiplexadas e introducidas en un bloque de control de ganancia. Una vez adecuada la señal al nivel programado, son digitalizadas, pasando por el bloque conversor analógico / digital. La salida, ya en formato digital, atraviesa un bloque de codificación, que permitirá (bajo programación) codificar las señales en formato Ley A o Ley µ. Una vez obtenida la trama final de bits, el bloque de entrada / salida serie será quien lo entregue al controlador a través del pin SDOUT.

La forma análoga de trabajar, sería como sigue: La trama de bits entregada por el controlador externo, es entregada al CODEC mediante el pin SDIN. Tras atravesar el decodificador Ley A o Ley µ (si ha sido codificada), la señal pasa por los conversores digital / analógico, y ya en formato analógico, es atenuada (según se programe), antes de ser entregada a las salidas MOUT (mediante un amplificador), LOUT y HEAD.

En el Anexo final de este libro se encuentran las hojas de características de este chip, donde hay más información al respecto


Página 86 de 156

Figura 45. Estructura interna del circuito integrado CS 4215

6.2.7. TX / RX

La función de este bloque es realizar, bajo la supervisión del DSP, la conmutación del modo de transmisión al de recepción o viceversa en el transceptor. Para su diseño, deberían ser estudiadas las señales que precisa el transceptor para realizar esta operación. En nuestro caso ha sido preparado para poder trabajar correctamente en los tres tipos de PTT (Push To Talk) más extendidos:

- El primero de estos modos se muestra en la figura que sigue. Estos transceptores disponen de una línea que, en condiciones de reposo, tiene una tensión aproximada de 12 voltios. Estando en estas condiciones (sin conectar), el transceptor se encuentra en modo de recepción, al cortocircuitar esta línea a masa, el transceptor entra en el modo de transmisión, modulando la señal en banda base que se introduzca por la línea de entrada de señal de audio.


Página 87 de 156

Figura 46. Conmutación TX / RX. Modo 1

- En el segundo de los modos, la diferencia radica con respecto al modo 1 en que en lugar de una sola línea de TX / RX, dispone de dos, siendo necesario cortocircuitar una de ellas para transmitir y otra para recibir. Si se cortocircuitaran las dos, los circuitos de transmisión y recepción estarían habilitados, pudiendo producir daños en el equipo. Si, por el contrario, permanecieran las dos en circuito abierto, ninguno de los circuitos estaría habilitado, permaneciendo el transceptor inactivo. En la siguiente figura se muestra este caso:



Página 88 de 156

- El Tercero de los modos consiste en detectar la impedancia presentada por la línea de entrada de señal de baja frecuencia. Si esta línea presenta alta impedancia, el transceptor se encontrará en modo de recepción y si, por el contrario, esta línea presenta baja impedancia, el transceptor pasará al modo de transmisión, modulando la señal que ingrese por la misma línea. La impedancia nominal que ha de presentar la línea es aproximadamente de 2000 ohmios, que es la habitual que presentan los micrófonos tipo “electrec”, que son los utilizados en este tipo de transceptores. La detección de esta baja impedancia se hace mediante la circulación de una corriente continua a través de la línea. Para evitar que esta corriente pueda afectar a la señal que se genera en la interfaz, se aislara en continua los dos circuitos mediante el empleo de un filtro formado por el condensador C1, de valor 100 nF. La figura siguiente representa el circuito:


Además de controlar el estado de transmisión o recepción del transceptor, este bloque realiza dos funciones más. Una de ellas es recibir o enviar la señal analógica desde o hacia el bloque ADC / DAC, y la otra será la de indicar al usuario el estado del transceptor, mediante dos diodos LED. Con todo esto, el esquema completo de este bloque es el representado en la figura siguiente:


Página 89 de 156

Figura 49. Esquema completo del bloque TX / RX

El funcionamiento de este circuito es muy sencillo y se va a efectuar su análisis para los dos modos de trabajo (recepción y transmisión).

6.2.7.1. RECEPCIÓN

Cuando la señal TX/RX se encuentra a nivel alto, se encenderá el diodo LED D1, indicando que el transceptor se encuentra en modo de recepción. El transistor Q2 pasará a conducción, con lo que la señal RX estará cortocircuitada, y el transceptor recibirá. La señal pasará entonces desde la salida de audio del transceptor hasta nuestro circuito a través del conector JACK P2, por la línea LIN, que irá hasta el bloque ADC. El diodo D2 y el transistor Q1 permanecerán inactivos, ya que la salida del inversor será de nivel bajo.

Para los diferentes tipos de transceptores, se actuará de esta manera:

- Modo 1: Puesto que no existe una señal concreta de recepción, el cable correspondiente a la señal RX del conector DB9 P1 deberá ser desconectado.

- Modo 2: En este caso, el cable deberá ser conectado, ya que es imprescindible para que el transceptor entre en modo de recepción.

- Modo 3: Al igual que en modo 1, el cable correspondiente a la señal RX del conector DB9 P1 deberá ser desconectado.


Página 90 de 156

6.2.7.2. TRANSMISIÓN

Se pasará al modo de transmisión cuando en la señal TX/RX se encuentre un nivel bajo. En este caso, el diodo D1 y el transistor Q2 se encontrarán inactivos, pero la salida del inversor 7404 U1A será de nivel alto. Esto provocará que el diodo D2 se ilumine, indicando la condición de transmisión, y que el transistor Q1 pase al modo de saturación, cortocircuitando la línea TX. En esta situación, la señal LOUT proveniente del bloque DAC será entregada al transceptor. Para los distintos modos de transceptores se actuara como sigue:

- Modo 1: Puesto que las señales de TX y la de audio se encuentran separadas, se pondra el JUMPER J1 entre los puntos 2 y 3, aislando ambos circuitos.

- Modo 2: Al igual que en el modo 1, se pondra el JUMPER J1 entre los puntos 2 y 3, aislando ambos circuitos.

- Modo 3: En este caso, la señal de audio y la de transmisión son la misma, con lo que se debera poner el JUMPER J1 entre los puntos 1 y 2, y se desconectara el cable TX que va al transceptor. De esta manera, se obtendra una línea que ofrecerá una impedancia aproximada de 2000 ohmios y la señal de BF.

6.2.8. TRANSCEPTOR

En este apartado voy a hacer una pequeña introducción de los transceptores que podrían ser utilizados para nuestra aplicación. La tarjeta ha sido preparada, como ya se ha visto, para ser empleada junto con un transceptor de los utilizados por los radioaficionados, pero en este punto cabría hacer una pequeña distinción entre ellos. De esta forma, voy a representar las características generales de cuatro de los tipos más empleados.

Cabe decir que el transceptor que se emplee en esta aplicación no es crítico, pero sí es importante la homogeneidad de características en los usados por todos los usuarios de la red local.

Es objeto de este apartado conocer las características que diferencian a este tipo de transceptores y evaluar cual es el idóneo en función de la aplicación que vaya a hacerse de nuestra red.

6.2.8.1. TIPOS DE TRANSCEPTORES COMERCIALES

Como ya he dicho, voy a hacer una pequeña distinción entre cuatro tipos de transceptores que se pueden encontrar en el mercado, haciendo en este punto una pequeña identificación de ellos para posteriormente analizar sus características.


Página 91 de 156

De esta forma, los cuatro tipos de transceptores que se pueden encontrar son:

- Transceptor HF.

- Transceptor CB.

- Transceptor VHF.

- Transceptor UHF.

6.2.8.2. CARACTERÍSTICAS GENERALES

Las características que diferencian a estos tipos de transceptores, son, en líneas generales, las siguientes:

• RANGO DE FRECUENCIAS: Es importante elegir una frecuencia para la comunicación que no se encuentre ocupada por otras transmisiones, a fin de evitar interferencias que empeorarían considerablemente el funcionamiento de nuestra red. El rango de frecuencias cubierto por cada tipo de equipo es el mostrado a continuación, pero cabe indicar que estos valores son únicamente los autorizados por la legislación, y que cabe la posibilidad de que determinados equipos permitan ser usados fuera del rango indicado.

TRANSCEPTOR HF

TRANSCEPTOR CB

TRANSCEPTOR VHF

TRANSCEPTOR UHF

RANGO DE FRECUENCIAS

3.50 – 3.80 MHz 7.00 – 7.10 MHz

10.10 – 10.15 MHz 14.00 – 14.35 MHz 18.06 – 18.16 MHz 21.00 – 21.45 MHz 24.89 – 24.99 MHz 28.00 – 29.70 MHz

26.96 – 27.41 MHz 144 – 146 MHz 430 – 440 MHz 1.24 – 1.30 GHz 2.30 – 2.45 GHz

Figura 50. Rangos de frecuencias de trabajo de los transceptores

• TIPO DE MODULACION: Los transceptores normalmente soportan distintos tipos de modulación de la señal, normalmente AM, FM y SSB. Algunos incorporan una función que suelen tratar como una forma de modulación, y es la denominada CW, que genera un tono como banda base cuando el equipo se encuentra en modo de transmisión. Es utilizado para comunicaciones en radiotelegrafía.


Página 92 de 156

TRANSCEPTOR HF

TRANSCEPTOR CB

TRANSCEPTOR VHF

TRANSCEPTOR UHF

TIPOS DE MODULACION AM, FM, SSB AM, FM, SSB FM FM

Figura 51. Tipos de modulación de los transceptores

• ANCHO DE BANDA POR CANAL: Normalmente, los canales de voz en todos los tipos de transceptores se encuentran limitados a unos 3 KHz, insuficientes para nuestra aplicación, que necesita un mínimo teórico de 4.8 KHz. No obstante, existen determinados tipos que ofrecen una entrada adicional preparada para datos con un ancho de banda superior (aproximadamente de 8 KHz). Para aquellos que no dispongan de esta interfaz, podrá modificarse las características de su hardware, obteniendo e insertando las señales antes de los filtros del modulador o demodulador. Los tipos de transceptores que pueden llevar este tipo de interfaz son los HF, UHF, y VHF.

• POTENCIA DE TRANSMISIÓN: Este parámetro es importante si las estaciones van a encontrarse en lugares geográficamente distantes. Evidentemente, a mayor potencia de transmisión, la relación señal/ruido también aumentará y con ello la calidad de la comunicación.

TRANSCEPTOR HF

TRANSCEPTOR CB

TRANSCEPTOR VHF

TRANSCEPTOR UHF

POTENCIA AUTORIZADA

MÁXIMA 200 4 50 30

Figura 52. Potencia de transmisión máxima para los transceptores

• INTERFACES EXTERNOS: Básicamente, se necesitara de una salida de audio con la señal recibida, en banda base, que la inmensa mayoría de los transceptores incorporan. Se precisara también de una entrada de baja frecuencia, y alguna forma (de entre las estudiadas anteriormente) de forzar el modo de transmisión o recepción. Adicionalmente, se podra disponer también de una entrada para datos, con ancho de banda mayor, que evitará modificar el hardware del transceptor. Como he dicho, esta última la incorporan algunos transceptores de los tipos HF, VHF, y UHF.


Página 93 de 156

• ANTENA: La antena es un punto importante a la hora de decidirnos por uno u otro transceptor, dependiendo también de la aplicación que vaya a hacerse de la red. Por ejemplo, si se quiere que en una misma sala o edificio convivan varias estaciones, se debera elegir un transceptor que permita ser conectado a una antena muy pequeña, para que cada estación pueda tener la suya propia, mientras que si las estaciones van a encontrarse alejadas, podrá instalarse una antena mayor en la azotea del edificio, por ejemplo. El tamaño de la antena dependerá, entre otras cosas, de la frecuencia del transceptor elegido. En general, deberá instalarse una gran antena en el edificio para los transceptores de más baja frecuencia (HF y CB), y bastará con una de dimensiones reducidas para los de alta frecuencia (VHF y UHF).

• CONSUMO: Si bien es cierto que algunos transceptores disponen de una fuente de alimentación incorporada, la mayoría son alimentados a 12 voltios de corriente continua, y además su consumo suele ser elevado (aunque depende de la potencia de transmisión).

• REGLAMENTACION: Existe una reglamentación que regula el uso de estos transceptores, y que limita la potencia, frecuencia, tipo de modulación y tipo de información que puede ser transmitida. Además es necesario disponer de una licencia otorgada por la entidad competente, y que varía en función del tipo de transceptor a utilizar. Existen cuatro tipos de licencias:

- ECB: Estación de banda ciudadana. Permite usar únicamente los equipos CB.

- EC: Estación clase C. Permite el uso de equipos HF con determinadas limitaciones.

- EB: Estación clase B. Permite el uso de equipos VHF y UHF.

- EA: Estación clase A. Permite usar todos los equipos excepto CB. Es el menos restringido en cuanto a potencias, frecuencias y modos de trabajo.

• PRECIO: El coste de estos transceptores puede oscilar entre 10.000 pesetas hasta 500.000 pesetas. Este amplio margen hace obligatorio el estudio de este parámetro. Los equipos de menor coste son, con mucha diferencia, los de tipo CB, mientras que los de mayor coste son los HF y los UHF.

6.2.8.3. CONCLUSIONES

Como he dicho anteriormente, la limitación que supone el coste de estos equipos obliga a descartar el uso de los equipos HF y UHF. Por otro lado, la legislación vigente prohibe el uso de equipos CB para la transmisión de datos, con lo que se esta obligado a utilizar un equipo de tipo VHF. Seguidamente, se volvera a analizar el resto de las condiciones:


Página 94 de 156

- Rango de frecuencias: De entre las posibles, la legislación limita la transmisión de datos al rango de 144 a 146 MHz.

- Tipo de modulación: Este tipo de equipos habitualmente sólo permiten la modulación en FM. Lo cual es una ventaja en nuestro caso, ya que en FM se obtiene una estabilidad mayor, al no existir variaciones en la potencia de transmisión, como sucede en las modulaciones en amplitud. Por otra parte, el ruido es menor.

- Ancho de banda: Habitualmente, el ancho de banda es de 3 KHz, pero algunos de estos dispositivos incorporan una interfaz de entrada que permite establecer comunicaciones con un ancho de banda de unos 8 KHz por canal.

- Potencia de transmisión: La legislación autoriza un máximo de 50 W lo cual es más que suficiente para un amplio radio de cobertura (de varias decenas de kilómetros). En un caso real, será conveniente (por motivos de consumo e interferencias) el reducir esta potencia.

- Interfaces externos: Todos estos equipos incorporan un conector tipo JACK para la salida de la señal recibida en banda base, y su conmutación a modo de transmisión suele ser el Modo 3, soportado por nuestra tarjeta.

- Antena: La antena puede ser de tipo base, para ser instalada en una azotea, y de aproximadamente 1.5 metros de longitud (si el radio de cobertura debe ser amplio), y puede también ser una antena de tipo portátil no superior a 10 cm. para su uso interno en un edificio.

- Consumo: El consumo de estos equipos suele ser aproximadamente de entre 50 y 150 W en modo transmisión (en función de la potencia) y menos de 10 W en modo recepción.

- Reglamentación: Todas las estaciones (usuarios) deberán estar provistas de una licencia tipo B otorgada por la entidad correspondiente (Ministerio de Fomento en la fecha de redacción de este proyecto).

- Precio: El coste de este tipo de equipos oscila, en la fecha de redacción, entre las 40.000 pesetas y las 200.000 pesetas, aproximadamente.

6.3. SOFTWARE A EJECUTAR POR EL DSP

En el circuito presentado, el DSP tendrá que ejecutar las funciones que corresponden al nivel físico de la red, ya que, como se ha visto anteriormente, las funciones de los niveles de enlace y de red son ejecutados por el PC.


Página 95 de 156

Dentro de este nivel físico, se puede distinguir dos grupos de funciones, las que operan directamente sobre la señal, ya sea analógica o digital, de los datos a transferir (modulación, demodulación, protocolo de comunicación con el PC, etc.) y las que atañen al propio hardware del sistema (gestión de memoria, del CODEC CS 4215, del transceptor, de interrupciones, etc.)

6.3.1. FUNCIONES SOBRE LA SEÑAL A TRANSFERIR

En este punto voy a comentar las funciones que debe realizar el DSP en cuanto al tratamiento de la señal se refiere. En el organigrama de más adelante, serán incluidas en el proceso general.

6.3.1.1. EN TRANSMISIÓN

6.3.1.1.1. RECEPCIÓN DE DATOS DEL PC

El PC enviará, a través del puerto serie RS-232 las tramas de datos, empaquetadas sobre el protocolo RPP. Estas tramas serán las que se deban entregar, sin modificación alguna, a los demás PC's de la red. Al recibir estos datos la interfaz serie (puerto SCI) del DSP, se generará una interrupción que almacenará el byte recibido en un búffer circular. El diagrama correspondiente a esta porción del código se muestra en la siguiente figura:

INICIO

ALMACENAR BYTERECIBIDO EN

BUFFER

FIN

Figura 53. Interrupción SCI_RX

6.3.1.1.2. MODULACIÓN DE LA SEÑAL

Para realizar la modulación de la señal de bits que se ha almacenado, se seguira el esquema general de un modulador QAM, donde se incluirán los bloques que aparecen en la figura siguiente y que se pasara a comentar a continuación:


Página 96 de 156

Figura 54. Modulación QAM

Dentro de este bloque se incluyen, como se ve en la figura:

• Codificador Bit/Símbolo: En 16 QAM, como ya se ha explicado, se transfieren los datos “empaquetados” de cuatro en cuatro bits. Puesto que la velocidad de nuestro sistema es de 9.600 bits por segundo, se transmitirán cuatro bits por símbolo y 2.400 símbolos por segundo. Este bloque será el encargado de leer del búffer circular que nos escribe el PC, bloques de cuatro bits, que serán convertidos en dos funciones, I y Q. I será la función que se module en PAM con el seno, mientras que Q será la modulada por la señal coseno. Estas dos funciones, serán el resultado de una conversión 1B2Q, y se corresponderán a cuatro niveles de tensión distintos, en función de los bits de entrada. De esta forma, se obtendran los niveles que se relacionan en la siguiente tabla:


Página 97 de 156

SEÑAL DE ENTRADA FUNCIÓN I FUNCION Q

0000 -3 -3

0001 -1 -3

0010 +1 -3

0011 +3 -3

0100 -3 -1

0101 -1 -1

0110 +1 -1

0111 +3 -1

1000 -3 +1

1001 -1 +1

1010 +1 +1

1011 +3 +1

1100 -3 +3

1101 -1 +3

1110 +1 +3

1111 +3 +3

Figura 55. Funciones I y Q

Al efectuar la operación anterior, nos encontramos con dos funciones que, a una velocidad de 2.400 símbolos por segundo, modificarán su valor discreto de entre cuatro posibles valores, de manera que con cada uno de estos símbolos se pueden distinguir dos bytes.

Hay que tener en cuenta que las velocidad de la información se ha visto decrementada, es decir, los 9.600 bps iniciales, se convirtieron en 4.800 bps para cada señal I y Q, que, al ser codificada en 2B1Q, se convirtieron en 2.400 símbolos por segundo.

• Filtro Paso Bajo: El siguiente paso es filtrar esta señal con un filtro paso bajo, de frecuencia de corte igual a la permitida por el transceptor. En nuestro caso, se podrá fijar este valor entre a un mínimo de 4.800 Hz y un máximo de 8.000 Hz. Para nuestar aplicación, 7.200 Hz serán adecuados.


Página 98 de 156

• Oscilador cuadrático: El DSP dispone ya de tablas pregrabadas que se corresponden con las muestras de un seno y un coseno. Se usaran estas muestras para multiplicar la señal de salida del filtro, a una velocidad de muestreo mínima de 9.600 Hz.

• Sumador: Una vez moduladas las dos señales, se sumaran muestra a muestra, obteniendo directamente la señal a transmitir.

El programa cargado en el DSP para esta función, responderá al siguiente diagrama:

INICIO

RECOGER BYTEDE BUFFER

COGER 2 BITS

MUESTREAR

FILTRO PASOBAJO

MODULAR CONCOSENO

ALMACENAR EN"A"

COGER 2 BITSSIGUIENTES

MUESTREAR

FILTRO PASOBAJO

MODULAR CONSENO

ALMACENAR EN"B"

SUMAR A+B

SSI_TX


MUESTREAR

FILTRO PASOBAJO

MODULAR CONCOSENO

ALMACENAR EN"A"


MUESTREAR

FILTRO PASOBAJO

MODULAR CONSENO

ALMACENAR EN"B"

SUMAR A+B

Figura 56. Modulación


Página 99 de 156

6.3.1.1.3. ENTREGA AL CS 4215

En este punto únicamente se indicara al CODEC el inicio de una trama de señal, y se comenzara a darle los valores obtenidos en el apartado anterior mediante el puerto SSI. Éste comenzará la conversión digital/analógica, que será la que se transmita. La entrega de los datos al CODEC se efectuará mediante una interrupción del puerto SSI, una vez configuradas éstas durante el proceso de inicialización. EL siguiente diagrama muestra este proceso:

INICIO

DATOS PARATX

CONMUTARTRANSCEPTOR RX

BLOQUEARINTERRUPCIÓN

SSI_TX

ACTIVARINTERRUPCIÓN

SSI_RX

ENTREGAR BYTE

Sí

No

FIN

Figura 57. Interrupción SSI_TX

6.3.1.2. EN RECEPCIÓN

6.3.1.2.1. RECEPCIÓN DE DATOS DESDE EL CODEC

La recepción de la señal es análoga a la transmisión. En este caso, será el CODEC el encargado de recoger del transceptor la señal analógica, y entregársela al DSP mediante el puerto SSI. Las interrupciones de éste puerto indicarán al DSP el inicio de una trama de información. El diagrama que se corresponde con el código que el DSP ejecutará al entrar en estas interrupciones se muestra en el diagrama siguiente:


Página 100 de 156

INICIO

ALMACENAR BYTEEN BUFFER

FIN

Figura 58. Interrupción SSI_RX

6.3.1.2.2. DEMODULACIÓN DE LA SEÑAL

El esquema general de un demodulador QAM es el mostrado en la figura siguiente:

Figura 59. Demodulador QAM

Las funciones serán, entonces, las que se comentan en los siguientes apartados:

• CONVERTIDOR ANALÓGICO DIGITAL: Al recibir el DSP las tramas de datos correspondientes a la digitalización de la señal, irá almacenando los valores en un búffer circular, de donde leerán las funciones del demodulador propiamente dicho.

• OSCILADOR CUADRÁTICO: El DSP dispone ya de tablas pregrabadas que se corresponden con las muestras de un seno y un coseno. Se usaran estas muestras para multiplicar la señal de salida del filtro, a una velocidad de muestreo mínima de 9.600 Hz. La función puede ser la misma que la utilizada en el modulador.


Página 101 de 156

• MULTIPLICADOR: Se multiplicaran las señales seno y coseno que han sido generadas en la función anterior con la señal de entrada, obteniendo de esta forma dos señales análogas que serán tratadas por el ecualizador.

• ECUALIZADOR TRANSVERSAL – LINEAL: El objetivo de este ecualizador es obtener, gracias a la señal que se le ha introducido, los valores de la señal que fue modulada por el seno y por el coseno, en amplitud y fase.

• DETECTOR DE SÍMBOLO: Este bloque analizará la respuesta obtenida por el ecualizador, y obtendrá dos bits correspondientes a la señal I y otro dos bits correspondientes a la señal Q.

• DECODIFICADOR BIT/SÍMBOLO: Este bloque únicamente volverá a reunir los dos bloques de dos bits que ha recibido en uno de cuatro bits, que se corresponde con el símbolo que fue transmitido.

Estos pasos se ejecutarán en el DSP de la forma que se indica en el siguiente diagrama de flujo:


Página 102 de 156

INICIO

RECOGER BYTEDE BUFFER

> 8DATOS

MULTIPLICAR PORCOSENO

ALMACENAR EN "A"

MULTIPLICAR PORSENO

ALMACENAR EN "B"

APLICARECUALIZADOR A

"A" Y "B"

DETECTARSÍMBOLO

COGER 4MUESTRAS

MULTIPLICAR PORCOSENO

ALMACENAR EN "A"

MULTIPLICAR PORSENO

ALMACENAR EN "B"

APLICARECUALIZADOR A

"A" Y "B"

DETECTARSÍMBOLO

COGER 4MUESTRAS

Sí

COMBINARSÍMBOLOS

ALMACENAR BYTE

FIN

No

Figura 60. Demodulación


Página 103 de 156

6.3.1.2.3. ENTREGA AL PC DE LOS BYTES RECIBIDOS

Una vez obtenidos estos símbolos, el DSP los almacenará en una memoria hasta que haya sido recibido al menos un byte completo (sólo dos símbolos), y se los entregará al PC, a través del puerto de comunicaciones serie SCI. Cuando el DSP entre en estas interrupciones, ejecutará un código que responderá al siguiente diagrama:

INICIO

DATOS PARATX

BLOQUEARINTERRUPCIÓN

SCI_TX

ACTIVARINTERRUPCIÓN

SCI_RX

ENTREGAR BYTE

Sí

No

FIN

Figura 61. Interrupción SCI_TX

6.3.2. FUNCIONES SOBRE EL HARDWARE DEL SISTEMA

A parte de las funciones que se han visto, que tratan únicamente a las señales a transmitir y a recibir, existen otras muchas funciones que son necesarias para que el hardware trabaje correctamente.

En los siguientes apartados haré una introducción a este tipo de funciones:

6.3.2.1. GESTIÓN DEL PROPIO DSP

Estas funciones configurarán y gestionarán los distintos dispositivos con los que cuenta el DSP 56002, tales como memoria, puertos e interfaces, interrupciones, etc.

6.3.2.1.1. CARGA DE SOFTWARE

Para cargar el software del que se está presentando, el DSP tiene varias alternativas. En este apartado se van a comentar brevemente y se optara por una de ellas, que será la que se empleará.


Página 104 de 156

El DSP lleva pregrabado de fábrica un pequeño software que, en función del estado de los pines MODA, MODB y MODC, actuará de una u otra manera para completar la secuencia de arranque del DSP. Esto ya fue explicado en la primera parte de este proyecto, pero se va a resumirlo en la siguiente tabla:

Figura 62. Modos de inicialización del DSP 56002

A continuación se vera brevemente las características de cada uno de los modos, de donde se obtendra suficiente información para decidirnos por una de ellas:

- Modo 0: En este caso, el DSP únicamente trabajaría con la memoria interna que posee, pero es de un tamaño demasiado reducido como para albergar en ella nuestro programa.

- Modo 1: En este modo de trabajo, el DSP cargará en memoria RAM interna el programa grabado en una EPROM, pero continuaría trabajando en modo 0, con lo que nuestro software no podría ser cargado por completo.

- Modo 2: Es el modo elegido para nuestra aplicación. El DSP cargará de la dirección E000h un paquete de 512 bytes, que constituirían el programa. Sigue siendo una cantidad de memoria muy inferior a la necesitada, con lo que la solución ha sido colocar, en estos 512 bytes de programa, otro cargador que cargue el programa completo en memoria RAM, y luego pase a ejecutarlo. Hay que tener en cuenta que nuestra memoria EPROM va entre las direcciones 8000h y la EFFFh, con lo que el programa debe ser truncado a la hora de grabar la memoria EPROM, para dar cabida a este otro.

- Modo 3: Es usado únicamente para tareas de depuración de código y desarrollo, por lo que no es válido en nuestro caso.

- Modo 5: El arranque es desde un dispositivo HOST, pero en nuestra tarjeta no existe tal dispositivo maestro.


Página 105 de 156

- Modo 6: En este modo la carga se realiza desde el puerto SCI. Esto sería posible en nuestro caso, salvo por que la fuente de reloj durante la transferencia debe ser externo y, por sencillez, no ha sido implementada esta característica. En una configuración típica del DSP, se incluye un controlador OnCE, con el que este desarrollo es posible.

6.3.2.1.2. PUERTO SCI

A través de este puerto, como ya se ha dicho en anteriores ocasiones, se mantendrá la comunicación con el PC. Al tratarse de una comunicación serie asíncrona, y estar la UART integrada en el DSP preparada para este tipo de protocolo, bastará con configurar, durante el proceso de inicialización del sistema, la velocidad (9.600 bps), bits de inicio (1), bits de parada (1) y bits de datos (8).

Una vez inicializado, se configurarán las interrupciones de tal forma que se produzca una cada vez que llega un byte nuevo al puerto, para pasar a ser procesado.

Para transmitir, se colocará el primer byte en el registro correspondiente, se bloquearán las interrupciones de recepción y se activarán las de transmisión. De esta forma, una vez haya sido enviado el primer byte, se producirá una interrupción, en la que se colocara el segundo byte en el registro correspondiente, y así sucesivamente. Al finalizar el último byte, cuando se produzca la interrupción, se bloquearan las de transmisión y se volveran a activar las de recepción.

6.3.2.1.3. PUERTO SSI

Mediante este puerto se mantendrá una comunicación serie síncrona con el CODEC, es decir, se mandaran las muestras correspondientes a la señal modulada y se obtendrán las muestras de la señal recibida, para pasar a su demodulación.

Por las características de la comunicación, únicamente habrá que configurar la velocidad, que será la velocidad de muestreo que se haya fijado (mínimo 9.600 KHz) multiplicada por 8 bits por muestra.

6.3.2.1.4. PUERTO H

Este puerto no se utiliza como tal, ya que no existe en nuestro sistema un procesador principal que controle al DSP. De él se usaran los pines como salidas de propósito general, de tal forma que tan sólo se tendra que utilizar uno de ellos, que será con el que se colocara al transceptor en modo de recepción o en modo de transmisión.

Este mismo pin servirá para activar o desactivar los dos diodos LED's que nos indicarán el estado de la interfaz (TX o RX).


Página 106 de 156

6.3.2.1.5. CIRCUITO DE RELOJ

Sobre este circuito no habrá que hacer ninguna operación salvo durante la inicialización del DSP, en el que se fijara la frecuencia de trabajo del mismo.

Puesto que el reloj externo que va a ser implementado será de 4 MHz, habrá que configurar el PLL para que la frecuencia del trabajo del DSP sea de 40 MHz, que es el máximo soportado. Para ello, bastará con fijar a 10 este valor e inicializar tanto el PLL como el circuito divisor de frecuencia.

6.3.2.1.6. INTERRUPCIONES

Existirán tres interrupciones que van a gestionar gran parte del software. De dos de ellas ya se ha hablado, y son las interrupciones de los puertos SCI y SSI. La tercera es una interrupción temporal, que interrumpirá al software cada 50 milisegundos, y que marcará los tiempos de espera de transmisión, los retardos del transceptor, los "watchdog" en transmisión y recepción de datos, etc.

Esta tercera interrupción será habilitada durante el proceso de inicialización del DSP, y no tendrá que volver a configurarse. Las distintas funciones, se basarán en contadores propietarios que se incrementan o se decrementan en esta interrupción, y que gestionarán únicamente las funciones afectadas.

El código que se ejecutará dentro de esta interrupción temporal es muy sencillo, y responderá al diagrama de la figura:

INICIO

INCREMENTAR ODECREMENTAR

VARIABLES

OVERLOAD

FIJAR NUEVOVALOR

FIN

Sí

No

Figura 63. Interrupción temporal


Página 107 de 156

6.3.3. ORGANIGRAMA COMPLETO DEL SOFTWARE

En la siguiente figura, se muestra el organigrama completo de realización de cada una de las funciones explicadas anteriormente. En ella, aparecen, por sencillez de representación, algunas etiquetas que no tienen una posición determinada dentro del organigrama, sino que se producen mediante interrupciones. De esta forma, se han identificado las siguientes funciones:

- Interrupción SCI_TX.

- Interrupción SCI_RX.

- Interrupción SSI_TX.

- Interrupción SSI_RX.

- Modulación.

- Demodulación.

- Interrupción temporal.

Que han sido mostradas durante los apartados anteriores.


Página 108 de 156

CARGA DESOFTWARE

(MODO 2)

INICIOINICIALIZACIÓN

RELOJ

INICIALIZACIÓNPUERTO SCI

INICIALIZACIÓNPUERTO SSI

INICIALIZACIÓNPUERTOH

INICIALIZACIÓNINTERRUPCIÓN

TEMPORAL

INICIO

DATOS DELCODEC

GUARDAR DATOSDEMODULADOS

ELIMINARMUESTRAS

TX_SCIRX_SCI

TX_SSIRX_SSI

INTERRUPCIÓNTEMPORAL

DEMODULAR

PAQUETERX

No

Sí

ENTREGA AL PC

Sí

DATOSTX

No

INTERRUPCIÓNTX_SCI

CONMUTARTRANSCEPTOR TX

Sí

MODULAR

ENTREGAR ALCODEC

INTERRUPCIÓNTX_SSI

No

Figura 64. Software cargado en el DSP


Página 109 de 156

7. MANUAL DE USUARIO

En este apartado se desarrolla el manual de uso de la interfaz presentada en este proyecto, tanto a nivel hardware como de instalación, uso y mantenimiento.

7.1. IDENTIFICACIÓN DE LA INTERFAZ

La interfaz, en su presentación final, presentará el aspecto que se muestra en las siguientes figuras:

Figura 65. Vista frontal de la interfaz


Página 110 de 156

Figura 66. Vista trasera de la interfaz

1- Conmutador ON / OFF: Permite apagar el interfaz cuando no se desee estar conectado a la red. La interfaz del equipo que sirva de gateway de la red debería encontrarse siempre en la posición “ON”.

2- LED Power ON: Indicador tipo LED de color rojo, que indica que la interfaz se encuentra conectada a una fuente de suministro de corriente y conectada.

3- LED TX: Indicador tipo LED de color rojo, que indica que la interfaz se encuentra transmitiendo datos a la red. Cuando este indicador se encuentra encendido, el transceptor se encontrará también en modo de transmisión.

4- LED RX: Indicador tipo LED de color verde, que indica que la interfaz, y por lo tanto el transceptor, se encuentran en modo de recepción. En este modo, la interfaz puede estar encontrándose recibiendo datos o tan sólo a la espera de los mismos. La función es realmente la inversa que el indicador LED TX.

5- Patas de goma: Para albergar en modo sobremesa a la interfaz.

6- SIGNAL IN: Conector tipo JACK, que conectará a la interfaz con la salida de audio del transceptor, a fin de poder analizar la señal proveniente de la red.

7- TRANSCEPTOR: Conector tipo DB-9 en el que se conectará el cable especial, provisto con la interfaz, para la conexión de las líneas de control y señal de audio al transceptor.


Página 111 de 156

8- SERIAL LINE: Conector tipo DB-9, que cumple con el estándar de conexionado del protocolo RS – 232, y que se conectará con un cable al puerto serie COM1 o COM2 del PC.

9- POWER SUPPLY: Conector tipo BNC que servirá para suministrar de corriente a la interfaz. Esta alimentación debe ser de 12 voltios de corriente continua, siendo el terminal positivo el interior del conector y el negativo el exterior.

7.2. INSTALACIÓN DEL HARDWARE

La instalación de la interfaz es muy sencilla. Únicamente deberán conectarse el PC, la interfaz, el transceptor y la fuente de alimentación tal y como se muestra en la figura, y con los cables que se proporcionan.

IBM Compatible

12 V DCTRANSCEPTOR

A LA ANTENA

A LA RED ELÉCTRICA220 v AC

CABLE RS - 232

CABLE BANANA - BNC

CABLE DB9 - CONECTORTRANSCEPTOR

CABLE JACK - JACK

Figura 67. Instalación hardware de la interfaz

Como se ve en la figura, se deberán efectuar las siguientes conexiones:

1- Conectar el cable JACK – JACK desde el conector de salida de audio del transceptor hasta el conector SIGNAL IN de la interfaz.

2- Conectar el cable especial DB-9 desde la tioma de control / entrada de audio del transceptor hasta el conector TRANSCEPTOR de la interfaz.


Página 112 de 156

3- Conectar el cable estándar RS – 232 desde un puerto serie del PC (puede ser COM1 o COM2) hasta el conector SERIAL LINE de la interfaz. Si el puerto del PC es del tipo DB25, puede intercalarse un adaptador DB9 – DB25.

4- Conectar en el transceptor la toma de antena en el conector provisto para ello. Este cable es de tipo coaxial.

5- Conectar la fuente de alimentación tanto a la interfaz como al transceptor, y conectar ésta a una toma de corriente alterna de 220 V AC.

7.3. INSTALACIÓN DEL SOFTWARE Y CONFIGURACIÓN

A la hora de configurar nuestro sistema para poder trabajar en la red propuesta, se deberan seguir los pasos que se indican a continuación:

- Inclusión del dispositivo en el núcleo de LINUX.

- Configuración de las propiedades de red.

- Configuración de las aplicaciones.

7.3.1. INCLUSIÓN DEL DISPOSITIVO EN EL NÚCLEO DE LI NUX

Los pasos a seguir para incluir a nuestro dispositivo como si fuera parte del sistema operativo son los que a continuación se detallan:

- Copiar en el directorio /usr/src/linux/drivers/net el archivo rpp.c (suministrado con el diskette de instalación), mediante los siguientes comando:

� mount -t msdos /dev/fd0 /mnt

En el caso de un host normal:

� cp rpp.c /usr/src/linux/drivers/net

En el caso del gateway:

� cp rppg.c /usr/src/linux/drivers/net/rpp.c

- Incluir en el archivo /usr/src/linux/drivers/net/Makefile las líneas siguientes:

Ifeq ($(CONFIG_RPP),y) L_OBJS += rpp.o Endif rpp.o:rpp.c


Página 113 de 156

- Incluir en el arrchivo /usr/src/linux/drivers/net/Config.in las líneas siguientes:

Bool 'Radio Packet Protocol' CONFIG_NET_RPP if [ "$CONFIG_NET_RPP" = "y" ]; then tristate 'RPP support' CONFIG_RPP fi

- Incluir en el archivo /usr/src/linux/drivers/net/Space.c las líneas siguientes:

#ifdef CONFIG_RPP extern int rpp_init(struct device *dev); static struct device rpp_dev = { "rpp0", 0x0, /* recv Fin memoria */ 0x0, /* recv Inicio memoria */ 0x0, /* Fin memoria */ 0x0, /* Inicio memoria */ 0x0, /* direccion I/O base */ 0, /* IRQ */ 0,0,0, /* flags */ NEXT_DEV, /* Siguiente dispositivo */ rpp_init /* Puntero a la funcion init */ };

#undef NEXT_DEV #define NEXT_DEV (&rpp_dev) #endif

- Arrancar el programa de configuración disponible en el Sistema Operativo. El nombre de éste puede variar en función de la distribución de Linux, pero habitualmente se llama "config". Dentro de él, habrá que seleccionar las opciones habituales de soporte de redes IP, y estas dos opciones nuevas que aparecerán:

[X] Radio Packet Protocol

[X] RPP support

- Compilar el núcleo con la siguiente secuencia de comandos:


Página 114 de 156

� cd /usr/src/linux

� make dep

� make clean

� make zImage

- Reiniciar el sistema con el nuevo núcleo instalado.

7.3.2. CONFIGURACIÓN DE LAS PROPIEDADES DE RED

Para poder utilizar nuestro driver y que los datos de red se transmitan a traves de este, hay que configurar las propiedades de red del sistema, de tal forma que sepa en que red se encuentra. Estos son los pasos que hay que seguir:

- Ejecutar el comando ifconfig. Aquí se le indica que dirección IP tiene el dispositivo, y cual es el gateway de la red, si este existe.

� ifconfig rpp0 10.21.211.2 netmask 255.255.255.0

- Añadir a la tabla de rutas, la red en la que se encuentra el dispositivo, mediante la orden route

� route add –net 10.21.211.0 netmask 255.255.255.0 rpp0

- En el caso de que el ordenador donde se este instalando el driver, fuera el gateway de la red, se deberia de ejecutar un ultimo comando. Este sirve, para indicar que los paquetes que le lleguen a traves de cualquier red, y vayan dirigidas hacia otra de ellas, sean retransmitidos. Para esto se utiliza el comando echo, con el que se escribe el valor 1 en un archivo del directorio /proc

echo “1” /proc/net/ip_forward

Si se quisiera para el driver momentaneamente, por cualquier razon, se deberia ejecutar los comandos siguientes:

� ifconfig rpp0 down

Cuando se quiera volver a poner en funcionamiento:

� ifconfig rpp0 up

7.3.3. CONFIGURACIÓN DE LAS APLICACIONES

Uno de los pasos a seguir consiste en dar nombre a las maquinas, e indicar que dirección IP tienen. Esto se realiza en el archivo hosts, que se encuentra en el directorio /etc.


Página 115 de 156

Cualquier linea que se añada en este archivo, debe de tener el siguiente formato:

� Dirección IP Nombre_Maquina

� Ejemplo: 10.21.211.2 Nombre_Maquina

El resto de las aplicaciones tales como los clientes FTP, HTTP y TELNET, deberan ser configuradas como indiquen los manuales de usuario propios de estas, ya que pueden variar bastante entre fabricantes, e incluso entre versiones.

7.4. APLICACIONES SOPORTADAS

Mediante esta interfaz se pueden transferir datos utilizando cualquier protocolo de la pila IP, ya sea el transporte efectuado sobre TCP como sobre UDP. Esto engloba a la inmensa mayoría de aplicaciones que circulan por las redes de área local e Internet, tales como FTP, TELNET, HTTP, PING, etc.

Soporta, asimismo, los protocolos de ruteado de IP, como EIGRP, RIP, BGP,...

A esta pila de protocolos, hay que eliminar el protocolo ARP, ya que, al no trabajar con direccionamiento IP, no puede ser transferido. Este hecho hace que tampoco se soporte el protocolo DHCP, cuyas solicitudes son mediante ARP, por lo que el direccionamiento de nuestra red deberá ser de tipo estático.

De entre las aplicaciones soportadas, habrá que tener en cuenta que, cuando el nivel de aplicación se trate de información que precisen gran cantidad de ancho de banda, el resultado puede no ser el adecuado, dada la reducida velocidad de la red.

7.5. ALCANCE DE LA RED LOCAL

El alcance, o distancia a la que pueden estar separadas las estaciones de la red, depende únicamente del equipo transceptor, antena y potencia que se esté usando. De esta forma, podrían encontrarse dos estaciones separadas tan sólo por unos metros como por varios miles de kilómetros. El único punto importante es que todas las estaciones deben estar situadas o estructuradas de forma que entre todas ellas exista plena comunicación, es decir, cada una de las estaciones debe ser capaz de recibir a todas las demás.


Página 116 de 156

8. PRESUPUESTO

El presupuesto de este proyecto se ha estructurado en dos partes, a saber: una primera en la que se calculan los costes derivados del personal que ha intervenido en la elaboración del proyecto, y una segunda en la que se calculan los costes del material utilizado.

Los costes de personal han sido calculados a partir de las horas invertidas en las distintas tareas que forman el desarrollo del proyecto, imputando a estas horas un coste sobre la base del salario medio del personal involucrado.

Por su parte los costes de material se han imputado directamente al coste total del proyecto, incluyendo en éstos tanto los costes de materiales para el desarrollo de las interfaces como el material informático necesario.

8.1. COSTES DE PERSONAL

Este proyecto ha sido elaborado por las siguientes personas:

• Un Ingeniero de Telecomunicaciones responsable de: Diseño de los objetivos, planificación del desarrollo del proyecto, análisis económico y elaboración de la memoria.

• Un Ingeniero Técnico de Telecomunicaciones responsable de: Diseño y desarrollo de la interfaz, programación tanto del DSP como del dispositivo de LINUX y tren de pruebas

• Un Auxiliar Administrativo responsable de: mecanografiado del texto, edición de las figuras y la composición de los documentos finales.

8.1.1. COSTES UNITARIOS

Se fijara aquí el coste de un día de trabajo de los profesionales anteriores. Para ello se partira de las siguientes hipótesis:

CUALIFICACIÓN SALARIO BRUTO ANUAL (Ptas.)

Ingeniero de Telecomunicaciones 6.000.000

Ingeniero Técnico de Telecomunicaciones 4.000.000

Auxiliar administrativo 2.000.000

Figura 68. Hipótesis para el cálculo de los costes unitarios

Además se supondra que el año laboral consta de 12 meses con 22 días laborables cada uno, lo cual nos da un total de 264 días laborables.


Página 117 de 156

Así, el coste por día de trabajo de las dos personas que han participado en la elaboración del proyecto sería el siguiente:

CUALIFICACIÓN COSTE DIARIO (Ptas.)

Ingeniero de Telecomunicaciones 22.727

Ingeniero Técnico de Telecomunicaciones 15.151

Auxiliar administrativo 7.576

Figura 69. Coste diario del personal

8.1.2. COSTES POR PERSONA

Para determinar el coste total de los dos profesionales se ha hecho una valoración de los días invertidos por cada uno. Así resulta lo siguiente:

TAREA EFECTUADA POR DURACCIÓN EN DÍAS

Diseño de los objetivos Ingeniero 10

Planificación del desarrollo del proyecto Ingeniero 25

Análisis económico Ingeniero 15

Diseño de la Interfaz Ingeniero Técnico 15

Desarrollo de la interfaz Ingeniero Técnico 30

Programación DSP Ingeniero Técnico 35

Dispositivo LINUX Ingeniero Técnico 45

Tren de pruebas Ingeniero Técnico 10

Elaboración de la memoria Ingeniero 8

Composición de los documentos Auxiliar Administrativo 15

Figura 70. Cantidad de días trabajados por cada persona


Página 118 de 156

Por tanto, los costes de personal derivados de la realización del proyecto son:

PERSONAL TIEMPO INVERTIDO (días)

COSTE DIARIO (Ptas.)

COSTE TOTAL (Ptas.)

Ingeniero 58 22.727 1.318.166

Ingeniero Técnico 135 15.151 2.045.385

Administrativo 15 7.576 113.640

COSTE TOTAL DE PERSONAL 3.477.191

Figura 71. Coste total de personal

Con lo que el coste total del personal empleado asciende a TRES MILLONES CUATROCIENTAS SETENTA Y SIETE MIL CIENTO NOVENTA Y UNA pesetas.

8.2. COSTES DE MATERIAL

El material utilizado para la realización de este proyecto, puede dividirse en dos partes:

- Material de producción técnica: Componentes electrónicos, herramientas de desarrollo, ordenadores, transceptores, etc. En la siguiente tabla se muestra el coste de estos elementos:

CONCEPTO DÍAS DE USO COSTE DIARIO (Ptas)

COSTE TOTAL (Ptas)

Componentes electrónicos

- - 50.000

2 Ordenadores Personales (LINUX

y Windows 95)

135 5.000 675.000

Herramientas de desarrollo

(ORCAD, PROTEL)

40 1.500 60.000

Herramientas de laboratorio y

programación

95 3.000 285.000

2 Transceptores 75 1.000 75.000

COSTE TOTAL 1.145.000

Figura 72. Coste de material técnico


Página 119 de 156

- Material de redacción: Ordenador provisto de herramientas de procesamiento de documentos, impresora, y otro material de oficina. En la siguiente tabla se muestra el coste de estos elementos:

CONCEPTO DÍAS DE USO COSTE DIARIO (Ptas)

COSTE TOTAL (Ptas)

Material de oficina - - 25.000

Equipo informático 15 2.500 37.500

Impresora Láser 15 2.500 37.500

COSTE TOTAL 100.000

Figura 73. Coste de material de redacción

Con lo que el coste total del material de proyecto asciende a UN MILLÓN DOSCIENTAS CUARENTA Y CINCO MIL pesetas.

8.3. TOTAL PRESUPUESTO

El coste total del proyecto se obtiene a partir del coste de ejecución material, formado por el coste de personal y el de materiales, según queda reflejado en la tabla:

CONCEPTO COSTE (Ptas.)

Coste total de personal 3.477.191

Coste total de material 1.245.000

COSTE DE EJECUCIÓN MATERIAL 4.722.191

Figura 74. Coste de ejecución material del proyecto


Página 120 de 156

Sólo queda añadir al coste anterior el 7% en concepto de tasas de elaboración y redacción del proyecto y el 16% en concepto de IVA para obtener el coste total:

CONCEPTO % APLICABLE SOBRE E.M. COSTE

Elaboración y redacción 7 330.553

IVA 16 755.551

COSTE TOTAL DEL PROYECTO 5.808.295

Figura 75. Coste de ejecución total del proyecto

Con lo que el coste total de este proyecto asciende a la cantidad de CINCO MILLONES OCHOCIENTAS OCHO MIL DOSCIENTAS NOVENTA Y CINCO pesetas.


Página 121 de 156

9. CONCLUSIONES

Como se dijo inicialmente, se pretendía con este proyecto desarrollar un sistema sencillo y de coste reducido que permitiera, a un nivel residencial, establecer comunicaciones digitales de manera inalámbrica, sin tener que ser necesario afrontar los costes que las operadoras de telecomunicaciones tarifan por sus servicios de enlace.

Durante el tercer apartado de este proyecto, se fijaron los objetivos que se pretendían cumplir durante la realización del mismo, y la impresión de los proyectistas ha sido que los objetivos han sido plenamente satisfechos, además de obtener una forma de comunicación sencilla y barata, que ha sido empleada durante el desarrollo del mismo con resultados satisfactorios entre nuestros domicilios, separados aproximadamente a una distancia de 10 Km.

El proyecto nos ha brindado conceptos claros en cuanto a los temas tratados se refiere, los cuales se consideran de suma importancia para el desarrollo de nuestro futuro profesional, por lo cual nuestros objetivos han sido satisfechos completamente.


Página 122 de 156

10. BIBLOGRAFÍA

- Libro “DSP 56002 Digital Signal Processor User’s Manual”, editado por Motorola.

- Libro “Manual avanzado de LINUX”, escrito por Raúl Montero Rivero y editado por Anaya Multimedia.

- Primera parte del proyecto “Diseño de una interfaz basada en DSP para el acceso vía radio a una red local”, Escrita por Francisco Valencia Arribas para la Universidad de Alcalá de Henares.

- “Unix system manager’s manual”, incorporado en la versión 2.2.5 del kernel del sistema operativo.

- Hojas de características de los circuitos integrados que intervienen en el proyecto, suministradas por el fabricante de cada uno de ellos.


Página 123 de 156

11. DIRECTORIO INTERNET

- http://www.motorola.com

- http://www.ee.latrobe.edu.au/library/Processors/Motorola/DSP56000/56000

- ftp://digigrup.es/amsat

- ftp://det.bi.ehu.es/pub/ham/evm

- ftp://nic.funet.fi/pub/ham/dsp

- http://jrmiller.demon.co.uk

- http://alibaba.math.unifi.it/linux.guides/khg/HyperNews/get/net/net-intro.html

- http://hamgate.upc.es/info/tcm3105.pdf

- http://209.1.238.250/arpdf/1798.pdf

- http://www.fairchildsemi.com/ds/DM/DM74LS157.pdf

- http://www.ece.mcgill.ca/courses/304-323/pdf/74ls00.pdf

- http://www-eu2.semiconductors.com/products/


Página 124 de 156

ANEXO A. LISTADO COMPLETO DEL SOFTWARE

A Continuación se representa el listado completo del software del dispositivo de LINUX que efectuará las tareas de administración de la red y generación del protocolo RPP, haciendo de intermediario entre el dispositivo físico y todos los protocolos de nivel superior, que están formados por la pila estándar de protocolos TCP/IP y que ya se encuentran cargados en el sistema operativo LINUX.

El siguiente código es el correspondiente a la incialización del software, con las deficiniones de las librerias, variables y funciones que intervendrán en el mismo:

/************************************************** ***********************/

/* rpp.c */

/* */

/* Driver de red para un módem externo sin imp lementación de */

/* protocolo en su hardware. */

/* */

/* Este driver esta escrito para trabajar bajo el sistema */

/* operativo LINUX */

/************************************************** ***********************/

/************************************************** ***********************/

/* Se cargan todas las librerías necesarias sumin istradas por LINUX */

/************************************************** ***********************/

#include <linux/config.h>

#include <linux/module.h>

#include <linux/sched.h>

#include <linux/types.h>

#include <linux/fcntl.h>

#include <linux/interrupt.h>

#include <linux/ptrace.h>

#include <linux/ioport.h>

#include <linux/in.h>

#include <linux/malloc.h>

#include <linux/string.h>

#include <linux/init.h>

#include <asm/system.h>

#include <asm/bitops.h>

#include <asm/io.h>

#include <asm/dma.h>

#include <linux/errno.h>

#include <linux/netdevice.h>

#include <linux/etherdevice.h>

#include <linux/if_ether.h>

#include <linux/if_arp.h>

#include <linux/skbuff.h>


Página 125 de 156

/************************************************** ***********************/

/* Definición de las constantes del si stema */

/************************************************** ***********************/

#define IO_EXTENT 10 /* Numero de puerto s del dispositivo */

#define LEN_HEAD_RPP 8 /* Tamaño de la cabe cera del paquete RPP */

#define IP_ADDR0 10 /* Dirección IP del dis positivo */

#define IP_ADDR1 21

#define IP_ADDR2 211

#define IP_ADDR3 2

#define MAX_RX 3000 /* Máximo tamaño del bú ffer de recepción */

#define MAX_CIRCULAR 6000 /* Máximo tamaño del búffer circular */

#define RPP_IP_MTU 2040 /* Máximo tamaño de l paquete IP */

#define TX_BAUD 9600 /* Velocidad del puert o serie */

#define DIVISOR 1843200/(16*TX_BAUD)

#define MAX_PACKET_TIME (RPP_IP_MTU*10)/TX_BAUD*20 /* Tiempo máximo de */

/* un paquete en */

/* interrupciones */

/* de 50 ms */

#define MAX_RANDOM_TIME 25 /* Ti empo máximo aleatorio */

/* en unidades de 100 ms */

#define MIN_RANDOM_TIME 1

#define RPP_COM 1 /* Seleccion a el numero de puerto */

/* serie: 0 -> COM1 y 1 -> COM 2 */

#define PACKET 0

#define CONF 1

/************************************************** ***********************/

/* Definición de funciones */

/************************************************** ***********************/

static int rpp_xmit(struct sk_buff *skb, struct dev ice *dev);

static struct net_device_stats *rpp_get_stats(struc t device *dev);

void rpp_interrupt(unsigned long data);

void rpp_irq(int irq, void *dev_id, struct pt_regs *regs);

int init_puerto(int Addr);

int control_buffers(void);

int del_buffer(void);

void TX_On(int);

/************************************************** ***********************/


Página 126 de 156

/* Definición de variables */

/************************************************** ***********************/

extern unsigned long jiffies; /* Var iable para el control */

/* de las interrupciones */

struct timer_list rpp_timer; /* Estructura de tiempo para add_timer */

struct rpp_data /* Estructura de dato s internos del driver */

{

struct device *dev;

unsigned char *buffTX;

int tx_len;

unsigned char *buffRX;

int rx_len;

int buffTX_busy;

unsigned char *circular_buffer;

unsigned int PWrite;

unsigned int PRead;

int Cont_Trans;

int Ndat_Trans;

int Uart;

};

struct header_rpp /* Estructura que indica el fo rmato del paquete RPP */

{

unsigned char Init0;

unsigned char Init1;

unsigned char Len_Low;

unsigned char Len_High;

unsigned char Source;

unsigned char Dest;

unsigned char CRC_Low;

unsigned char CRC_High;

};

struct buffers /* Estructura para gestionar la cola de buffers de entrada*/

{

unsigned char *buffer;

int time_out;

int num;

struct buffers *next;

};

struct buffers *first_buffer=NULL; /* Puntero al pr imer búffer de la cola*/

static struct rpp_data *rpp; /* Punter o a la estructura rpp */

struct net_device_stats *stats; /* Pu ntero a la estructura */

/* de estadisticas */

unsigned char buffer_conf[6]; /* Buffe r para la confirmacion */

unsigned char *buffer_trans; /* Pu ntero para transmitir */

/* po r el puerto serie */

char *cardname= "RPP0"; /* Nombre usado en las ru tinas de interrupcion */

int tx_delay_time = MAX_PACKET_TIME; /* Contador usado para transmitir */

int port_list[]={0x3f8,0x2f8}; /* Lis ta de las direcciones */


Página 127 de 156

/* base de los puertos serie */

int serie_irq[]={4,3}; /* Lista de las interrupciones */

/************************************************** ***********************/

/* Definición de variables generales de control */

/************************************************** ***********************/

int Stop_Count = 0;

long Rn;

int TX_Flag = 0;

int tx_time_out = 0;

int Terminar_Trans=0;

int open=0;

unsigned long rx_delay_time = 0;

int count=0;

int Num_pack=0;

A continuación se irán detallando las funciones que han sido declaradas:

/************************************************** ***********************/

/* FUNCIÓN open */

/* Es la llamada al ejecutar ifconfig */

/************************************************** ***********************/ static int rpp_open(struct device *dev) { open = 1; printk("Driver RPP Habilitado\n"); return 0; } /************************************************** ***********************/

/* FUNCIÓN close */

/* Es la llamada al ejecutar ifconfig con la opción down */

/************************************************** ***********************/ static int rpp_close(struct device *dev) { open = 0; init_puerto(rpp->Uart); printk("Driver RPP Deshabilitado\n"); return 0; } /************************************************** ***********************/

/* FUNCIÓN init */

/* Es la llamada por el sistema al iniciar se */


Página 128 de 156

/************************************************** ***********************/ int rpp_init(struct device *dev) { int irqval; /* Inicializa la e structura device */ dev->hard_start_xmit= rpp_xmit; dev->irq = serie_irq[RPP_COM]; dev->priv = kmalloc(sizeof(struct net_device_stats ), GFP_KERNEL); if (dev->priv == NULL) return -ENOMEM; memset(dev->priv, 0, sizeof(struct net_device_stat s)); dev->get_stats = rpp_get_stats; dev->open = rpp_open; dev->stop = rpp_close; dev->set_multicast_list = NULL; dev->change_mtu = NULL; dev->hard_header = NULL; dev->rebuild_header = NULL; dev->set_mac_address = NULL; dev->hard_header_cache = NULL; dev->header_cache_update = NULL; dev->hard_header_parse = NULL; dev->hard_header_len = 0; /* Indica que el sistema no reserva */ /*espacio para i ntroducir una cabecera*/ dev->mtu = RPP_IP_MTU; /* Valor máximo del paquete IP */ dev->addr_len = 0; dev->type = ARPHRD_SLIP; /* Tipos de paquete a transmitir */ dev->tx_queue_len = 10; /* Numero de paquete s en cola que */ /* guardara el s istema */ dev->flags = IFF_NOARP; /* Indica que no se utilizará el */ /* protocolo AR P */ dev_init_buffers(dev); /* Inicializa los búf fers del sistema */ /* Reserva memoria para la estructura rpp */ rpp = (struct rpp_data *)kmalloc(sizeof(struct rpp _data),GFP_KERNEL); if(rpp==NULL) { printk("%s: Error de memoria. rpp",dev->name); return -EAGAIN; } rpp->buffRX = (char *)kmalloc(MAX_RX,GFP_KERNEL); /*Reserva memoria*/ /* para el búffer */ /* buffRX */ if(rpp->buffRX==NULL) { printk("%s: Error de memoria. buffRX",dev->name); return -EAGAIN; } /* Reserva memoria para el búffer circular */ rpp->circular_buffer = (char *)kmalloc(MAX_CIRCULA R,GFP_KERNEL);


Página 129 de 156

if(rpp->circular_buffer==NULL) { printk("%s: Error de memoria. circular_buf fer",dev->name); return -EAGAIN; } /* El búffer TX no esta aqui porque es rese rvado dinamicamente */ rpp->dev = dev; /* Inicial iza la estructura rpp */ init_timer(&rpp_timer); rpp_timer.expires=jiffies+5; rpp_timer.data=0; rpp_timer.function=rpp_interrupt; add_timer(&rpp_timer); rpp->PWrite = 0; rpp->PRead = 0; rpp->buffTX_busy = 0; rpp->Uart = port_list[RPP_COM]; stats=(struct net_device_stats *)dev->priv; printk("Driver de red RPP\n"); /* Se comprueba que se puede usar la interrupcion */ irqval=request_irq(serie_irq[RPP_COM],&rpp_irq,0,c ardname,NULL); if(irqval) { printk("%s: IRQ %d ya en uso\n",dev->name,dev->ir q); dev->irq=0; return -EAGAIN; } else printk("%s: IRQ %d asignada\n",dev->name,dev- >irq); /* Se comprueba que se pueden usar los puertos */ if(check_region(rpp->Uart,IO_EXTENT)==0) { printk("%s: Direcciones %d - %d de I/O asignadas\ n",dev->name, port_list[RPP_COM],port_list[RPP_COM]+IO_E XTENT-1); request_region(rpp->Uart,IO_EXTENT,"rpp"); dev->base_addr=port_list[RPP_COM]; } else { printk("%s: Direcciones %d - %d de I/O ya en uso\ n",dev->name, port_list[RPP_COM],port_list[RPP_COM]+IO_EXTENT); dev->base_addr=0; return -EAGAIN; } init_puerto(rpp->Uart); /* Inicializa el puerto * / return 0; }


Página 130 de 156

/************************************************** ***********************/

/* FUNCIÓN RAND */

/* Genera un número aleatorio */

/************************************************** ***********************/ int Rand(void) { int rnd; rnd=(int)(jiffies & 0xff); rnd/=10; if(rnd>MAX_RANDOM_TIME) rnd=MAX_RANDOM_TIME; /* Numero máximo */ if(rnd<MIN_RANDOM_TIME) rnd=MIN_RANDOM_TIME; /* Numero mínimo */ return rnd; } /************************************************** ***********************/

/* FUNCIÓN write_buffer */

/* Escribe un dato en el búffer circular e incr ementa el puntero */

/************************************************** ***********************/ void write_buffer(unsigned char Dato) { int Paux = rpp->PWrite; if (rpp->PWrite==MAX_CIRCULAR-1) rpp->PWrite=0; else rpp->PWrite++; if(rpp->PWrite==rpp->PRead) rpp->PWrite=Paux; else rpp->circular_buffer[Paux] = Dato; }

/************************************************** ***********************/

/* FUNCIÓN read_buffer */


Página 131 de 156

/* Lee un dato del búffer circular. En función del parámetro type: */

/* Type=0 -> No incrementa el puntero. Desp indica el desplazamiento */

/* Type=1 -> Incrementa el puntero. Desp indica el desplazamiento */

/* Type=2 -> Devuelve el número de bytes pendiente s por leer. Desp es */

/* ignorado */

/************************************************** ***********************/ int read_buffer(int Type, int Desp) { int Dato; int Paux = rpp->PRead; int Dif; if(Type!=2) { if(rpp->PRead==rpp->PWrite) return -1; if(rpp->PWrite < rpp->PRead) Dif=rpp->PWrite + MAX _CIRCULAR - rpp->PRead; else Dif=rpp->PWrite - rpp->PRead; if(Dif>=Desp) { Paux+= Desp; If(Paux > (MAX_CIRCULAR-1)) Paux-= MAX_CIRCULAR; Dato = rpp->circular_buffer[Paux]; If(Type==1) rpp->PRead=Paux; } else Dato=-1; } else { if(rpp->PRead > rpp->PWrite) Dato = rpp->PWrite + MAX_CIRCULAR - rpp->PRead; else Dato = rpp->PWrite - rpp->PRead; } return Dato; } /************************************************** ***********************/

/* FUNCIÓN comp_init_rpp */


Página 132 de 156

/* Comprueba si ha llegado el inicio de un paquete */

/************************************************** ***********************/ int comp_init_rpp(void) { int d=0; while(d!=0xD8) { d=read_buffer(0,0); if(d==-1) return -1; if(d!=0xD8) d=read_buffer(1,1); } return 0; } /************************************************** ***********************/

/* FUNCIÓN Init_RandomTX */

/* Genera un valor aleatorio al que se le puede sum ar un tiempo minimo */

/************************************************** ***********************/ void Init_RandomTX(int Time) { /* El máximo paquete son MAX_TIME interrupciones */ Rn=Rand(); tx_delay_time = Time + Rn * 2; } /************************************************** ***********************/

/* FUNCIÓN comp_total_rpp */

/* Comprueba si ha llegado un paquet e entero */

/************************************************** ***********************/ int comp_total_rpp(void) { unsigned int Len_Low; unsigned int Len_High; unsigned int Len; if(read_buffer(2,0) < 4) return -1; /* Si el búffer contiene menos */ /* de 4 b ytes, sale */ Init_RandomTX(0); /* Genera un nuevo tiempo al eatorio */ Len_Low = read_buffer(0,1); Len_High = read_buffer(0,2); Len = (Len_High * 256) + Len_Low; Len--; if(Len>RPP_IP_MTU+8) {read_buffer(1,1); return -2;} /* Si hay un error */ /* en el tamaño, */ /* sale y devuelve */ /* un -2 */ if(read_buffer(2,0)>=Len) return 0; /* S i no ha llegado el */ /* pa quete entero, se sale */ return -1; } /************************************************** ***********************/

/* FUNCIÓN check_CRC */


Página 133 de 156

/* Comprueba si el CRC es correcto */

/************************************************** ***********************/ int check_CRC(void) { unsigned int CRC_Low; unsigned int CRC_High; unsigned int CRC; int Len; int Len_Low; int Len_High; int x; unsigned int Sum=0; CRC_Low = read_buffer(0,5); /* Lee el CRC que vien e en el paquete */ CRC_High = read_buffer(0,6); CRC = (CRC_High * 256) + CRC_Low; Len_Low = read_buffer(0,1); Len_High = read_buffer(0,2); Len = (Len_High * 256) + Len_Low; Len--; for(x=0;x<Len;x++) /* Calcula el CRC que deberia tener el paquete */ { if(x!=5 && x!=6) Sum += read_buffer(0,x); } if( (Sum & 0xffff) == CRC ) return 0; /* Si coincid en se devuelve */ /* un 1, e n caso contrario un 0 */ return -1; } /************************************************** ***********************/

/* FUNCIÓN del_rpp_packet */

/* Elimina un paquete RPP del búffer cir cular */

/************************************************** ***********************/ void del_rpp_packet(void) { int d; d = read_buffer(1,1); /* Incrementa en 1 el puntero de */ /* lectura al buffer circular */ } /************************************************** ***********************/

/* FUNCIÓN comp_conf */


Página 134 de 156

/* Comprueba si la confirmación es par a esta máquina */

/************************************************** ***********************/ int comp_conf(void) { if(read_buffer(2,0)<4) return 0; /* Comprueba que el búffer */ /* ci rcular tiene mas de */ /* cu atro bytes */ if(read_buffer(0,1)==0xd9 && read_buffer(0,2)==0xda ) /* Comprueba si el */ /* paquete es una */ /* confirmación */ { if(read_buffer(0,3)==IP_ADDR3) /* Si la confir mación es */ /* para esta maquina, se */ /* elimina el paquete */ { /* confirmado */ del_buffer(); rpp->buffTX_busy=0; stats->tx_dropped++; } del_rpp_packet(); /* Se elimina la confirmación */ /* del búf fer circular */ Stop_Count=0; Init_RandomTX(5); } return 0; } /************************************************** ***********************/

/* FUNCIÓN copy_rpp_packet */

/* Copia un paquete RPP del búffer circular al búffer local */

/************************************************** ***********************/ char *copy_rpp_packet(void) { unsigned char Len_Low; unsigned char Len_High; int Len; int x; Len_Low = read_buffer(0,1); /* Comprueba la l ongitud del */ /* paquete en el buffer circular */ Len_High = read_buffer(0,2); Len = (Len_High * 256) + Len_Low; rpp->rx_len=Len; Len--; for(x=0;x<Len;x++) rpp->buffRX[x]=(char)read_buffer (0,x); stats->rx_bytes+=Len; return (rpp->buffRX); } /************************************************** ***********************/


Página 135 de 156

/* FUNCIÓN packet_rx */

/* Controla la recepción de paquetes en el b úfefr circular */

/************************************************** ***********************/ char *packet_rx(char *buffer) { int estado; estado = comp_init_rpp(); /* Comprueba que ha llegado el */ /* inicio de un paquete */ if(estado==-1) return NULL; comp_conf(); Stop_Count=1; estado = comp_total_rpp(); /* comprueba que el paqu ete ha llegado entero */ if(estado==-1) return NULL; if(estado==-2) {Stop_Count=0; return NULL;} Stop_Count = 0; Estado = check_CRC(); /* Compru eba la integridad del */ /* paquet e mediante el CRC */ if(estado==-1) /* En caso de no ser correcto elimina el paquete */ { del_rpp_packet(); return NULL; } buffer = copy_rpp_packet(); /* Copia el paquete en el búffer */ /* de recep ción */ del_rpp_packet(); return buffer; }


Página 136 de 156

/************************************************** ***********************/

/* FUNCIÓN Init_TX */

/* Inicia la transmisión */

/************************************************** ***********************/ int Init_TX(int Mode) { struct header_rpp *head; int Len; if(TX_Mode==PACKET) first_buffer->time_out++; if(TX_Mode==PACKET) stats->tx_packets++; TX_Flag=1; if(TX_Mode==PACKET) /* Comprueba si lo que se de be */ /* Transmi tir es un paquete o */ /* es una confirmación */ { head=(struct header_rpp *) rpp->buffTX; Len=head->Len_Low + head->Len_High * 256; Buffer_trans=rpp->buffTX; } else { buffer_trans=buffer_conf; Len=5; } TX_Flag=1; rpp->Cont_Trans=0; rpp->Ndat_Trans=Len-1; outb(0x02,rpp->Uart+1); outb(buffer_trans[rpp->Cont_Trans],rpp->Uart); stats->tx_bytes+=Len; return 0; } /************************************************** ***********************/

/* FUNCIÓN rpp_len */

/* Calcula la longitud del paquete RPP s in cabecera */

/************************************************** ***********************/ int rpp_len(void) { int len; len = rpp->rx_len - LEN_HEAD_RPP; return len; }


Página 137 de 156

/************************************************** ***********************/

/* FUNCIÓN rpp_del_header */

/* Elimina la cabecera de un paquete RPP */

/************************************************** ***********************/ char *rpp_del_header(char *buffer) { buffer+=LEN_HEAD_RPP-1; return buffer; } /************************************************** ***********************/

/* FUNCIÓN net_up */

/* Sube al nivel superior un paquete RP P */

/************************************************** ***********************/ int net_up(char *buffer, int len) { struct sk_buff *skb; skb = dev_alloc_skb(len); /* Reserva un búffer skb */ if (skb == NULL) { printk("%s: memory squeeze, dropping packet.\n", r pp->dev->name); return 0; } skb->dev = rpp->dev; /* Copia el búffer loc al en el */ memcpy(skb_put(skb,len), buffer, len); /* buffer skb, y se lo devuelve */ skb->mac.raw=skb->data; /* al nive l superior */ skb->protocol=htons(ETH_P_IP); netif_rx(skb); stats->rx_packets++; /* Control de estadisticas */ return 0; } /************************************************** ***********************/

/* FUNCIÓN control_conf */

/* Controla la confirmación */

/************************************************** ***********************/ unsigned char *control_conf(unsigned char *buffer) { if(buffer[4]!=IP_ADDR3) return buffer; /* Si el paq uete no es para esta */ /* máquina, no se confirma */ buffer_conf[0]=0xff; /* Se rellena el b úffer de confirmacion */ buffer_conf[1]=0xd8; buffer_conf[2]=0xd9; buffer_conf[3]=0xda; buffer_conf[4]=buffer[3]; /* Se conf irma con la dirección */ /* de esta máquina */ Init_TX(Conf); return buffer; }


Página 138 de 156

/************************************************** ***********************/

/* FUNCIÓN rx_control */

/* Controla la recepción */

/************************************************** ***********************/ int rx_control(void) { unsigned char *buffer=NULL; int ndat; buffer = packet_rx(buffer); /* Comprueba si han l legado paquetes */ if(buffer==NULL) return 0; buffer = control_conf(buffer); /* Comprueba si han llegado */ /* confirnacion es */ ndat= rpp_len(); buffer = rpp_del_header(buffer); net_up(buffer,ndat); /* En caso de haber llegado un */ /* paquete, es enviado al nivel */ /* superior */ return 0; }

/************************************************** ***********************/

/* FUNCIÓN TX_Off */

/* Coloca al transceptor en modo recepc ión */

/************************************************** ***********************/ void TX_Off(void) { TX_Flag=0; if(TX_Mode==PACKET)Init_RandomTX(20); } /************************************************** ***********************/

/* FUNCIÓN init_puerto */

/* Inicializa el puerto serie */

/************************************************** ***********************/ int init_puerto(int Addr) { outb(0x83,Addr+3); /* Selecciona los pue rtos Dirección y */ /* dirección+1 para p rogramar la velocidad */ outb(DIVISOR & 0xff,Addr); outb((DIVISOR >> 8) & 0xff,Addr+1); outb(0x03,Addr+3); /* Vuelven a su func ionamiento normal */ outb(0x03,Addr+3); outb(0x01,Addr+1); outb(0x08,Addr+4); outb(0x0,Addr+2); inb(Addr); return 0; }


Página 139 de 156

/************************************************** ***********************/

/* FUNCIÓN rpp_irq */

/* Rutina de interrupción del puer to serie */

/************************************************** ***********************/ void rpp_irq(int irq, void *dev_id, struct pt_regs *regs) { int tipo=0; unsigned char d; tipo=inb(rpp->Uart+2); /* Comprueba si la inte rrupción es */ /* por transm ision o por recepción */ if((tipo & 7)==2) /* Transmisión */ { if(Terminar_Trans==0) /* Transmite mientras este flag sea 0 */ { rpp->Cont_Trans++; /* Se incrementa en cada byte */ /* trans mitido */ if(rpp->Cont_Trans<=rpp->Ndat_Trans) outb(buffer_ trans[rpp->Cont_Trans],rpp->Uart); /* Se comprueba q ue hay mas datos para */ /* transmitir, si no se termitna */


Página 140 de 156

else {Terminar_Trans=1; outb(0,rpp->Uart);} /* Si no hay mas datos, */ /* se transmite un */ /* último de byte, de */ /* valor "0" */ } else /* Si no hay mas datos para */ /* transmitir, s e coloca la emisora */ /* en recepción */ { Terminar_Trans=0; TX_Off(); if(TX_Mode==PACKET) rpp->buffTX_busy=0; rpp->dev->tbusy=0; } } if((tipo & 7)==4) /* Recepción */ if(open) /* Comprueba si la recepción está */ /* habilitada */ { rx_delay_time=jiffies; /* Tiempo de retardo de r ecepción */ /* entre bytes */ d=inb(rpp->Uart); /* Se lee el byte recibido, y se */ /* guarda en el buffer circular */ write_buffer(d); } return; } /************************************************** ***********************/

/* FUNCIÓN tx_control */

/* Controla la transmisión */

/************************************************** ***********************/ int tx_control(void) { if(Stop_Count==0) /* Indica el tiempo de espera an tes de tranmitir */ /* Este es fijado aleatoriamente */ { tx_delay_time--; if(tx_delay_time<0) tx_delay_time=0; } if(Stop_Count==1 && jiffies > rx_delay_time+50) /* Comprueba que la */ /* r ecepción no tiene un */ /* t ime_out */ { del_rpp_packet(); Stop_Count=0; }


Página 141 de 156

if(tx_delay_time==0 && TX_Flag==0) /* Si ya es posible */ /* tra nsmitir, y no se esta */ /* tra nsmitiendo ya, se */ /* pon e la emisora en */ /* tra nsmisión */ if(rpp->buffTX_busy==1) { /* Se llama a la función que empezara */ /* a enviar datos a la t arjeta */ Init_TX(PACKET); } return 0; } /************************************************** ***********************/

/* FUNCIÓN rpp_interrupt */

/* Rutina de interrupción periódica. Se p roduce cada 50 ms */

/************************************************** ***********************/ void rpp_interrupt(unsigned long data) { cli(); if(open) { control_buffers(); if(TX_Flag==0) rx_control(); /* Si no se esta tr ansmitiendo se */ /* controla la recepción */ tx_control(); /* Controla la transmisión */ } rpp_timer.expires=jiffies+5; /* Timer */ add_timer(&rpp_timer); } /************************************************** ***********************/

/* FUNCIÓN Make_CRC */

/* Calcula el CRC para incluirlo en el pa quete RPP */

/************************************************** ***********************/ int Make_CRC(char *buffer, int len) { int i; int CRC=0; for(i=1;i<len;i++) CRC+=(unsigned char)buffer[i]; return CRC; } /************************************************** ***********************/

/* FUNCIÓN rpp_add_header */

/* Añade la cabecera a un paquete RP P */

/************************************************** ***********************/ int rpp_add_header(unsigned char *buffer, int len) { struct header_rpp *head;


Página 142 de 156

int CRC; head=(struct header_rpp *)buffer; /* Rellena los c ampos de la cabecera */ head->Init0 = 0xff; head->Init1 = 0xd8; head->Len_Low = len & 0xff; head->Len_High = (len >> 8) & 0xff; head->Source = IP_ADDR3; /* Comprueba que el paq uete va a nuestra red */ /* sino, el paquete es enviado al gateway */ if(buffer[LEN_HEAD_RPP+16] != IP_ADDR0 || buffer[LEN_HEAD_RPP+17] != IP_ADDR1 || buffer[LEN_HEAD_RPP+18] != IP_ADDR2) head->Dest = 254; else head->Dest = buffer[LEN_HEAD_RPP+19]; head->CRC_Low = 0; head->CRC_High = 0; CRC = Make_CRC(buffer, len); /* Calcula el CRC */ head->CRC_Low = CRC & 0xff; head->CRC_High = (CRC >> 8) & 0xff; return 0; }

/************************************************** ***********************/

/* FUNCIÓN add_buffer */

/* Añade un búffer a la lista de búffer de transmisión */

/************************************************** ***********************/ struct buffers *add_buffer(struct sk_buff *skb) { struct buffers *new,*lista=first_buffer; if(count>250) return NULL; /* Máximo número de búffers en la lista */ new=(struct buffers *)kmalloc(sizeof(struct buffers ),GFP_KERNEL); /* Reserva memoria para un nuevo búffer */ if(first_buffer==NULL) lista=first_buffer=new; /* S i no hay búffers en */ /* l a lista, se coloca el */ /* p rimero */ else /* En caso contrario, se busca e l último búffer de la */ /* lista, y se añade después */ { while(lista->next!=NULL) lista=lista->next; lista->next=new; lista=lista->next;


Página 143 de 156

} lista->next=NULL; lista->time_out=0; lista->num=Num_pack++; /* Reserva memoria */ lista->buffer=(char *)kmalloc(skb->len + LEN_HEAD_R PP,GFP_KERNEL); /* Copia el buffer, y deja el hueco de la cab ecera para rellenarla */ memcpy(lista->buffer+LEN_HEAD_RPP,skb->data,skb->le n); count++; return lista; }

/************************************************** ***********************/

/* FUNCIÓN rpp_xmit */

/* Recibe paquetes del nivel superio r */

/************************************************** ***********************/ static int rpp_xmit(struct sk_buff *skb, struct dev ice *dev) { struct buffers *lista; lista=add_buffer(skb); if(lista==NULL) /* Se comprueba si el búffer e sta ocupado */ { dev->tbusy=1; /* Se le indica a linux que e l driver */ /* está ocupado en T X y se devuelve error */ return 1; } dev->tbusy=0; rpp_add_header(lista->buffer,skb->len+LEN_HEAD_RPP ); /* Añade la */ /* cabecera al*/ /* buffer */ dev_kfree_skb(skb); /* Libera el búff er que linux nos */ /* ha propor cionado */ return(0); } /************************************************** ***********************/

/* FUNCIÓN net_devices_stats */

/* Inicializa las estadísticas */

/************************************************** ***********************/ static struct net_device_stats *rpp_get_stats(struc t device *dev) { struct net_device_stats *stats = (struct net_de vice_stats *) dev->priv; return stats; } /************************************************** ***********************/

/* FUNCIÓN del_buffer */

/* Elimina un paquete RPP de la lista de transmisión */

/************************************************** ***********************/ int del_buffer(void) { struct buffers *lista; lista=first_buffer;


Página 144 de 156

if(first_buffer==NULL) return -1; /* Si no ha y buffers, devuelve */ /* un erro r */ first_buffer=first_buffer->next; /* Se elimina el primer búffer */ /* de la l ista */ kfree(lista->buffer); /* Se libera la memori a del */ /* búffer eliminado */ kfree(lista); count--; return 0; } /************************************************** ***********************/

/* FUNCIÓN control_buffers */

/* Controla la lista de buffers */

/************************************************** ***********************/ int control_buffers(void) { struct buffers *lista=first_buffer; if(rpp->buffTX_busy==1) return 0; /* Se comprueba q ue el búffer local */ /* transmisión no está ocupado */ if(lista==NULL) return 0; /* Si no hay buffers en la lista sale */ if(lista->time_out==4) /* Si se han trasnm itido cuatro veces */ /* el mismo búf fer, se elimina */ { del_buffer(); rpp->buffTX_busy=0; count--; return 0; } rpp->buffTX=lista->buffer; /* Se coloca el nue vo búffer a */ /* transmiti r, en el búffer local */ rpp->buffTX_busy=1; return 0; }


Página 145 de 156

ANEXO B. INTERFAZ FSK

Con la finalidad de poder probar el dispositivo de comunicaciones de LINUX presentado en este proyecto, va a ser implementada una pequeña aplicación de un modulador – demodulador en FSK, basada en el circuito integrado TCM 3105.

B.1. CARACTERÍSTICAS GENERALES

Esta tarjeta, ofrece una manera de comunicar a las estaciones de la red presentada de una forma modesta, pero sencilla. Las características principales de que consta este dispositivo son las siguientes:

- Permite establecer comunicaciones a una velocidad de transferencia de hasta 1.200 bits por segundo.

- Al tratarse de un ancho de banda reducido, no es necesario modificar las condiciones de los transceptores habituales, pudiendo ser introducida la señal directamente en la entrada preparada para un micrófono, y obtener la señal del conector para unos auriculares o un altavoz exterior.

- No requiere de ningún tipo de programación, siendo misión del ordenador personal todas las tareas que deba efectuar el sistema.

- No requiere de ningún tipo de ajuste, a excepción de un potenciómetro que ajustará el offset de las señales recibidas, pero funciona correctamente en un amplio margen de posiciones.

- Su montaje es muy sencillo, y su coste reducido.

B.2. DIAGRAMA DE BLOQUES

El diagrama de bloques de este sencillo circuito es el que se puede ver a continuación:

Figura 76. Diagrama de bloques de la interfaz basada en el CI TCM 3105

La funcionalidad de cada uno de estos bloques quedará comentada en los apartados siguientes:


Página 146 de 156

B.2.1. FUENTE DE ALIMENTACIÓN

El circuito debe recibir dos tipos de alimentación, una de ellas a 12 voltios, y otra a 5 V. El diseño de la fuente de alimentación ha sido estudiado para obtener, de una manera sencilla, estados tensiones de una forma estable. Cabe destacar que la primera de ellas (12 V.) debe ser suministrada en buenas condiciones de amplitud, ya que esta señal es directamente utilizada, sin hacer sobre ella ningún tratamiento previo.

En la figura se puede ver el circuito eléctrico de este bloque. Su funcionamiento será explicado a continuación:

Figura 77. Circuito de la fuente de alimentación del diseño

En esta figura, se ve que el corazón del desarrollo está basado en el circuito integrado regulador 7805. El funcionamiento del circuito es muy simple:

La tensión de 12 voltios de corriente continua de entrada se aplica al conector T1. Inmediatamente después nos encontramos con el interruptor S1. El diodo D1 evita daños en el circuito si se intercambiara la polaridad de entrada. Los condensadores en paralelo C1 y C2 filtrarán posibles variaciones en la tensión de la señal. De este mismo punto, se obtendra la tensión de 12 voltios que precisarán determinados componentes en el circuito.

Esta misma señal, es aplicada a un circuito regulador del tipo 7805, obteniendo a su salida una tensión muy estable de 5 voltios que se usara para alimentar el resto del circuito. Los condensadores C3 y C4 evitan, al igual que C1 y C2, variaciones bruscas en esta tensión, y el conjunto formado por la resistencia R1 y el diodo LED D1 indicarán que el módem se encuentra conectado.


Página 147 de 156

B.2.2. RS – 232

Este bloque se encarga de adaptar las señales procedentes del interfaz serie RS – 232 del Ordenador a los niveles utilizados por el modulador de nuestra tarjeta y viceversa. Es decir, los niveles de la interfaz serie RS – 232 tiene unos valores que identifican cada uno de los símbolos digitales de tal forma que una bit de valor “1” se identifica con una tensión negativa de unos 12 voltios, mientras que un bit “0” se identifica con +12 V. Puesto que, en nuestra interfaz, los valores son los estándares TTL (5 V. para un “1” y cero voltios para un “0”), es necesario adaptar estos dos rangos de niveles.

Esta misión la realiza principalmente el circuito integrado MAX 232, cuando es configurado, según su fabricante, como se indica en la figura. En ella también se puede ver cómo han sido establecidas las conexiones del conector (DB9), que coinciden con las dictaminadas por RS – 232.

Figura 78. Circuito de la interfaz RS – 232 del diseño

De esta forma, las señales que salen del circuito son exactamente iguales a las que entran (lógicamente hablando), pero de niveles distintos.

B.2.3. MODULADOR / DEMODULADOR

Este bloque será el encargado de generar una señal analógica en función de la trama de bits de entrada en un sentido, y generar la trama de bits en función de la señal analógica en sentido contrario. Con el circuito propuesto, se modula en FSK, cuya explicación teórica se encuentra en la primera parte del proyecto. El componente activo del bloque es el circuito integrado TCM 3105, cuyas hojas características se reflejarán en el anexo final de este libro.


Página 148 de 156

El circuito completo de este bloque es el que se muestra a continuación:

Figura 79. Circuito del modulador / demodulador

En la figura puede observarse la simplicidad de este circuito. Pero, debido a que el circuito integrado TCM 3105 ha sido diseñado específicamente para esta aplicación, no requiere de más circuitería externa. Se va a basar su estudio en la función del patillaje del circuito integrado:

- Pin 1, VDD: Este pin se conectará a la alimentación positiva de 5 voltios.

- Pin 2, CLK: Este pin suministra una señal de reloj igual a 16 veces el valor de la velocidad de transmisión. Sirve para servir de fuente de reloj a un controlador externo, por lo que en nuestro caso no será utilizada.

- Pin 3, CDT: Esta es una señal digital que indicará la presencia de portadora.

- Pin 4, RXA: Esta es la entrada de señal analógica, que se corresponderá con una trama digital modulada en FSK.


Página 149 de 156

- Pin 5, TRS: Esta entrada seleccionará la velocidad de transmisión y recepción junto con TXR1 y TXR2. Para una velocidad de 1.200 bits por segundo, deberán permanecer las tres señales a un nivel bajo.

- Pin 6, NC: Pin no conectado internamente.

- Pin 7, RXB: A este pin se ha conectado un potenciómetro. Su utilidad es la de ajustar el offset de la señal analógica de entrada con la finalidad de evitar posibles errores en la señal digital que se recibe.

- Pin 8, RXD: Por este pin se transmitirán hacia el PC la trama digital de bits, una vez demodulados.

- Pin 9, Vss: Punto del negativo de la alimentación.

- Pin 10, CDL: El nivel de señal necesario para que se entienda que existe portadora en la entrada, y para que el pin CDT se ponga a nivel lógico uno, se ajusta mediante un potenciómetro conectado a este pin. Para el funcionamiento normal, no sería necesaria su conexión, ya que se hace caso omiso de la presencia o no de portadora, pero ha sido conectado con fines de ajuste.

- Pin 11, TXA: En este pin se transmite la señal analógica de salida, que corresponde a la trama de bits digitales de entrada, una vez modulados en FSK.

- Pin 12, TXR2: Esta entrada seleccionará la velocidad de transmisión y recepción junto con TXR1 y TRS. Para una velocidad de 1.200 bits por segundo, deberán permanecer las tres señales a un nivel bajo.

- Pin 13, TXR1: Esta entrada seleccionará la velocidad de transmisión y recepción junto con TXR2 y TRS. Para una velocidad de 1.200 bits por segundo, deberán permanecer las tres señales a un nivel bajo.

- Pin 14, TXD: Señal digital para ser modulada y transmitida.

- Pines 15 y 16, OSC: A estos pines se conectará un cristal de cuarzo de 4’4336 MHz típicamente, para el funcionamiento interno del TCM 3105.

B.2.4. TX / RX

Esta parte del circuito realiza dos tareas relacionadas con el control del transceptor. La primera de ellas es actuar sobre el control de transmisión de la misma, a fin de forzar al transceptor a conmutar del modo de transmisión al de recepción o viceversa.

La otra tarea importante realizada por este circuito es ajustar las señales de transmisión y recepción analógicas a unos valores adecuados para que sean aceptados correctamente tanto en la entrada del transceptor como en la entrada de nuestro sistema.


Página 150 de 156

En la siguiente figura se puede observar el esquema eléctrico de este bloque. En ella, se puede apreciar que la conmutación del modo de transmisión al de recepción y viceversa se ha realizado mediante un relé. Puesto que no va ser conmutado a alta velocidad, y dado que el retardo de conmutación del relé es despreciable frente al del transceptor, surgió como mejor alternativa.

Figura 80. Circuito del driver del transceptor

Mediante los dos potenciómetros R2 Y R4, se consigue ajustar los niveles de la señal a los valores adecuados, dentro de un amplio margen de aceptación, por lo que el ajuste no requiere ninguna herramienta precisa. Además, con la misma función que estos dos potenciómetros nos encontramos con los ajustes de volumen y ganancia de micrófono del transceptor, por lo que el ajuste puede ser efectuado externamente a la tarjeta.

Para eliminar la componente continua de las señales, ha sido implantado un condensador en cada una de las líneas (transmisión y recepción).

En este bloque han sido incluidos también dos diodos LED, que nos indicarán el estado del transceptor. Utilizando la señal RTS que ofrece el PC a través del puerto MAX-232, se enciende un diodo LED de color rojo al mismo tiempo que se activa el relé que hará conmutar a la emisora. Mediante la inversión conseguida con el transistor, se encendera el LED de color verde (recepción) al apagar el LED rojo (transmisión).


Página 151 de 156

B.3. ESQUEMA ELÉCTRICO COMPLETO

En la siguiente figura se puede observar el esquema eléctrico completo de la interfaz diseñada. Puesto que ya ha sido explicado su funcionamiento durante el desarrollo por bloques, no es preciso volver a comentarlo. Sólo cabe comentar las conexiones de los conectores DB9 que comunicarán a nuestra interfaz con el ordenador personal por un lado y con el transceptor por el otro. El DB9 que conectará con el PC, ha sido conectado siguiendo lo marcado por el estándar RS – 232, con la finalidad de que cualquier cable de este tipo que se adquiera sea válido para nuestra aplicación. En cuanto al conector de la emisora, se han escogido las conexiones de tal manera que no coincidan con las anteriores, para evitar daños en caso de conexión errónea. De este conector saldrá un cable de 4 hilos, que se conectará al transceptor de la siguiente manera:

- Señal TX Analógica: Pin de entrada de señal de micrófono.

- Señal TX: Pin ofrecido por los transceptores habitualmente. Al llevarlo a masa, el transceptor conmutará al modo de transmisión.

- Señal RX: Pin ofrecido por los transceptores habitualmente. Al llevarlo a masa, el transceptor conmutará al modo de recepción. En muchos casos, no será necesario conectar este cable, ya que algunos transceptores se mantienen en modo de recepción simplemente por el hecho de que el pin de señal TX se mantenga al aire.

- Masa: Terminal de masa del transceptor.

Puesto que estos equipos suministran la señal de audio a través de un conector Jack externo, se ha instalado un conector al que se colocará un cable Jack – Jack, y que servirá para transportar a la señal analógica de entrada a la interfaz.


Página 152 de 156

Figura 81. Esquema eléctrico completo de la interfaz basada en el TCM 3105

B.4. MODIFICACIONES A EFECTUAR SOBRE EL SOFTWARE

Para adecuar el software de LINUX prewsentado en este proyecto a esta interfaz, habrá que adecuar unos determinados parámetros. Concretamente, estos son:

- La velocidad se reduce de 9.600 bps a 1.200 bps

- El transceptor deberá ponerse en transmisión o en recepción en el mismo software, y mediante el apoyo de la línea RTS del puerto, ya que en el diseño original es el DSP quien realiza esta tarea. Las modificaciones a realizar son las siguientes:

Fijar las siguientes variables del preprocesador a estos valores:

#define RPP_IP_MTU 504 #define TX_BAUD 1200

Añadir la función TX_On:


Página 153 de 156

void TX_On(int Mode)

{

TX_Mode=Mode;

if(TX_Mode==PACKET) first_buffer->time_out++;

iX_Flag=2;

if(TX_Mode==PACKET) stats->tx_packets++;

else stats->rx_dropped++;

outb(0x0a,rpp->Uart+4);

}

Sustiuir la función TX_Off por la siguiente:

void TX_Off(void) { TX_Flag=0; If(TX_Mode==PACKET)Init_RandomTX(20); outb(0x08,rpp->Uart+4); outb(0x01,rpp->Uart+1); }

Sustituir la función tx_control por la siguiente:

int tx_control(void) { if(Stop_Count==0) /* Indica el tiempo de espera an tes de tranmitir */ /* Este es fijado aleatoriamente */ { tx_delay_time--; if(tx_delay_time<0) tx_delay_time=0; } if(Stop_Count==1 && jiffies > rx_delay_time+50) /* Comprueba que la */ /* r ecepción no tiene un */ /* t ime_out */ { del_rpp_packet(); Stop_Count=0; } if(tx_delay_time==0 && TX_Flag==0) /* Si ya es posible */ /* tra nsmitir, y no se esta */ /* tra nsmitiendo ya, se */ /* pon e la emisora en */ /* tra nsmisión */ if(rpp->buffTX_busy==1) TX_On(PACKET); if(TX_Flag>1) { TX_Flag++; /* Con este conta dor se espera el */ /* tiempo de conm utacion de la emisora */ Init_TX(TX_Mode);


Página 154 de 156

} return 0; }

Sustituir la función Init_TX por la siguiente:

int Init_TX(int Mode) { struct header_rpp *head; int Len; if(TX_Mode==PACKET) /* Comprueba si lo que se de be */ /* Transmi tir es un paquete o */ /* es una confirmación */ { head=(struct header_rpp *) rpp->buffTX; Len=head->Len_Low + head->Len_High * 256; Buffer_trans=rpp->buffTX; } else { buffer_trans=buffer_conf; Len=5; } if(TX_Flag >= 4) /* Espera el tiempo de conmutación a TX de las emisoras, antes de transmitir */ { TX_Flag=1; Rpp->Cont_Trans=0; Rpp->Ndat_Trans=Len-1; Outb(0x02,rpp->Uart+1); Outb(buffer_trans[rpp->Cont_Trans],rpp->Uart); Stats->tx_bytes+=Len; } return 0; }

- El tamaño máximo de los paquetes debe reducirse de 2048 bytes a 512 bytes, con la finalidad de que las transmisiones no resulten excesivamente largas y un error pueda interferir mucho en el funcionamiento de la red. Es decir, habrá que modificar el valor de MTU.

Cambiar el valor de la variable del preprocesador IP_RPP_MTU


Página 155 de 156


Página 156 de 156

ANEXO C. HOJAS DE CARACTERÍSTICAS

Se definen es este anexo las hojas de características ofrecidas por el fabricante de los componentes activos utilizados en el circuito de nuestra interfaz, y en la pequeña aplicación FSK realizada. Únicamente se mostrarán aquellos menos utilizados, de tal forma que no se representaran el regulador de tensión LM 7805, las memorias EPROM 27C256 o RAM 6206 ni el MAX 232.

Tampoco será presentado el DSP 56002, ya que ha sido ampliamente tratado durante el proyecto.

En definitiva, se ofrecen a continuación las características de los circuitos:

- CODEC CS 4215

- Módem FSK TCM 3105

universidad de alcalÁ escuela universitaria … · universidad de alcalÁ escuela universitaria...

Documents