Autorizada la entrega del proyecto del alumno: Fernando

Anuncio
Autorizada la entrega del proyecto del alumno:
Fernando Tomás Murillo
EL DIRECTOR DEL PROYECTO
José Daniel Muñoz Frías
Fdo.:
Fecha:
/
Vº Bº del Coordinador de Proyectos
David Contreras Bárcena
Fdo.:
Fecha:
/
/
/
RESUMEN
Este proyecto trata del desarrollo e implantación de una nueva arquitectura que
sea capaz de realizar el control de motores mediante el uso de un sistema de tiempo real
Linux-RTAI y que trabaje con Real-Time Workshop.
Para la realización de este proyecto nos hemos basado en una arquitectura
anterior que estaba disponible en la universidad. El sistema hardware de esta
arquitectura estaba basado en buses ISA y se ha adaptado a un sistema hardware más
moderno basado en buses PCI, ya que los ordenadores actuales no disponen ya de
ranuras ISA.
Los objetivos que se perseguían con la realización de este proyecto son la
obtención de una arquitectura que funcionara bajo un Sistema de Tiempo Real
compatible con Linux, la actualización de los drivers disponibles en la arquitectura
existente para que se pudiera trabajar con ésos drivers en la nueva arquitectura y la
documentación de todo el proceso de forma clara y concisa de tal forma que se facilitara
el trabajo con esta arquitectura en el futuro, tanto en la instalación como en una
posterior actualización.
Aparte de los objetivos de la universidad se han cumplido los objetivos
personales que consistían en la mejora de conocimientos en Linux y MATLAB y en el
aprendizaje satisfactorio del proceso a seguir para la realización de una nueva
arquitectura.
Para la realización de este proyecto se han utilizado las versiones de software
más actuales y estables de los distintos componentes software utilizados, además se ha
utilizado componentes hardware ya disponibles en la universidad, por ser esto de de
interés vital por parte de la universidad.
Se ha empleado una metodología en cascada para la realización de este proyecto
en la cual se han realizado las siguientes actividades:
1. Compilación óptima del kernel de Linux
I
2. Instalación de los parches RTAI
3. Instalación de la arquitectura hardware
4. Modificación de los drivers
5. Realización de un ejemplo práctico
6. Documentación
Para la realización de este proyecto ha sido imprescindible el aprendizaje por
parte del alumno de nuevas técnicas y nuevos lenguajes de programación, como el
utilizado por MATLAB, así como la consulta de manuales como el manual de Databook
PCI9052, ya que en este proyecto se ha tenido que trabajar tanto a bajo nivel (registros y
bits) como a alto nivel (lenguaje MATLAB).
Además también destacar la dificultad para la realización de este proyecto ya
que en muchas ocasiones la arquitectura de los componentes, es decir la forma de
trabajar, de éstos había cambiado respecto a la arquitectura disponible por lo que ha sido
más dificultosa la modificación de los drivers, ya que se ha tenido que realizar
modificaciones en otros módulos software distintos al del propio driver.
Los resultados han sido satisfactorios, ya que se han cumplido tanto los objetivos
que tenía puestos la universidad en este proyecto como los objetivos personales. Como
consecuencia de la consecución de estos objetivos se dispone actualmente de los
siguientes componentes que son los resultados del proyecto:
1.
Plataforma de tiempo real instalada y en ejecución.
2.
Drivers compatibles con la nueva versión de Real Time Workshop.
3.
Manuales completos y detallados de todo el proceso.
Hay que destacar en este proyecto la documentación realizada, ya que se ha
conseguido resumir los extensos manuales existentes de los diferentes componentes de
la arquitectura en un documento bastante más reducido. Además se debe destacar esta
documentación porque no existía previamente documentación alguna sobre una
plataforma de este estilo en la universidad. Esta documentación es útil tanto para la
instalación de esta arquitectura en otros equipos como para la actualización futura de
ésta.
II
Las conclusiones de este proyecto son positivas acerca del uso que se le va a dar
a la plataforma, ya que es una plataforma sencilla de manejar, porque el usuario final
tan sólo tiene que trabajar con MATLAB y más concretamente con Real Time
Workshop y no debe tener en cuenta ningún detalle sobre el diseño de la arquitectura.
Además esta plataforma es fácilmente implantable por parte de la universidad,
ya que se dispone actualmente de todos los componentes necesarios para su instalación
así como de los manuales que ilustran de forma sencilla el proceso seguido.
III
ABSTRACT
This project is about the development and implementation of a new architecture
that is able to control engines working with the following software components:
1. Linux-RTAI, a real time system.
2. Real Time Workshop
To achieve this project, we have based in a previous architecture that were
available in the university. This architecture were based in a hardware system which
works with ISA buses. The current PCs do not work with ISA buses, they work with
PCI buses. This fact means that we have had to adapt this hardware system to a new
system compatible with up to date computers.
The main objectives of this project are the obtaining of a new architecture
hardware and software capable of working with a Real Time System compatible with
Linux , the update of the drivers and the achievement of a documentation which let
anybody follow all the steps necessary to install the architecture, provide a based for a
future updating and make easier to work with this architecture.
Besides, the previous objectives there are also personal objectives that were to
improve my Linux and MATLAB knowledge and learning about how to do a new
architecture.
In this project they have been used the more up to date and stable versions of all
the software components. About hardware we have only used available products in
university because it was more the best option for the university.
To realize the protect it has been used a linear methodology where we have
defined the following activities:
1. Optimum compilation of Linux kernel
2. Installation of RTAI patches
IV
3. Hardware system installation
4. Drivers updating
5. A practical example
6. Documentation
In this project it has been indispensable the learning of new techniques and new
languages, like MATLAB’s language, moreover consulting user´s manuals like
PCI9052 Databook. In this project we have work in two opposite directions, in low
level, registers and bytes, and in high level, MATLAB´s language.
I would also like to stand out the difficulty of this project because in some
situations the way of work of the components were different in the previous architecture
than in the new. It means that we have to make big changes because the way of work of
the driver also changes. It had been necessary to make some changes in other software
furthermore the driver.
The results had been positive because all the objectives had been accomplished
including the personal objectives. Like a consequence of that we have actually available
the following components like a result of the project:
1. Real Time platform installed and in execution
2. Compatible drivers with the new Real Time Workshop version
3. User´s guide of the whole process easily to understand
I would like to emphasizes about the documentation, because the documentation
summarizes a lot of extensive user´s guides and databooks from all the different
components used in the architecture in one document not so long. Moreover the
documentation is so important because there were no documentation about the previous
architecture which exists in the university. This documentation is very useful in each
installation process and for future updates.
V
The conclusions are positive because the architecture is going to be used and it is
an easy platform to used, because the user has only to work with MATLAB and
specifically in Real Time Workshop and the user does not have to know anything about
the design of this new architecture.
Moreover this architecture is easily to implant in the university because all the
components are available in the university besides all the user guide´s in order to make
all the installation process in an easily way.
VI
Índice
Capítulo 1: Introducción................................................................................................... 1
1.1 Preámbulo............................................................................................................... 1
1.2 Objetivos................................................................................................................. 2
1.3 Estructura del documento ...................................................................................... 3
Capítulo 2: Estado del Arte .............................................................................................. 4
2.1 Introducción............................................................................................................ 4
2.2 Antecedentes........................................................................................................... 5
2.3 Arquitecturas comerciales ...................................................................................... 7
2.3.1) Sistemas SCADA ........................................................................................... 8
2.3.2) Sistemas Operativos de Tiempo Real .......................................................... 11
2.3.3) Data Acquisition Toolbox ............................................................................ 12
2.4 Arquitecturas educativas ...................................................................................... 14
2.4.1) Sistema operativo de Tiempo Real .............................................................. 15
2.4.2) Sistemas SCADA ......................................................................................... 17
2.4.3) Linux-RTAI sin MATLAB .......................................................................... 19
2.5 Alternativas a MATLAB ...................................................................................... 23
Capítulo 3: Instalación Arquitectura............................................................................... 25
3.1 Manual de Instalación del software ...................................................................... 25
3.2 Manual de Instalación del hardware..................................................................... 46
Capítulo 4: Arquitectura Software.................................................................................. 56
4.1 Descripción general .............................................................................................. 56
4.2 Módulo Driver ...................................................................................................... 57
4.2.1 Descripción general ....................................................................................... 57
4.2.2 Driver.c .......................................................................................................... 58
4.2.3 PCL812PG.H................................................................................................. 61
4.2.4 PWMX2_FPGA.H......................................................................................... 64
4.3 Módulo RTW........................................................................................................ 67
4.3.1 Descripción general ....................................................................................... 67
4.3.2 Grt_rtai.tlc ..................................................................................................... 70
4.3.3 Grt_rtai.tmf .................................................................................................... 73
4.3.4 Grt_main.c ..................................................................................................... 77
4.4 Módulo Bridge...................................................................................................... 79
4.4.1 Descripción general ....................................................................................... 79
4.4.2 Datos posibles en los Registros ..................................................................... 81
4.4.3 PLXLinux ...................................................................................................... 86
Capítulo 5: Instalación drivers........................................................................................ 87
5.1 Instalación PCL812PG ......................................................................................... 87
5.2 Instalación PWM .................................................................................................. 94
5.3 Manual Ejecución ............................................................................................... 102
Capítulo 6: Conclusiones.............................................................................................. 106
Bibliografía................................................................................................................... 107
ANEXO A: Valoración Económica ............................................................................. 109
ANEXO B: Componentes ............................................................................................ 110
VII
VIII
Capítulo 1: Introducción
1.1 Preámbulo
En el presente proyecto fin de carrera se ha desarrollado e implementado una
arquitectura de tiempo real que permite realizar el control de motores trifásicos. Esta
arquitectura funciona con el Sistema Operativo Linux y con Real Time Workshop, que
es un módulo de MATLAB que permite la creación de modelos matemáticos que
funcionan en tiempo real.
Existía anteriormente una arquitectura parecida a la desarrollada, debido a lo
cual la arquitectura desarrollada se realizado actualizando la arquitectura disponible
para compatibilizar los dispositivos hardware ya disponibles con los nuevos dispositivos
hardware y software. Además se ha realizado una documentación que está incluida en el
presente documento que ayudará a las futuras instalaciones y actualizaciones.
Esta arquitectura ha sido implantada en el laboratorio de potencia y servirá para
realizar las prácticas de Control de Motores y las prácticas de Sistemas de Tiempo Real
en el futuro y otros trabajos que se necesiten realizar en un futuro próximo.
El presente documento no sólo pretende ser un documento para la rápida
instalación de esta arquitectura en otros equipos del mismo laboratorio. También
pretende ser una guía para entender con mayor facilidad el funcionamiento de esta
arquitectura para poder actualizar la arquitectura de forma más fácil e intuitiva en el
futuro.
A pesar de la existencia en esta arquitectura de muchos dispositivos hardware en
este proyecto no se ha construido ningún dispositivo hardware. Aparte tampoco se ha
realizado ninguna elección sobre el tipo de arquitectura, ya que este proyecto tenía
requerimientos hardware que implicaban el diseño de la arquitectura finalmente
desarrollada.
1
Este proyecto sólo abarca el desarrollo e implantación informática de esta la
arquitectura que se explicará a lo largo de este documento.
1.2 Objetivos
Los objetivos que se han buscado en el desarrollo de esta plataforma son:
™ Obtención de una plataforma RTAI-Linux: el primer objetivo que se
cumplió fue la obtención de un Sistema de Tiempo Real que
funcionara bajo Linux. Esta plataforma debía ser estable y cumplir
los requerimientos que tiene cualquier Sistema de Tiempo Real.
™ Implantación de la arquitectura hardware: además en este objetivo
se incluye explícitamente el uso del hardware del que dispone la
universidad (tarjeta PCL812PG y tarjeta PWM). El cumplimiento de
este objetivo es un paso intermedio de cara a desarrollar la plataforma
que quería realizarse.
™ Actualización de los drivers: con este objetivo se pretendía que el
sistema actualizado funcionara de igual manera que el sistema
antiguo, ya que el sistema antiguo cumple los requerimientos que se
le piden al nuevo sistema.
™ Implantación de la arquitectura software: además en este objetivo se
incluye explícitamente el uso de software disponible en la
universidad como es Real Time Workshop. El cumplimiento de este
objetivo es un paso intermedio de cara a desarrollar la plataforma que
quería realizarse.
™ Documentación de todo el proceso: se pretende conseguir una
documentación clara y sencilla de entender que permita instalar de
forma intuitiva la nueva arquitectura.
2
1.3 Estructura del documento
El trabajo se organiza de la siguiente manera:
Capítulo 2: Estado del Arte. En este capítulo se plasma la situación previa de
los Sistemas de control de motores en la universidad así como las distintas posibles
soluciones para el control de motores que existen fuera de nuestra universidad.
Capítulo 3: Instalación Arquitectura. En este capítulo se detalla el proceso de
instalación de todos los componentes descritos anteriormente de forma que se acabe
creando la arquitectura deseada.
Componentes. En este capítulo se explican todos los componentes de la
arquitectura para conocer sus funcionalidades y el papel que desempeña cada uno dentro
de nuestra arquitectura.
Capítulo 4: Arquitectura Software. En este capítulo se detalla el trabajo
realizado para integrar los drivers de las tarjetas en esta arquitectura y en Real Time
Workshop, así como los módulos de los drivers.
Capítulo 5: Instalación drivers. En este capítulo se detalla el proceso de
instalación de ambos drivers así como el proceso que hay que seguir para ejecutarlos.
3
Capítulo 2: Estado del Arte
2.1 Introducción
En este capítulo se van a comentar los aspectos más relevantes del control de
motores en diferentes ámbitos, tanto de arquitectura como de herramientas que se
pueden utilizar para el control de estos motores.
Este capítulo pretende dar una rápida referencia de los sistemas y posibilidades
que se pueden utilizar para el control de motores mediante sistemas de tiempo real.
Además pretende dar a conocer alternativas posibles al uso de MATLAB.
En este capítulo se comentará al principio la plataforma de la que se disponía en
la universidad para luego pasar a dar a conocer el estado del arte en el control de
motores mediante una arquitectura de tiempo real, tanto en el mundo industrial como en
el mundo académico. Por último se comentará las posibles alternativas a MATLAB, que
es uno de los pilares en nuestro proyecto.
Este capítulo se divide en los siguientes apartados:
o Antecedentes
o Arquitecturas Comerciales
o Arquitecturas Educativas
o Alternativas a MATLAB
4
2.2 Antecedentes
El antecedente más cercano para el control de motores con un sistema
informático que cumpla los requisitos necesarios para ser denominado de tiempo real es
la desarrollada por Omar Pinzón Ardila para la realización de su tesis “Compensación
Selectiva de Armónicos Mediante Filtros Activos de Potencia”, que tiene algunas
similitudes con la que se va a desarrollar en este proyecto, pero también grandes
diferencias.
Este proyecto intenta conseguir algunos de los objetivos que se alcanzaron en
esta tesis pero en una plataforma más actual. Esta plataforma aún está disponible en el
Laboratorio de I+D de la Universidad. Esta plataforma aparece representada en el
siguiente esquema:
5
Los componentes utilizados en este sistema son:
™
PC Pentium II con un Debian con kernel 2.4.22, que es una
distribución de Linux y RTAI versión 3.1.
™
PCI Bridge PLX 9052, que está descrito en el ANEXO B.
™
Tarjeta de adquisición de datos Tagle PCI703S (indicada en la
imagen como A/D 16 Ch), que consta de 16 entradas analógicas de muestreo
simultáneo, resolución de 14 bits y frecuencia máxima de muestreo por canal de
400 KHz.
™
Tarjeta de modulación PWM, que ha sido desarrollada por
D. Omar Pinzón Ardila para la realización de su tesis “Compensación Selectiva
de Armónicos Mediante Filtros Activos de Potencia”.
™
Matlab, Simulink y Real Time Workshop como programa de
control y obtención de datos de los inversores y filtros de potencia.
No vamos a entrar en el resto de la arquitectura porque se sale del ámbito
informático de nuestro proyecto.
6
2.3 Arquitecturas comerciales
En este punto nos vamos a centrar en las soluciones mayoritarias o más
relevantes para nuestro proyecto que la industria implementar a la hora de implantar
sistemas de tiempo real que controlen sus motores. En este punto se darán unas
pequeñas pinceladas de los sistemas usados en la industria y de productos utilizados
para controlar sus motores. En este punto nos hemos centrado más en las diferentes
opciones que hay respecto a arquitectura que en productos concretos, ya que la elección
de una arquitectura frente a otra determinará en gran medida el uso de los productos que
se utilizarán finalmente. Los sistemas y productos más relevantes encontrados en la
industria son:
1. Sistemas SCADA
2. Sistemas Operativos de Tiempo Real
3. Data Acquisition Toolbox
7
2.3.1) Sistemas SCADA
SCADA es un acrónimo de Supervisory Control And Data Acquisition (control
y adquisición de datos de supervisión). Los sistemas SCADA utilizan PCs y
comunicaciones para automatizar el monitoreo y control de procesos industriales. Estos
sistemas se utilizan en la mayoría de los ambientes industriales complejos o
geográficamente dispersos ya que pueden recoger la información de una gran cantidad
de fuentes muy rápidamente, y la pueden presentar a un operador.
Hoy, los proveedores de SCADA están diseñando sistemas que están pensados
para resolver las necesidades de muchas industrias con módulos de software específicos
de cada industria que están disponibles para proporcionar las funcionalidades requeridas
comúnmente. La mayoría de los sistemas SCADA que son instalados hoy se está
convirtiendo en una parte integral de de la información corporativa. Estos sistemas ya
no son vistos por la gerencia simplemente como herramientas operacionales, sino como
un recurso importante de información útil para el negocio.
La arquitectura de un sistema SCADA es la siguiente:
8
Esta arquitectura está compuesta por tres componentes:
ƒ
Múltiples Unidades de Terminal Remota (RTU)
ƒ
Estación Maestra y PC con un interfaz
ƒ
Infraestructura de comunicación
RTU
La RTU se conecta al equipo físicamente, es el centro del sistema y es un
componente básico ya que realiza las siguientes funciones:
•
Adquisición de datos. Recolección de datos de los RTU's.
•
Trending. Guardar los datos en una base de datos, y ponerlos a
disposición de los operadores en forma de gráficos.
•
Procesamiento de Alarmas. Analizar los datos recogidos de los RTU's
para ver si hay una situación anormal, y alertar a personal de operaciones
sobre las mismas.
•
Control. Control iniciado por el operador.
•
Visualizaciones. Gráficos del equipamiento actualizado para reflejar los
datos.
•
Informes. La mayoría de los sistemas SCADA tienen un ordenador
dedicado a la producción de reportes conectado en red (LAN o similar)
con el principal.
•
Mantenimiento del Sistema Mirror, es decir, mantener un sistema
idéntico con la capacidad segura de asumir el control inmediatamente si
el principal falla.
•
Interfaces con otros sistemas. Transferencia de datos desde otros
sistemas corporativos para, por ejemplo, el procesamiento de órdenes de
trabajo, de compra, la actualización de bases de datos, etc.
•
Seguridad. Control de acceso a los distintos componentes del sistema.
•
Administración de la red. Monitoreo de la red de comunicaciones.
9
•
Administración de la Base de datos. Agregar nuevas estaciones,
puntos, gráficos, puntos de cambio de alarmas, y en general, reconfigurar
el sistema.
•
Aplicaciones especiales. Casi todos los sistemas SCADA tendrá cierto
software de aplicación especial, asociado generalmente al monitoreo y al
control de la planta.
•
Sistemas expertos, sistemas de modelado. Los más avanzados pueden
incluir sistemas expertos incorporados, o capacidad de modelado de
datos.
La infraestructura de comunicación y la estación maestra dependen de cada
sistema particular y no tienen funciones reseñables.
Los sistemas SCADA más utilizados son:
™ FactoryLink de USDATA, utilizado para recolectar información
crítica.
™ Paradym-31 de Advantech, para problemas de automatización.
™ Virgo 2000 de AlterSys Inc., para generar controles virtuales y
compatibles con QNX (sistema operativo de tiempo real).
™ Cimplicity de GE FAPUC, que proporciona información en
tiempo real de diversos procesos productivos.
™ HYBREX de Siemens, que permite realizar cambios en planta
virtuales para medir el impacto sin riesgo alguno.
10
2.3.2) Sistemas Operativos de Tiempo Real
Formalmente un sistema operativo de tiempo real es un sistema operativo que ha
sido desarrollado para aplicaciones de tiempo real. Por ello se le exige corrección en sus
respuestas bajo unos requerimientos estrictos de tiempo. Dentro de esta definición
caben muchas opciones diferenciadas y diferentes requisitos de tiempo (Sistemas
Operativos de Tiempo Real Estricto y Sistemas Operativos de Tiempo Real No
Esctricto). Existe una gran diversidad de Sistemas Operativos de Tiempo Real con
diferentes características y diferentes requisitos por lo que en este apartado sólo vamos a
definir los más relevantes, que son:
1. VxWorks: es un sistema de tiempo real basado en UNIX. Tiene un planificador
muy potente que se basa en la prioridad para la planificación de las tareas que
puede interrumpir rápidamente la ejecución de cualquier tarea, aparte puede
comunicar los diferentes procesos para mejorar la sincronización, y además posee
un sistema propio de ficheros. Las características diferenciadoras de VxWorks es
el direccionamiento de memoria eficiente gracias a su gestor POSIX, posibilidad
de uso en multiprocesador, su interfaz de usuario y la supervisión de
funcionamiento.
2. QNX: está basado en Unix y está desarrollado principalmente para su uso en
dispositivos empotrados., aunque también está orientado a su utilización en
microcontroladores y sistemas críticos. Está disponible para una gran variedad de
arquitecturas (x86, MIPS, PowerPC, SH4, etc.…).QNX está basado en una
estructura de microkernel, que proporciona una alta estabilidad frente a fallos de
dispositivos o aplicaciones. Tiene también un sistema de ventanas.
3. RTEMS (Real-Time Executive for Multiprocessor Systems): está específicamente
diseñado para el diseño de aplicaciones en sistemas empotrados. Está diseñado
para poder soportar las máximas restricciones temporales posibles así como para
ser igualmente compatible con otros estándares libres. Se puede implementar
11
dentro de otro Sistema Operativo como puede ser Windows, MacOS o las
diferentes distribuciones de Linux.
2.3.3) Data Acquisition Toolbox
Dentro de MATLAB existen unas librerías que comúnmente se llaman toolbox y
están especializadas en un aspecto concreto dentro de todas las funcionalidades que
puede aportar MATLAB y que se explicará más delante de forma más detallada. Entre
las tarjetas que pueden trabajar con esta toolbox están la tarjeta de adquisición de datos
que vamos a utilizar en este proyecto.
Una de estas toolbox es la Data Acquisition Toolbox, una toolbox que
proporciona un juego completo de funcionalidades para la E/S digital y analógica de
una gran variedad de Tarjetas de Adquisición. Esta toolbox permite configurar este tipo
de hardware, leer los datos con MATLAB y Simulink para el análisis de sus datos y el
envío.
Esta toolbox funciona gracias a su comunicación con el driver de la tarjeta que
trabaja a bajo nivel. Además de la comunicación con el driver la toolbox hace de puente
entre este driver y el usuario, tal y como se muestra en la siguiente imagen:
Con esta toolbox se pueden personalizar las adquisiciones, acceder a los
registros de la tarjeta, e incorporar el análisis y la visualización de MATLAB y de más
toolboxes relacionadas. Esta toolbox permite usar MATLAB como un ambiente
integrado para apoyar la adquisición de datos, el análisis de datos y el proceso de
12
desarrollo de aplicaciones que trabajen con estas tarjetas. Esta toolbox también funciona
en Simulink con bloques que permiten incorporar datos o la configuración de hardware
directamente en Simulink. Se pueden verificar y validar los modelos contra datos,
medidos como parte del proceso de desarrollo de los modelos. Las características más
destacadas de esta toolbox son:
™
Controla y se comunica con una variedad de tarjetas de adquisición de
datos estándar de industria.
™
Adquiere datos desde programa, mediante MATLAB o Simulink para
el análisis inmediato.
™
Proporciona un ambiente integrado para la adquisición de datos, el
análisis, y la visualización.
™
Funciona tanto en modo interrupción como en modo continuo.
™
Configura y tiene acceso sobre la entrada analógica, la salida
analógica, y la E/S digital.
™
Uso de un osciloscopio virtual mediante software (SoftScope) para la
demostración gráfica de datos.
™
Interfaces que comunican
rasgos específicos de cada dispositivo,
como canales específicos, adquisiciones de varios canales y E/S análoga
mediante buffer entre otros.
™
Controla las adquisiciones mediante triggers tanto de software como de
hardware.
™
Proporciona un interfaz para la sustitución fácil de las pasarelas de
hardware.
13
2.4 Arquitecturas educativas
En este punto nos vamos a centrar en las soluciones obtenidas por distintas
universidades para la realización de prácticas de control de motores o de sistemas de
tiempo real. En este punto no explicaremos las soluciones más complejas que se utilizan
en grandes sistemas industriales que abarcan desde el desarrollo de arquitecturas
hardware específicas, como pueden ser los sistemas empotrados, hasta el desarrollo e
implantación de software específico.
Existen infinidad de opciones que han sido escogidas por diferentes
universidades, pero en este apartado nos vamos a centrar en las más cercanas, tanto por
parecido de arquitectura como de motores que va a controlar esta arquitectura. En estas
soluciones nos hemos centrado en el análisis del software utilizado, ya que el análisis y
la comparativa del hardware que se utiliza en este proyecto quedan fuera del alcance de
éste.
Las opciones más utilizadas en los laboratorios de control de motores o de
procesos de otras universidades son las siguientes:
1.
Uso de un Sistema Operativo de Tiempo Real junto con los drivers
correspondientes.
2.
Uso de sistemas SCADA
3.
Uso de Linux-RTAI junto con los drivers correspondientes sin utilizar
MATLAB
14
2.4.1) Sistema operativo de Tiempo Real
Los componentes básicos que se utilizan en este proyecto son:
•
PC de desarrollo
•
PC de ejecución
•
Robot
La arquitectura del sistema es la siguiente:
El dispositivo que nos interesa estudiar en este proyecto es la arquitectura del PC
de desarrollo ya que el target tan sólo tiene la conexión con el robot y es en el PC de
desarrollo donde se realizan todas las actividades. Además el estudio del robot utilizado
en este laboratorio carece de interés para este proyecto.
15
El PC de desarrollo tiene los siguientes programas instalados:
•
RTEMS
•
GCC
•
GDB
RTEMS
En este proyecto la implementación se ha realizado en un Debian, que es una
distribución de Linux que se explicará más adelante en el Anexo B.
GCC y GDB
GCC es el compilador de C de código libre mientras que GDB es el depurador,
ambos son los estándares de Linux y se rigen mediante la licencia GNU de código libre.
Conclusiones:
Las conclusiones de este proyecto es que se trata de un proyecto muy específico
pero nos sirve para conocer una forma de controlar los motores en un laboratorio de una
universidad (UPM). La gran diferencia es que en este caso el laboratorio se basa en
hacer mover el robot sin necesitar de él apenas ningún cálculo con lo que no necesita
driver específico aparte del que venga en RTEMS.
El problema de este laboratorio es que la licencia de RTEMS es cara, mientras
que el aspecto positivo es que el Sistema de Tiempo Real montado es eficaz y eficiente,
quizá demasiado para lo que se va a realizar. Aparte el gran problema de esta
arquitectura es el uso de dos ordenadores para realizar estás prácticas, uno en el que se
programa y otro que es el que se acaba comunicando con el robot.
16
2.4.2) Sistemas SCADA
Esta es la arquitectura utilizada para el laboratorio de control de universidad
EUPVG-UPC, que se basa en los sistemas SCADA explicados anteriormente, y en la
herramienta Lab-View.
Los sistemas que se implantan en los laboratorios de control de algunas
universidades (EUPVG-UPC) ofrecen capacidades simples de monitoreo y control,
comparándolos con sus homólogos industriales. Los PCs recolectan los datos de los
motores controlados gracias a comandos de control, y la presentación de la información
sobre una pantalla de CRT.
LAB-VIEW
Las prácticas del laboratorio de control se realizan mediante Lab-View que es
una herramienta diseñada especialmente para monitorizar, controlar, automatizar y
realizar cálculos complejos de señales analógicas y digitales capturadas a través de
tarjetas de adquisición de datos. Esta herramienta es en realidad un lenguaje de
programación que permite la realización de programas para SCADA de forma fácil e
intuitiva y su integración con programas matemáticos como en este caso es el
MATLAB.
Este programa incluye librerías que permiten realizar el proceso de adquisición,
análisis y presentación de datos.
Esta herramienta es de código abierto y se basa en dos partes:
1.
Front Panel (panel frontal): esta parte es el interfaz de usuario en
la monitorización o control del sistema. Este contiene controles e indicadores y
existe una gran variedad de ellos, pero además incluso se pueden diseñar
controles e indicadores personalizados.
2.
Block diagram (diagrama de bloque): esta parte es la lógica de
aplicación. En ella están todos los controles e indicadores interconectados,
pareciéndose mucho a un diagrama de esquema eléctrico.
17
Conclusiones:
Este es el modo más sencillo de realizar el control de motores, ya que sólo
debemos tener la herramienta necesaria. El gran inconveniente de este sistema es que
debemos utilizar PCs dedicados al control únicamente, de hecho para un buen
funcionamiento deberíamos utilizar varios, para tener una infraestructura de tipo
SCADA.
Además para la implantación de este sistema se debe obtener el software
SCADA que no es abierto, con lo que se deberían obtener las licencias
correspondientes, no nos haría falta para Lab-view, pero si queremos probar las
aplicaciones realizadas con Lab-view necesitamos el sistema SCADA. En definitiva
esta es una buena solución para sistemas industriales pero no cumple muchos de los
requisitos deseados para nuestro laboratorio.
18
2.4.3) Linux-RTAI sin MATLAB
En este punto tan sólo se va a analizar la arquitectura utilizada para la
realización de este proyecto.
Los componentes que se utilizan en este proyecto tanto software como hardware
son:
•
RTAI
•
ADEOS
•
Driver
•
Tarjeta desarrollada por DISAM (tarjeta propia)
RTAI
La arquitectura del sistema operativo es Linux-RTAI que es la misma que se ha
utilizado en este proyecto, por lo tanto será explicada más detalladamente en el Anexo
B.
ADEOS
ADEOS que proporcionar un entorno flexible para compartir los recursos
hardware para múltiples sistemas operativos ó múltiples instancias de un mismo sistema
operativo. ADEOS utiliza una arquitectura nano-kernel, que consigue repartir las
interrupciones y los eventos del sistema a los múltiples kernels (normalmente SO
completos) gracias al uso de lo que ha llamado abstractamente "dominio".
ADEOS activa múltiples dominios, que existen simultáneamente sobre el mismo
hardware. Ninguno de estos dominios necesariamente conoce la existencia del resto,
pero todos ellos si conocen de la existencia de ADEOS. Un dominio puede ser un
Sistema Operativo completo, pero no necesariamente. Un dominio es un componente
software del kernel base al cuál ADEOS puede notificar:
19
•
Las interrupciones hardware.
•
Llamadas al sistema de las aplicaciones Linux.
•
Eventos del sistema lanzados por el kernel de Linux.
•
Otros eventos que personalicemos nosotros.
ADEOS puede crear dominios gracias a que sigue el siguiente esquema:
El modo de trabajar de ADEOS se basa en los dominios y en un módulo de
software que procesa las interrupciones de los diferentes dominios, incluyendo las
posibles prioridades que pudieran tener estos dominios.
El uso de ADEOS es importante en las siguientes situaciones:
• Controlar de forma determinista el flujo de interrupciones hardware
usando una capa software antes de que el kernel de Linux las procese.
Este control incluye la interceptación, el enmascarado y/o la priorización
de las interrupciones.
• Monitorizar
las llamadas al sistema de Linux, añadiendo más
información y sin tener que modificar el código de las llamadas al
sistema.
20
• Obtención de un mecanismo para monitorizar los eventos internos que
ocurren en el kernel de Linux como pueden ser la planificación de tareas,
la creación de procesos ó las señales que capturan las tareas.
Driver
Este driver ha sido directamente realizado en C sin ningún tipo de interconexión
con algún programa matemático o científico. Por ello este driver no tiene gran
capacidad de cálculo o de obtención de series de datos útiles para nuestro proyecto sino
que sólo se dedica al control de varias plataformas hardware. Por ello no entraremos en
detalles de la implementación de las funciones del driver. Tan sólo decir que este driver
se descompone en dos módulos llamados rtai_ensa.h y rtai_ensa.c. La siguiente imagen
muestra el esquema de funcionamiento de este driver:
21
Tarjeta
Esta es una tarjeta creada específicamente por DISAM (Departamento de
Ingeniería de Sistemas y Automática) de la Universidad Politécnica de Madrid. Por lo
tanto tan sólo decir de la tarjeta utilizada que tiene 32 entradas y 32 salidas y tiene un
funcionamiento que se puede ilustrar en el siguiente diagrama de bloques:
Conclusiones:
Las conclusiones de este proyecto es que se trata de un proyecto muy específico
y básico del cual sirve más para aprender el uso de los Sistemas de Tiempo Real que
para un laboratorio de control de motores ya que los aspectos controlados por el driver
son pobres para lo que se pretende realizar en este proyecto.
Uno de los aspectos positivos de este proyecto respecto al nuestro es el uso de
ADEOS que permite el control de diversos dispositivos a la vez y de sistemas con
múltiples sistemas operativos.
22
2.5 Alternativas a MATLAB
En este punto se van a describir de forma general las posibles alternativas a otro
de los pilares de nuestro proyecto, el uso de un programa matemático que en nuestro
caso hemos decidido que fuera MATLAB.
MATLAB es el programa de cálculo matemático más conocido y se explicará
con más detenimiento en el siguiente capítulo. A pesar de esto existe infinidad de
alternativas a MATLAB, de las cuales hemos escogido las más relevantes.
Scilab: es un paquete de software científico para cómputos numéricos que
proporcionan un ambiente matemático para la ingeniería y usos científicos. Scilab es
una alternativa a MATLAB de código abierto, aunque su uso está bastante limitado a
ambientes educativos e industriales. Scilab incluye una gran diversidad de funciones
matemáticas con la posibilidad de añadir interactivamente programas de diversos
lenguajes de programación (C, C ++, Fortran…).
Esta utilidad ha implicado la mejora del soporte de estructuras de datos, un
intérprete y un lenguaje de programación de alto nivel. Scilab ha sido diseñado para ser
un sistema abierto donde el usuario puede definir nuevos tipos de datos y operaciones.
Aparte de las principales utilidades de Scilab tiene muchas más e infinidad de
extensiones. Las principales utilidades de Scilab son:
o Animación gráfica de 2-D y 3-D
o Simulación: resolución de ODE (Open Dynamics Engine) y de DAE
(Differential Algebraic Equations).
o Scicos: modelador y simulador de sistemas híbridos dinámicos.
o Control fuerte y clásico, optimización LMI.
o Procesamiento de señales.
o Interfaz con Fortran, Tcl/Tk, C, C ++, Java y LabVIEW.
o Metanet: gráficos y redes.
23
Octave: es un lenguaje de programación de alto nivel especialmente preparado
para cálculos numéricos y matemáticos. Octave proporciona un interfaz de línea de
comando que se llama KOctave.
KOctave sirve para solucionar problemas lineales y no lineales, y para realizar
otros experimentos numéricos que utiliza un lenguaje que es sobre todo compatible
con Matlab. Además puede ser utilizado lenguaje orientado a su uso en programas
batch. Octave es una solución de código abierto con lo cual se puede distribuir y
modificada siguiendo la GPL (General Public Licence) de GNU.
Octave tiene diversos instrumentos para solucionar problemas de álgebra
comunes numéricos lineales, encontrando las raíces de ecuaciones no lineales,
integrando funciones ordinarias, manipulando polinomios, e integrando ecuaciones
ordinarias diferenciales y diferenciales algebraicas. Estas funcionalidades primarias son
fácilmente extensibles y personalizables gracias a funciones definidas por usuario
escritas en Octave, o usando módulos escritos en C ++, C, Fortran, u otras lenguajes de
programación.
24
Capítulo 3: Instalación Arquitectura
3.1 Manual de Instalación del software
Esta es una guía de los pasos seguidos para realizar la compilación del núcleo
con las opciones necesarias para después instalar RTAI. En esta guía tan sólo se hace
referencia a las opciones y pasos fundamentales y seguidos en la primera compilación
del kernel e instalación de RTAI en el laboratorio. En esta instalación se suponemos que
tenemos en el ordenador Linux y Matlab.
Los pasos a seguir son:
1. Para empezar nos pondremos en el usuario root, ya que vamos a necesitar este
usuario para realizar unas cuantas operaciones. Nos ponemos como usuario root
con el siguiente comando: sudo bash. Entonces nos pedirá una contraseña a la
que pondremos la contraseña respectiva.
2. Después nos bajaremos el RTAI que esta disponible en www.rtai.org y bajarnos
en el repositorio RTAI la versión más novedosa (en el caso de ejemplo es la
3.4).
3. Después debemos copiar el RTAI descargado al directorio /usr/src, esto se
realiza mediante el comando:
cp (ruta de directorios donde estuviera)/rtai-(versión).tar.bz2 /usr/src.
Después deberemos movernos a este directorio para ello utilizamos el siguiente
comando: cd /usr/src.
4. Ahora deberemos comprobar si en esa carpeta existe una versión anterior del
RTAI, que deberemos borrar en caso de que exista, para ello utilizamos el
siguiente comando: rm rtai.
5. Ya en la carpeta deberemos desempaquetarlo, para ello utilizaremos el siguiente
comando: tar vxjpf rtai-(versión).tar.bz2.
25
6. Ya con nuestro RTAI desempaquetado procederemos a la creación de un enlace
simbólico para nuestra versión RTAI, esto se realiza mediante el comando:
ln -s rtai-(versión) rtai.
7. Después de instalarlo deberemos mirar dentro del directorio
/usr/src/rtai/base/arch/i386/patches/ para comprobar que existe el parche para la
versión de kernel del linux que vamos a instalar posteriormente. Tras comprobar
esto pasaremos a obtener el kernel deseado.
8. Antes de obtener el kernel y compilarlo necesitamos unos paquetes específicos
que son los paquetes build-essential y el kernel-package. Ambos paquetes si se
posee una conexión a Internet se pueden obtener mediante el siguiente comando:
apt-get install build-essential kernel-package.
También descargaremos paquetes que aunque no sean necesarios para la
compilación del kernel si lo son para la selección de opciones a utilizar, para ello
utilizaremos los siguientes comandos: apt-get install libncurses5-dev y
apt-get install libqt3-dev.
9. Debemos ir a la siguiente dirección web www.kernel.org donde encontraremos
la última versión del kernel de linux. Si queremos una versión anterior del kernel
debemos ir a la siguiente página en la que aparecen todos los kernels
www.kernel.org/pub/linux/kernel. En la primera instalación hemos utilizado el
kernel 2.6.17. Después de elegir el kernel deberemos descargarlo. Al finalizar
este paso tendremos el archivo linux-version.tar.bz2 en el directorio que
hayamos decidido.
10. Después debemos copiar el kernel descargado al directorio /usr/src, esto se
realiza mediante el comando:
cp (ruta de directorios donde estuviera)/linux-source-(versión).tar.bz2
/usr/src. Después deberemos movernos a este directorio para ello utilizamos el
siguiente comando: cd /usr/src.
11. Ahora deberemos comprobar si en esa carpeta existe un enlace a un antiguo
kernel de linux que hayamos compilado anteriormente, si este es nuestro caso
deberemos borrarlo, para ello utilizamos el siguiente comando: rm linux.
26
12. Ahora ya no tenemos ningún enlace a linux en la carpeta /usr/src, por lo cual ya
podemos proceder a descomprimir el archivo en esta carpeta, para lo cual
utilizaremos el siguiente comando: tar vxjpf linux-source-(versión).tar.bz2.
Esto crea un directorio que se llamará linux-source-versión.
13. Ya con nuestro kernel desempaquetado procederemos a la creación de un enlace
simbólico para este kernel, esto se realiza mediante el comando:
ln -s linux-source-(versión) linux.
14. Ahora debemos parchear el kernel que queremos compilar (en el que queremos
instalar el RTAI), y lo parcheamos para incluir el RTAI en este kernel, para ello
deberemos primero ir a la carpeta linux con el comando: cd /usr/src/linux.
Luego deberemos parchear el kernel con la siguiente línea de comando:
patch -p1 < /usr/src/rtai/base/arch/i386/patches/hal-linux-(versión).patch
15. Ahora deberemos seleccionar el tipo de ventana que utilizaremos para la
selección de opciones en la compilación de nuestro kernel. Para ello primero nos
situaremos en el directorio del enlace creado con el comando: cd /usr/src/linux.
Después ya en esa carpeta utilizaremos cualquiera de estos dos comandos:
make menuconfig o make xconfig. La imagen que aparecerá será la siguiente:
27
16. Ahora deberemos escoger las opciones correctas, las opciones aquí especificadas
son imprescindibles para el funcionamiento de RTAI, en las demás opciones se
aconseja dejar las que vienen por defecto si no se sabe muy bien lo que se está
haciendo. Las opciones que tenemos que poner obligatoriamente son las
siguientes:
En Code Maturity Level options:
En General Setup:
28
En Loadable Module Support:
En Processor Type and Features:
29
En Power Management Options:
30
En Device Drivers:
En File Systems:
31
Las imágenes que no aparecen es porque se dejan las opciones que vienen por
defecto, en caso de error en alguna de estas opciones, habría que seleccionarla si
es por omisión o deseleccionarla si falla al compilar ese módulo.
17. Ahora tenemos que compilar nuestro kernel e instalarlo, para ello ejecutaremos
el siguiente comando:
make clean && make && make modules_install && make install.
La compilación e instalación del kernel es un paso muy largo y no requiero
ninguna interacción por parte del usuario. Este paso tarda del orden de una hora.
Después de la ejecución hay que asegurarse de que todo ha ido correctamente y
no hay ningún fallo.
18. Después de este paso debemos comprobar que se nos han creado todos los
ficheros necesarios para la ejecución e instalación del nuevo kernel. Para ello
iremos al directorio /boot con el siguiente comando: cd /boot. Allí deberemos
tener los siguientes ficheros:
System.map-(versión del kernel)-identificador
vmlinuz-(versión del kernel)-identificador
initrd.img-(versión del kernel)-identificador.
Si no existe este último fichero lo crearemos con el siguiente comando:
mkinitrd -o /boot/initrd.img-(versión del kernel)-identificador (versión del
kernel).
32
19. Después deberemos editar el menú GRUB para poder tener el kernel accesible,
para ello utilizamos el siguiente comando: vi /boot/grub/menu.lst. El menú
GRUB deberá tener una entrada como la siguiente:
title
root
identificador
(hd0,1)
kernel
/boot/vmlinuz-(versión del kernel)-identificador root = /dev/hda3 ro
quiet splash
initrd /boot/initrd.img-(versión del kernel)-identificador
savedefault
boot
20. Después de compilar el kernel debemos asegurarnos de que todo funciona
correctamente, para ello reiniciamos con el comando: /sbin/reboot. Aquí
podemos hacer algunas cosas optativas como guardar los cambios o editar el
menú de arranque, para escoger otras opciones pero recomiendo utilizar las que
pongo en el punto anterior ya que son sobre las que se ha hecho la instalación
inicial.
21. Ahora debemos instalar Mesa, aunque en nuestro ordenador tengamos una
versión previa instalada, para instalarlo primero iremos a un directorio temporal
con el siguiente comando: cd /tmp. Después deberemos ir a la página web
http://www.mesa3d.org/ . Descargarse en /tmp.
22. Ahora deberemos desempaquetarlo, para ello utilizaremos el siguiente comando:
tar vxjpf MesaLib-(versión).tar.bz2.
23. Después de descargar Mesa iremos al directorio donde está Mesa con el
siguiente comando: cd Mesa-(versión).
24. Una vez allí instalaremos la librería con los siguientes comandos:
make linux-x86-static para compilar y make install para instalar.
33
25. Ahora descargaremos la librería EFLTK en un directorio temporal con los
siguientes comandos: cd /tmp y
cvs-d:pserver:[email protected]:/cvsroot/ede login(cuando
pregunta por contraseña ENTER)
y
cvs -z3 -d:pserver:[email protected]:/cvsroot/ede co efltk.
Si no funciona la línea de comando podemos descargarlo de la siguiente
dirección web: http://sourceforge.net/projects/ede. Descargarse en /tmp.
26. Ahora deberemos desempaquetarlo, para ello utilizaremos el siguiente comando:
tar vxjpf efltk-(versión).tar.bz2.
27. Después de descargar EFLTK iremos al directorio donde está EFLTK con el
siguiente comando: cd efltk.
28. Ahora deberemos darnos los permisos necesarios para poder ejecutar los
siguientes comandos con el comando: chmod 777 *
29. Una vez allí configuraremos la librería con el siguiente comando:
./efltk-config.in --prefix=/usr/local –multithread. Después de esto
instalaremos la librería con los siguientes comandos: ./emake y
./emake install.
30. Después de instalar EFLTK deberemos añadir al archivo /etc/ld.so.conf la
siguiente entrada: /usr/local/lib/
31. Después de esto actualizaremos la librería con el siguiente comando:
/sbin/ldconfig. Por último reiniciaremos para comprobar que hemos instalado
correctamente esta librería.
32. Ahora instalaremos Comedi y Comedilib, que son muy importantes. Para ello
nos moveremos a /usr/src con el siguiente comando: cd /usr/src.
34
33. Después iremos a la página web www.comedi.org/download y descargaremos
la versión 0.7.71 de Comedi y 0.7.22 de Comedilib. Para ello en la página web
deberemos seleccionar el archivo comedi-0.7.71.tar.gz y el archivo
comedilib-0.7.22.tar.gz y descargarlos en usr/src o copiarlos después con el
comando: cp (ruta de directorios donde estuviera)/comedi0.7.71.tar.gz/usr/src y cp (ruta de directorios donde estuviera)/comedilib0.7.22.tar.gz /usr/src
34. Después de la descarga los descomprimiremos con los siguientes comandos:
tar -xzvf comedi-0.7.71.tar.gz y tar -xzvf comedilib-0.7.22.tar.gz
35. Después crearemos un enlace simbólico, pero antes borraremos el enlace
antiguo, en caso de tenerlo, con el comando: rm –f comedi.
Para la creación del enlace simbólico utilizaremos el siguiente comando:
ln -fs comedi-(versión) comedi.
36. Ahora configuraremos e instalaremos Comedilib. Primero lo configuramos con
los siguientes comandos: cd /usr/src/comedilib-(versión) y
./configure --sysconfdir=/etc. Para la instalación utilizaremos los siguientes
comandos: make, make install y make dev.
37. Ahora configuraremos e instalaremos Comedi. Primero lo configuramos con los
siguientes comandos: cd /usr/src/comedi y
./configure --with-linuxdir=/usr/src/linux --with-rtaidir=/usr/realtime.
Para la instalación utilizaremos los siguientes comandos: make y make install.
38. Ahora instalaremos RTAI, para ello primero debemos ir a donde esta: cd
/usr/src/rtai
35
39. Ahora elegiremos las opciones de nuestra instalación, para ello utilizaremos el
comando: make menuconfig. La imagen que aparecerá será la siguiente:
40. Las opciones que escogeremos en el menú que aparece son las que aparecen en
las siguientes imágenes:
En General:
En Machine:
36
En Base System:
37
En Add-ons:
38
En RTAI-Lab:
41. Si aparece algún fallo relativo a que no encuentra el archivo comedilib.h
correspondiente deberemos mover el archivo comedilib.h al directorio donde lo
busca, está indicado en el reporte del error, incluso creando la carpeta donde lo
está buscando en caso de ser necesario.
42. Ahora tan sólo deberemos instalar con los comandos: make y make install.
Después de la instalación debemos reiniciar con el comando: /usr/bin/reboot
43. Ahora comprobaremos que no hay errores, para lo cual debemos utilizar los
siguientes comandos y ver que no hay fallos:
cd /usr/realtime/testsuite/user/latency
./run (use ctrl-c to stop it)
cd /usr/realtime/testsuite/user/preempt
./run (use ctrl-c to stop it)
cd /usr/realtime/testsuite/user/switches
./run (use ctrl-c to stop it)
cd /usr/realtime/testsuite/kern/latency
./run (use ctrl-c to stop it)
cd /usr/realtime/testsuite/kern/preempt
./run (use ctrl-c to stop it)
cd /usr/realtime/testsuite/kern/switches
./run (use ctrl-c to stop it)
39
A veces estos comandos producen errores porque las entradas de las colas no
son persistentes con lo que borran tras un reinicio, para hacerlas persistentes
tendremos que añadir el código que viene a continuación en un archivo que en
este caso lo he llamado S15RTAI en el directorio /etc/init.d. Para ello
ejecutaremos el comando: vi /etc/init.d
a) Si tenemos un fallo tipo Error opening /dev/rtf/0 (u otro número del 1 al 9). El
código será el siguiente:
#!/bin/bash
mkdir /dev/rtf
for n in `seq 0 9`
do
f=/dev/rtf/$n
mknod -m 666 $f c 150 $n
done
b) Si tenemos un fallo tipo Error opening /dev/rtf0 (u otro número del 1 al 9 o
rtai_shm). El código será el siguiente:
#!/bin/bash
mknod -m 666 /dev/rtai_shm c 10 254
for n in `seq 0 9`
do
f=/dev/rtf$n
mknod -m 666 $f c 150 $n
done
Después de haber creado el archive deberemos linkarlo con el modo de inicio
correspondiente. El modo de inicio por defecto es 2. Para lindarlo utilizaremos
el siguiente comando: ln –s /etc/init.d/S15RTAI /etc/rc2.d/S15RTAI.
44. Ahora deberemos reiniciar con el siguiente comando /sbin/reboot y probaremos
que la instalación funciona correctamente volviendo a ejecutar los comandos del
paso 39.
40
45. Ahora deberemos copiar los archivos de RTAI al Matlab, para lo cual
ejecutaremos el siguiente comando: cp -r /usr/src/rtai-3.3/rtai-lab/matlab
usr/local/Matlabr14/rtw/c/rtai.
46. Tras comprobar que todo funciona correctamente, ahora abriremos Matlab de la
siguiente forma, iremos a la carpeta donde está instalado MATLAB con el
siguiente comando: cd /usr/local/Matlabr14/bin(he supuesto que Matlab está
instalado en el directorio usr/local, sino iremos al directorio correspondiente).
Ahora inicializaremos Matlab poniendo en línea de comandos: matlab.
Debemos ejecutar el archivo setup.m que está en el directorio de rtai-lab dentro
de rtai -3.4. Después de este paso se debería ser capaz de acceder a las librerías
RTAI devices desde el navegador de Simulink.
47. Ahora deberemos crear los ejecutables mex para las funciones que necesita
RTAI. Para ello en Matlab, ejecutaremos los siguientes comandos:
mex –setup
mex sfun_rtai_led.c
mex sfun_rtai_log.c
mex sfun_rtai_meter.c
mex sfun_rtai_scope.c
mex sfun_rtai_synchronoscope.c
mex sfun_comedi_dio_write.c
mex sfun_comedi_dio_read.c
mex sfun_comedi_data_write.c
mex sfun_comedi_data_read.c
48. Para probar que toda la instalación funciona vamos a generar código desde un
ejemplo. Para ello primero vamos a copiar el código de ejemplo que esta en
usr\local\Matlabr14\rtw\c\rtai\examples\test.mdl al directorio de trabajo (por
ejemplo usr\local\Matlab\work).
41
49. Después abriremos este fichero con Simulink y lo ejecutaremos. Debe funcionar
sin problemas. Aunque puede existir uno de los siguientes problemas:
En este caso esto se soluciona haciendo en una ventana el siguiente comando:
export LD_PRELOAD=/lib/libgcc_s.so.1
50. En este punto ya somos capaces de generar código, para ello abriremos el menú
de simulación->parámetros de simulación->Real Time Workshop y nos
aseguraremos que el RTAI Target está seleccionado, de no ser así lo
seleccionaremos y entonces le damos al botón Build. Si aparece el siguiente
fallo lo solucionaremos de la misma manera que en el punto 42:
42
Pero si aparece el siguiente fallo seguiremos otro procedimiento, definido en el
punto 47:
51. Para ello tendremos que añadir las librerías en la siguiente ventana, en el caso de
que no tengamos la librería liblxrt.a en la ruta indicada deberemos copiarla allí:
43
52. Después de hacer esto ya deberíamos generar el código, para lo cual deberemos
ir en una ventana a la siguiente carpeta, para ello deberemos ejecutar en una
ventana el siguiente comando: cd /usr/local/Matlab/test_rtai
53. Después deberemos incluir los módulos con la siguiente líneas de comando:
sync
insmod /usr/realtime/modules/rtai_hal.ko
insmod /usr/realtime/modules/rtai_lxrt.ko
insmod /usr/realtime/modules/rtai_fifos.ko
insmod /usr/realtime/modules/rtai_sem.ko
insmod /usr/realtime/modules/rtai_mbx.ko
insmod /usr/realtime/modules/rtai_msg.ko
insmod /usr/realtime/modules/rtai_netrpc.ko ThisNode="127.0.0.1"
sync
44
54. Después de realizar esto ejecutaremos el programa como mostramos en la
siguiente ventana con el comando ./test –v –f 5 ó ../test –v –f 5 en el caso de
que el primero no funcione:
45
3.2 Manual de Instalación del hardware
Esta es una guía de los pasos seguidos para instalar el hardware necesario para
este proyecto. En esta guía tan sólo se hace referencia a las opciones seguidas para la
instalación, aunque alguna se puede cambiar. El ordenador utilizado para esta
instalación es Dell GX280. Es recomendable tener todos los componentes disponibles
antes de empezar la instalación del hardware, aunque no es estrictamente necesario.
Para la instalación del hardware necesitaremos tener disponibles los siguientes
elementos:
•
Ordenador Dell GX280
•
Extensor del bus PCI
•
Extensor del bus PCI
•
Extensor del bus ISA
•
Bridge PCI-ISA PCI9052
•
Tarjeta DAQ PCL812PG
•
Tarjeta PWM
46
Los pasos a seguir son:
1. Primero nos aseguraremos de que el ordenador está apagado, para más
seguridad es recomendable desconectar el ordenador de la corriente.
2. Después abriremos el ordenador, tiene unas solapas a ambos lados para
poder abrirlo de forma sencilla. El ordenador abierto es:
3. Ahora tiraremos de la palanca verde que se indica en la imagen:
47
4. Tras tirar de la palanca podremos ver el bus PCI, que debe ser así:
5. Cogeremos el extensor del bus PCI, cuyo aspecto es el siguiente:
48
6.
Enchufaremos el extensor PCI al bus PCI indicado en la imagen,
Enchufaremos de nuevo el bus PCI al ordenador, asegurándonos de que queda
bien enganchado, el bus tiene unos carriles que es por donde debe ir para
asegurarnos de esto. Después de esto la instalación debe estar así:
49
7. Ahora cogeremos el bridge PCI9052 que tiene la siguiente apariencia:
8. Enchufaremos el bridge al extensor del bus PCI en el bus indicado en la
imagen.
OJO: De no utilizar este bus el ordenador no reconocerá el bridge, es decir pasará lo mismo que
en caso de estar el bridge mal conectado.
Tras la conexión el ordenador quedará de la siguiente forma:
50
9. Ahora cogeremos el extensor del bus ISA, que tiene el siguiente aspecto:
51
10. Enchufaremos el extensor del bus ISA al bridge, quedando el hardware
instalado hasta el momento de la siguiente manera:
11. Cogeremos la tarjeta PCL812PG, que es la que aparece en la siguiente
imagen:
52
12. Enchufaremos la tarjeta al extensor ISA por el lado que aparece en la
imagen,
La tarjeta junto con el extensor ISA quedará de la siguiente manera:
Vista lateral
Vista frontal
13. Cogeremos la tarjeta PWM, que es la que aparece en la siguiente imagen:
53
14. Volveremos a repetir el paso 12 pero con la tarjeta PWM, de esta forma la
arquitectura final hardware quedará de la siguiente manera:
15. Ahora deberemos alimentar la tarjeta PWM, para lo cual deberemos enchufar
en los conectores un cable de alimentación. En nuestro es el que alimenta a
la disquetera de CD-ROM.
16. Para finalizar tan sólo debemos enchufar de nuevo el ordenador a la corriente
y nuestra arquitectura hardware ya estará lista para funcionar.
17. Para comprobar el correcto funcionamiento de nuestra arquitectura hardware
tendremos que encender el ordenador. Cuando este encendido abriremos una
consola y ejecutaremos el siguiente comando: lspci. El resultado de este
comando deberá ser el siguiente:
54
En caso de no aparecer la línea subrayada en rojo quiere decir que el
hardware no está correctamente conectado. En ese caso deberemos revisar las
conexiones.
55
Capítulo 4: Arquitectura Software
4.1 Descripción general
En este capítulo se pretende dar a conocer la arquitectura software del sistema y
los cambios que se han tenido que realizar en los elementos disponibles para que esta
funcione de forma coordinada y conjunta con el hardware de esta arquitectura. Antes de
leer este documento se recomienda tener conocimientos básicos sobre Real Time
Workshop para lograr una mayor comprensión del texto.
El software específico de esta arquitectura se divide en tres módulos, que
explicaremos de forma detallada a lo largo de este capítulo. Estos módulos son:
o
Módulo Driver: es el software que interactúa directamente con las
tarjetas.
o
Módulo RTW: es el software que interactúa entre el módulo del
driver y el Real Time Workshop.
o
Módulo Bridge: es el software que permite que el bridge pueda
cumplir sus funciones y permitir la comunicación de las tarjetas con el
PC. Además en este módulo cobra especial relevancia el valor de los
datos que se deben escribir en los registros del bridge de cara a abrir la
comunicación entre tarjetas y el PC.
56
4.2 Módulo Driver
4.2.1 Descripción general
Este apartado pretende explicar el código del módulo drivers, que es el módulo
donde está integrado las funciones de bajo nivel de las tarjetas. De esta forma se podrá
conocer el funcionamiento de los drivers y la utilidad de todas las funciones utilizadas
en este. Además se podrá conocer las funcionalidades que aporta este driver.
Se ha dividido este módulo en tres partes, cada una de las cuales representa un
fichero o un tipo de fichero:
™
Driver.c, cada driver tiene un fichero como este pero el nombre cambia
en cada driver sustituyendo el termino driver por el nombre de la tarjeta
correspondiente.
™
PCL812PG.h
™
PWMX2_FPGA.h
57
4.2.2 Driver.c
En ambos este fichero es común y es el que realiza las funciones de interfaz
entre las funciones de más bajo nivel que están en las cabeceras correspondientes a cada
fichero, y RTW. Por ello las funciones que están en este fichero son funciones
específicas de Matlab-RTW que son llamadas por este programa y son necesarias para
su ejecución junto con el modelo que hayamos diseñado para casa caso particular.
Aparte de las funciones el interfaz está también compuesto por una estructura
que se define en Matlab-RTW, concretamente en el fichero simstruct.c, que es Simstruct
que nos proporciona una macro que permite encapsular toda la información del modelo
que se vaya a ejecutar, incluso las salidas. Por lo tanto esta estructura nos permitirá
también comunicar el driver, mediante la actualización de esta estructura, con el modelo
que se vaya a ejecutar en cada momento.
La estructura básica de ejecución de un driver del RTW es:
58
Ahora se va a explicar detalladamente las fases en las que se divide la ejecución
mostrada en la imagen anterior:
1. Registro del modelo: En esta fase se registra el modelo y el sistema
inicializa las zonas de trabajo que necesitará el modelo posteriormente. Se
realiza este paso con las funciones Model, MdlInitializeSizes y
MdlInitializeSampleTimes. A continuaciones explicarán las dos últimas
funciones porque la primera es propia del programa en el que se ejecuta cada
modelo y no del driver.
MdlInitializeSizes es la función que define el número de argumentos del
driver y además las entradas, salidas, parámetros y otras características
importantes. En este caso los datos de inicialización se escribirán en
SimStruct.
MdlInitializeSamplesTimes es la función que indica los tiempos de muestreo
que va a utilizar el driver, que se ajustarán al del modelo desarrollado y el
inicio del modelo en el instante 0.
2. MdlStart: Con esta función se inicializa la tarjeta correspondiente para cada
driver y algún que otro dato que pueda ser importante, como puede ser el
número de datos leídos por la tarjeta, o se inicializan las interrupciones en el
caso de la PWM. Esta función sólo se ejecuta una vez al principio.
3. MdlOutputs: Con esta función se realiza la lectura y escritura de las tarjetas
correspondientes, ya que este es la función que actualiza las salidas en el
momento adecuado, indicado por MdlInitializeSamplesTimes. Esta función
tiene dos argumentos, la estructura SimStruct que nos proporcionará la
información del modelo y la tarjeta y la tid que es el identificador de la tarea,
en este driver no nos va a ser de utilidad. Esta función se ejecuta cada vez
que queramos leer o escribir datos en la tarjeta.
4. MdlTerminate: Esta es la función que realiza todas las acciones necesarias
para terminar el modelo. En nuestro caso no tenemos que realizar ninguna
acción. Esta es la última función que se ejecutará en todos nuestros modelos.
59
Aparte de las funciones que integran las fases básicas para la comunicación hay otras
funciones relevantes, que aparecen en más de una fase de ejecución del driver, que
necesitamos utilizar en el driver y son las siguientes:
•
Las funciones que cambian valores en la estructura SimStruct (S), gracias a las
cuales escribimos en el interfaz del driver con el modelo. Estas funciones son
muy similares y tienen la siguiente estructura: ssSetparametro(S, valor).
•
Hay otras funciones que son prácticamente iguales que las anteriores y cuya
única diferencia es que tienen tres argumentos en vez de dos, estas funciones
son ssSetOutputPortWidth(S, índice del canal a utilizar, tamaño del puerto),
ssSetSampleTime(S, índice del período de muestreo, duración del período de muestreo) y
ssSetOffsetTime(S, índice del tiempo a ajustar, valor al que se ajusta el tiempo).
60
4.2.3 PCL812PG.H
Este es el fichero en el que se realizan las funciones de bajo nivel específicas de
la tarjeta de adquisición de datos PCL812PG. Se pueden distinguir dos partes bien
diferenciadas:
•
Definición de los registros: En esta parte hemos definido de forma estática
tanto la dirección base de la tarjeta en una variable a la cual hemos llamado
BASE_ADDR, así como la estructura de registros de la tarjeta, que viene
explicada detalladamente en el Anexo B. El valor de la dirección base es el
puerto donde está el primer registro de la tarjeta, que conoceremos gracias al
mapeo que realiza el bridge PCI9052. La obtención de esta dirección se
explicará más adelante. Las direcciones de los registros están diseccionados en
relación a la dirección base de la tarjeta.
•
Definición de las funciones: En este apartado se han programado las funciones.
Existen dos tipos de funciones, las que se han programado y las funciones que
estando dentro de C son poco conocidas.
Funciones de C:
o
iopl (): esta la función que cambia el nivel de privilegio de E/S
del driver, según se especifique en el argumento de entrada. Hay
dos posibles estados de error de esta función, el primero es que el
valor del argumento no puede ser mayor que 3 y además esta
función se debe ejecutar siempre como super-usuario.
o
outb (): esta la función que permite escribir a un registro. Con
esta función escribimos en un puerto de 1 byte únicamente. Esta
función tiene dos argumentos, el primero de ellos es el valor que
se va a escribir en el puerto correspondiente y el segundo
argumento es el puerto correspondiente al registro donde
queramos escribir.
61
o
inb (): esta función que permite leer es la función de un registro.
Con esta función leemos 1 byte únicamente. Esta función tiene un
único argumento, que es el puerto de donde escribimos que será
el registro que corresponda en cada caso.
Funciones programadas:
o
pcl812pg_init (void): esta función inicializa todos los puertos de
modo escritura-lectura, de esta forma el resto del driver puede
escribir y leer de los puertos que necesite. Para la ejecución de
esta función es imprescindible tener los permisos adecuados, de
no ser así no se puede ejecutar.
o
write_do_lsb (char valor): esta función escribe en el registro
A/D byte bajo, es decir en el registro del cual obtenemos los bits
menos significativos de la entrada analógica. El valor que
escribimos es el que se envía a la función. Esta función devuelve
un código de retorno para comprobar si ha habido errores durante
su ejecución.
o
write_do_msb (char valor): esta función escribe en el registro
A/D byte alto, es decir en el registro del cual obtenemos los bits
más significativos de la entrada analógica. El valor que
escribimos es el que se envía a la función. Esta función devuelve
un código de retorno para comprobar si ha habido errores durante
su ejecución.
62
o
read_adc (char canal, char ganancia): esta función es la que
permite leer una entrada analógica cualquiera que sea su fuente.
En esta función primero inicializamos el trigger y comprobamos
que la señal analógica está lista, de no estar lista en un período
prudencial esta función nos devolverá un error y se terminará el
programa, porque esto significará que no se están leyendo los
datos de la tarjeta adquisitora pcl812pg. Tras obtener la señal la
leeremos del canal que se nos ha indicado anteriormente y con la
ganancia requerida. Esta función devolverá la señal analógica
transformada en un valor digital.
63
4.2.4 PWMX2_FPGA.H
Este es el fichero en el que se realizan las funciones de bajo nivel específicas de
la tarjeta de modulación PWM. Se pueden distinguir dos partes bien diferenciadas:
•
Definición de los registros: En esta parte hemos definido de forma estática
tanto la dirección base de la tarjeta en una variable a la cual hemos llamado
BASE_ADDR, así como la estructura de registros de la tarjeta, que viene
explicada detalladamente en el Anexo B. El valor de la dirección base es el
puerto donde está el primer registro de la tarjeta, que conoceremos gracias al
mapeo que realiza el bridge PCI9052. La obtención de esta dirección se
explicará más adelante. Las direcciones de los registros están diseccionados en
relación a la dirección base de la tarjeta.
•
En este apartado se han programado las funciones.
Existen dos tipos de
funciones, las que se han programado y las funciones que estando dentro de C
son poco conocidas.
Funciones de C:
o
iopl (): esta la función que cambia el nivel de privilegio de E/S
del driver, según se especifique en el argumento de entrada. Hay
dos posibles estados de error de esta función, el primero es que el
valor del argumento no puede ser mayor que 3 y además esta
función se debe ejecutar siempre como super-usuario.
o
outw (): esta función que permite escribir a un registro. Con esta
función escribimos en un puerto de una palabra (2 bytes)
únicamente. Esta función tiene dos argumentos, el primero de
ellos es el valor que se va a escribir en el puerto correspondiente
y el segundo argumento es el puerto correspondiente al registro
donde queramos escribir.
64
o
inw (): esta función que permite leer es la función de un registro.
Con esta función leemos de una palabra (2 bytes) únicamente.
Esta función tiene un único argumento, que es el puerto de donde
escribimos que será el registro que corresponda en cada caso.
Funciones programadas:
o
svpwm_fpga_init (void): esta función inicializa todos los
puertos de modo escritura-lectura, de esta forma el resto del
driver puede escribir y leer de los puertos que necesite. Para la
ejecución de esta función es imprescindible tener los permisos
adecuados, de no ser así no se puede ejecutar.
o
svpwm_fpga_stop (int valor): esta función es la que finaliza el
dispositivo. Esta función devuelve un código de retorno para
comprobar si ha habido errores durante su ejecución.
o
svpwm_fpga_run (int valor): esta función es la que inicializa el
dispositivo, de tal forma que se puede empezar a trabajar con la
tarjeta PWM. Esta función devuelve un código de retorno para
comprobar si ha habido errores durante su ejecución.
o
interrupcion_ini(int valor_conmutacion, int valor_muestreo):
esta función realiza una interrupción guardando el valor que
tuviera por el muestreo y el valor de conmutación. Esta función
devuelve un código de retorno para comprobar si ha habido
errores durante su ejecución.
o
write_rama1 (float valor): esta función es la que permite
escribir en la primera rama de la tarjeta PWM, el valor entrante se
transformará en un valor de 2 bytes antes de escribirlo. Esta
función devuelve un código de retorno para comprobar si ha
habido errores durante su ejecución.
65
o
write_rama2 (float valor): esta función es la que permite
escribir en la segunda rama de la tarjeta PWM, el valor entrante
se transformará en un valor de 2 bytes antes de escribirlo. Esta
función devuelve un código de retorno para comprobar si ha
habido errores durante su ejecución.
o
write_rama3 (float valor): esta función es la que permite
escribir en la tercera rama de la tarjeta PWM, el valor entrante se
transformará en un valor de 2 bytes antes de escribirlo. Esta
función devuelve un código de retorno para comprobar si ha
habido errores durante su ejecución.
o
write_rama4 (float valor): esta función es la que permite
escribir en la cuarta rama de la tarjeta PWM, el valor entrante se
transformará en un valor de 2 bytes antes de escribirlo. Esta
función devuelve un código de retorno para comprobar si ha
habido errores durante su ejecución.
o
write_rama5 (float valor): esta función es la que permite
escribir en la quinta rama de la tarjeta PWM, el valor entrante se
transformará en un valor de 2 bytes antes de escribirlo. Esta
función devuelve un código de retorno para comprobar si ha
habido errores durante su ejecución.
o
write_rama6 (float valor): esta función es la que permite
escribir en la sexta rama de la tarjeta PWM, el valor entrante se
transformará en un valor de 2 bytes antes de escribirlo. Esta
función devuelve un código de retorno para comprobar si ha
habido errores durante su ejecución.
66
4.3 Módulo RTW
4.3.1 Descripción general
Este apartado pretende explicar el código del módulo RTW, que es el módulo
donde está integrado las funciones necesarias para la comunicación del módulo drivers
con el Real Time Workshop. De esta forma se podrá conocer más en profundidad el
funcionamiento del Real Time Workshop y las funcionalidades que nos ofrece.
Para entender este módulo primero se debe conocer el modo de funcionamiento
en la generación de código del Real Time Workshop. El proceso de generación de
código sigue el siguiente esquema:
67
Siguiendo con este esquema, sabemos que los pasos que Real Time Workshop
sigue en la generación de código son los siguientes:
™ Compilación del modelo (Real Time Workshop Build): en este paso
Real-Time Workshop analiza el modelo construido previamente con
Simulink, que en la imagen anterior es model.mdl, y compila este modelo
produciéndose un archivo intermedio codificado en código ASCII que es
model.rtw.
™ Generación del makefile: aunque este proceso está en el esquema dentro
del Real Time Workshop Buid, no tiene ninguna relación con el punto
anterior. En este proceso únicamente se generará el makefile del modelo,
por ejemplo model.mk, a partir de un fichero temporal (template
makefile), por ejemplo system.tmf.
™ Generación del código (Target Language Compiler): en este proceso se
compila el fichero intermedio obtenido anteriormente con el compilador
que dispone Real Time Workshop para los ficheros de tipo target, por
ejemplo system.tlc, de tal forma que obtenemos los ficheros de código
correspondientes al modelo, es decir el código generado por Real Time
Workshop.
™ Generación del ejecutable (make): este proceso ya nos es propio de Real
Time Workshop, aunque viene integrado en la misma aplicación. En
realidad este paso están solo hacer el make que se ha obtenido
anteriormente, por ejemplo make.mk. De esta forma ya obtenemos el
ejecutable con todos los ficheros de código y cabeceras necesarias para
su ejecución.
Este modelo básico tiene algunas opciones que se desgranarán más adelante en
el caso de nuestros drivers concretos. A pesar de esto estos pasos se cumplen siempre
para todos los modelos, independientemente de su naturaleza u opciones de ejecución.
68
Se ha dividido este módulo en tres partes, cada una de las cuales representa un
fichero o un tipo de fichero:
™
Grt_rtai.tlc
™
Grt_rtai.tmf
™
Grt_main.c
Aparte de estos ficheros se necesita para un correcto funcionamiento de los
drivers la modificación de algunos ficheros más, a los que se hará referencia en el
apartado 4.3.4.
69
4.3.2 Grt_rtai.tlc
Este fichero es de tipo “target” (Target Language Compiler file) y es
imprescindible para realizar la generación de código, con lo cual es uno de los ficheros
imprescindibles a la hora de compilar nuestros modelos. Este fichero será procesado por
el Target Language Compiler para poder obtener nuestro código para nuestros modelos.
Cada fichero “target” está asociado a uno o más ficheros temporales, “template
makefile”, de esta forma el usuario puede escoger para varios modelos el mismo
“target”, pero el modo en que se generaría el ejecutable sería diferente porque la
generación del make sería diferente al poder escoger entre diferentes “template
makefile”.
Más concretamente los ficheros generados gracias a este fichero y el Target
Language Compiler son:
1. Model.c: es el código fuente generado a partir del modelo.
2. Model.h: es la cabecera del modelo.
3. Model_private.h: en este fichero se definen los parámetros y estructuras
necesarias para el código generado.
Los ficheros de tipo “target” son básicamente ficheros ASCII en los cuales se
controla el modo en el que Real Time Workshop va a generar el código. Cambiando un
valor en estos ficheros podemos alterar el modo en el que Real Time Workshop va a
generar el código y consecuentemente el código generado para cada modelo. Por todo
ello conviene conocer el uso de cada variable antes de empezar a trabajar con Real Time
Workshop para no llevarse ninguna sorpresa desagradable posteriormente.
70
Un fichero de estas características, al menos en nuestro proyecto, se divide en
tres partes bien diferenciadas:
1. Cabecera: en esta parte del fichero están las variables SYSTLC, TMF,
MAKE y EXTMODE. Una cabecera está compuesta por estas 4
variables. Un fichero puede tener varias cabeceras, ya que esta es la parte
del fichero que permite asociar el “target” con sus correspondientes
“template makefiles”.
2. Opciones genéricas de Target Language Compiler: esta zona es la que se
utiliza para especificar las diferentes opciones que se van a utilizar del
Target Language Compiler. Estas opciones suelen ser bastante generales
por lo que no hace falta modificarlas en exceso.
3. Opciones de Real Time Workshop: esta zona se distingue de las demás
porque
está
separada
del
resto
por
las
sentencias
BEGIN_RTW_OPTIONS y END_RTW_OPTIONS.
En este punto únicamente se van a describir el uso de cada variable para
conocerla más a fondo, además del valor que se ha considerado oportuno dar a cada
variable. Para cada driver concreto se especificará el valor de cada variable. Las
variables que hemos utilizado para estos drivers son las siguientes:
o
SYSTLC: esta es la primera variable de cada fichero y sirve para
mostrar un comentario en el Real Time Workshop de cara a que el
usuario conozca de forma más intuitiva el “template makefile”
seleccionado. En nuestro caso el valor ha sido:
o
TMF: es el nombre del fichero del “template makefile” asociado al
“target”. En nuestro caso el valor ha sido: grt_rtai.tlc
71
o
MAKE: es el comando make que se usará para generar el makefile.
En caso de no estar muy seguro de saber lo que se está haciendo el
valor de esta variable debe ser make_rtw, que es la generación por
defecto del makefile. En nuestro caso el valor ha sido: make_rtw
o
EXTMODE: es el nombre del interfaz externo que se va a utilizar en
caso de que se utilice alguno. En caso de no poderse ejecutar el
modelos de forma externa el valor del interfaz es no_ext_comm, el
interfaz por defecto es ext_comm. En nuestro caso el valor ha sido:
ext_comm
o
TargetType: esta variable es útil para Real Time Workshop de cara a
distinguir entre modelos de simulación y modelos de tiempo real. El
valor para modelos de tiempo real es “RT” y para los demás es
“NRT”. En nuestro caso el valor ha sido: RT
o
Language: es el lenguaje que vamos a utilizar para la generación de
código, prácticamente en todos los caso el lenguaje es C. El valor
para lenguaje C es “C”. En nuestro caso el valor ha sido: C
o
rtwgensettings.BuildDirSuffix: esta es una variable que está dentro
de las opciones de Real Time Workshop y es la única que siempre se
utiliza, ya que es en la que se indica el nombre de la carpeta que se
creará para almacenar el código generado y el ejecutable. El nombre
que se coloque en esta variable se concatenará con el nombre del
modelo a la hora de crear el directorio. En nuestro caso el valor ha
sido:
Además de estos valores el fichero grt_rtai.tlc tiene muchos más valores, que no
se ha considerado oportuno explicar en este documento.
72
4.3.3 Grt_rtai.tmf
Este fichero es de tipo temporal (template makefile) y es imprescindible para
realizar la generación del makefile, con lo cual es uno de los ficheros imprescindibles a
la hora de compilar nuestros modelos. Este fichero será procesado por el Real Time
Workshop Build para poder obtener nuestro makefile para poder generar el ejecutable
final partiendo del código generado para cada modelo.
Cada fichero temporal, “template makefile”, puede ir asociado a varios ficheros
“target”, no hay ninguna limitación en ese aspecto. Básicamente este fichero bastante
parecido al makefile que se generará. El fichero generado por este “template makefile”
se llamará model.mk
Este fichero puede tener dos enfoques diferentes los cuales son el enfoque al
compilador específico que se vaya a utilizar y un enfoque generalista, el cual permite
que se pueda utilizar para cualquier compilador. Si escogemos la segunda opción
deberemos seleccionar previamente con MATLAB el compilador que se va a utilizar.
Este fichero está dividido en varias partes las cuales vamos a pasar a explicar a
continuación:
1. Macros read by make_rtw: estos son los valores genéricos que leerá
nuestro comando make, en esta caso make_rtw, estos valores no se deben
modificar sin conocer realmente el impacto que tendrá. Las variables que
aparecen son:
o
MAKECMD: en esta variable se almacena el comando
make que se utilizará posteriormente. En este caso concreto el valor
de esta variable será: make
o
HOST: en esta variable se almacena el tipo de host en el
que se va a desarrollar el modelo. En este caso concreto el valor de
esta variable será: UNIX
73
o
BUILD: en esta variable se almacena si se va a construir el
ejecutable o sólo se genera el código para este modelo. En este caso
concreto el valor de esta variable será: yes
o
SYS_TARGET_FILE: en esta variable tiene que ir el
nombre del target al que este “template makefile” está asociado. En
este caso concreto el valor de esta variable será: grt_rtai.tlc
2. Tokens expanded by make_rtw: estos valores son los que ha generado
para cada variable respectiva Real Time Workshop, se recomienda no
utilizar estos valores ya que Real Time Workshop les asignará
automáticamente su valor correspondiente. Además en esta zona se
describen los directorios raiz para el resto del “template makefile”, el
directorio de MATLAB ya viene puesto por defecto, además de este se
recomienda poner los siguientes:
LINUX: el directorio donde está linux (/usr/src/linux)
RTAI: el directorio donde están las librerías de RTAI
(/usr/realtime/include)
RTW: el directorio donde está el Real Time Workshop
(MATLAB/rtw/c)
RTAI_RTW: el directorio donde están los ficheros para
comunicar Real Time Workshop con RTAI (RTW/rtai)
DRIVERS: el directorio donde se van a instalar los drivers
(/usr/src/drivers)
3. Tool Specifications: en esta zona del fichero básicamente se define la
herramienta a utilizar, se recomienda no cambiar estos valores si no se
está muy seguro de lo que se esta haciendo. La herramienta a utilizar
siempre será rtw/c/tools/unixtools.mk. Esta es la herramienta que se
utiliza para UNIX, por lo que esto no debemos cambiarlo. Aparte se
define valores útiles para el log, que no deberíamos cambiar.
74
4. Include Path: en esta parte del fichero se definen todos los ficheros que
se van a incluir para realizar posteriormente el make. Las carpetas
imprescindibles para el correcto funcionamiento de los drivers son:
MATLAB_ROOT/simulink/include (para trabajar con Simulink)
MATLAB_ROOT/extern/include (necesario para la compilación)
RTW/src (necesario para trabajar con Real Time Workshop)
RTW/libsrc (librerías de Real Time Workshop)
RTW/src/ext_mode/common (necesario para trabajar de modo externo)
LINUX/include (necesario ya que son las librerías del sistema)
RTAI (librerías de RTAI)
DRIVERS_HOME/pcl812pg (driver de la tarjeta DAQ)
DRIVERS_HOME/pwmx2_fpga (driver de la tarjeta PWM)
El resto de este parte se recomienda no tocar, ya que es el código que
permite incluir también las subcarpetas y la sentencia de inclusión de
todos los directorios antes enumerados.
5. External mode: en esta parte del fichero se definen opciones para el uso
del modo externo en Real Time Workshop. Se recomienda dejar las
opciones tal y como están.
6. C Flags: en esta parte del fichero se definen los flags del GCC que se van
a utilizar, para el ejemplo y la instalación del driver hemos dejado los
flags por defecto.
7. Source Files: en esta parte del fichero se definen los ficheros necesarios
para la compilación correcta del modelo y la posterior ejecución del
modelo. Estos ficheros se definen mediante la sentencia REQ_SRC, en la
cual deben estar los siguientes ficheros:
MODEL, se refiere al modelo que se va a compilar
MODULES, se refiere a los posibles módulos de este modelo
Rt_sim.c, este fichero permite el uso de SimStruct
75
Grt_main.c, es el fichero main explicado anteriormente
Rt_nonfinitive.c, este fichero nos
EXT_SRC, son los ficheros necesarios para el uso del modo externo
LOG_SRC, son los ficheros de log
Aparte de estos ficheros se recomienda no cambiar nada más ya que las
demás opciones van a utilizarse siempre de la misma manera excepto en
algún caso que se sale del ámbito del presente proyecto.
8. Rules: en esta parte del fichero se van a definir las reglas que se van a
crear en el makefile y que se ejecutarán al hacer el make. Para que todo
funcione correctamente como mínimo se deben compilar todos los
ficheros que necesita el modelo y hemos especificado antes y los drivers.
En este punto se debe comentar las siguientes líneas, de otra forma la
creación del makefile dará un error:
|>START_EXPAND_RULES<|%.o : |>EXPAND_DIR_NAME<|/%.c
$(CC) -c $(CFLAGS) $
|>END_EXPAND_RULES<|
Aparte de las normas en este parte también aparecen normas para la
creación de una librería que debemos dejar tal y como está por defecto.
9. Dependencies: en esta parte se definen funciones genéricas del modelo y
de la librería que se va a crear como el borrado del ejecutable cuando se
recompila y otras funciones útiles que se recomienda dejar como está
para una mayor organización del trabajo.
76
4.3.4 Grt_main.c
Este es el fichero donde esta definida la función main de nuestro modelo, por eso
lo vamos a llamar de aquí en adelante como fichero “main”, es decir la función principal
del ejecutable que se generará al final de todo el proceso. Básicamente el contenido de
este fichero es el código que tiene la función main que en nuestro caso realiza funciones
muy generales, ya que para el uso del modelo llama a funciones especificadas dentro del
modelo en ficheros como model.c. Además de la función main existe en este fichero
muchas funciones más que se van a necesitar para la ejecución de nuestro modelo.
Lo más interesante de este fichero es conocer la utilidad que tiene, ya que
realmente es código y además es la función main de nuestro ejecutable final, con lo que
siempre se ejecuta. A veces este fichero puede ser fuente de errores por
incompatibilidades con otros ficheros de nuestro modelo o simplemente por fallos de
programación que se generan al juntar el modelo y el código que genera este modelo
con este fichero “main”.
Lo más recomendable en los casos de fallo con este fichero, es decir MATLAB
genera un fallo en tiempo de compilación y el fallo pertenece a este fichero o se produce
un error en tiempo de ejecución como Segmentation Fault, es conocer exactamente
donde está el fallo y modificar este fichero para solucionar este fallo.
Conviene tener en cuenta en caso de modificación de este fichero, tener este
cambio bien documentado, ya que aunque sea imprescindible para el funcionamiento de
un modelo concreto nada nos asegura que las modificaciones realizadas permitirán que
funcionen todos los modelos que vayamos a ejecutar con este fichero “main”.
77
Los principales errores que aparecen en la ejecución del programa o
compilación:
•
Si aparece error en la llamada a funciones (too few arguments to
function), es debido a que en el fichero main existen por defecto las
llamadas con 0 argumentos. En ese caso debemos buscar las funciones
que se llaman y ponerles un argumento, que sea lógico y razonable. En
caso de necesitar una estructura SimStruct se pondrá la definida al
principio del main, y en caso de necesitar valores enteros se pondrá el
que se estime oportuno.
•
Si aparecen errores en momento de creación del ejecutable por falta de
referencias a una función, entonces deberemos localizar la función en el
main para ver cual es, deberemos ir a los ficheros ext_svr_transport.c o
ext_svr.c y deberemos realizar los siguientes cambios en los nombres o
funciones:
o
ExtGetHostMsg -> ExtGetHostPkt
o
ExtSetHostMsg -> ExtSetHostPkt
o
ExtWaitForStartMsgFromHost ->ExtWaitForStartPktMsgFromHost
o
ExtGRTSleep -> ExtModeSleep
o
rt_PktServerWork -> rt_MsgServerWork
o
ExtWaitForStartPkt ->ExtWaitForStartMsg
o
rt_ExtModeSleep -> grt_Sleep
o
Copiar el código de ExtModeShutdown a ExtForceDisconnect, creando
esta función si es necesario
•
Si aparecen errores en tiempo de ejecución de tipo Segmentarion Fault,
lo primero que debemos hacer es localizar la función donde se produce
este fallo y después cambiar esta línea para que no se produzca, ya sea
cambiando los argumentos de entrada a una función si se trata de una o
está dentro de una función o si no es necesaria la línea para la ejecución
del modelo comentando esta.
78
4.4 Módulo Bridge
4.4.1 Descripción general
En un PC existen dos tipos de direcciones, las primeras son las direcciones que
están situadas en memoria, las cuales hacen referencia a los recursos internos del
ordenador, es decir a los registros del ordenador y al software que este instalado en el
ordenador. Las segundas y no por ello menos importantes son los puertos, que son
direcciones especiales a las que se mapean los dispositivos de E/S. Cada dispositivo de
E/S tiene asignados unos puertos, en los cuales está disponible la información que tiene
la tarjeta en ese registro.
En nuestro caso concreto debemos tener en cuenta que lo que está directamente
conectado al ordenador es únicamente el bridge, no las tarjetas. Pero también debemos
tener en cuenta que el bridge proporciona los puertos necesarios para poder direccionar
las dos tarjetas, es decir dentro del espacio de direcciones E/S (puertos) del bridge
deben estar situadas las dos tarjetas.
Para que funcione el driver necesitamos asignar una dirección base correcta, es
decir debemos asignar el puerto que está en el espacio de direcciones E/S (puertos) del
bridge en el que está situada cada tarjeta respectivamente. Además debemos indicar en
el bridge si el espacio de entrada-salida va a ser el ISA y otras propiedades necesarias
para que funcione.
Estas propiedades están situadas en los siguientes registros:
•
INTCSR, es el registro en el que se definen características de
funcionamiento general para el bridge.
•
CNTRL, es el registro donde se definen características específicas de ISA
para el bridge.
79
•
LAS0RR y LAS1RR, son los registros que definen el rango del espacio de
memoria o E/S a mapear.
•
LAS0BRD y LAS1BRD, son los registros que definen características
individuales de cada espacio de memoria o E/S que se va a mapear.
•
LAS0BA y LAS1BA, son los registros donde se define la dirección base que
se va a mapear en el bridge.
•
CS0BASE y CS1BASE, son los registros donde se define la dirección base
en la que va a mapear los chipsets correspondientes.
A continuación vamos a pasar a explicar uno a uno los datos que debemos poner
en cada registro para la correcta instalación del bus ISA en el bridge. Los valores x
significa que da igual el valor. El valor – significa que el valor depende de la
situación concreta o de las opciones que se quieran realizar. Si aparece algún
símbolo en vez de un número significa que el dato debe cumplir unas restricciones
que aparecen enumeradas abajo.
80
4.4.2 Datos posibles en los Registros
INTCSR
Bit
9:0
Descripción
Otros valores
Valor
-
12
ISA Enable
1
31:13
Reservado
x
El valor del registro INTCSR en hexadecimal del registro será:
XXXX*XXX
* significa que el número será impar, es decir 1,3,5,7,9,B, D o F.
En nuestro caso hemos utilizado el valor será 0000115b, porque es el que viene por
defecto y cumple la condición necesaria
CNTRL
Bit
Descripción
Valor
5:0
Enable IORD,IOWR
x10x10
11:6
Configuración USER2 y USER3
x
13:12
PCIBAR Enables
00
14
PCI r2.1 Enable
1
15:17
Opciones PCI
x
18
PCI Write Release Bus Mode Enable
1
22:19
PCI Direct Slave Retry Delay Clocks
Entre 0011 y 1111
31:23
Reservado
0
El valor del registro CNTRL en hexadecimal del registro será:
00■▐▼X*●
■ significa que debe ser menor que 8 y mayor que 0.
▐ significa que debe ser mayor que 3.
▼ significa que debe ser 4 o C.
* significa que el número será impar, es decir 1,3,5,7,9,B, D o F.
● significa que debe ser 2 o 6.
81
En este caso el valor será 007c4252. Básicamente porque este valor cumple las
condiciones pedidas y nos venía puesto por defecto. En este caso hemos puesto que los
ciclos de retraso del reloj sean 7, pero podría tener otro valor, siempre cumpliendo la
condición.
LAS0RR
Bit
Descripción
Valor
0
Mapeo en Espacio de Memoria
0
2:1
Espacio de memoria
00
3
Lectura Prefectable
x
27:4
Rango
x
31:28
Reservados
x
El valor del registro LAS0RR en hexadecimal del registro será:
XXXXXXX●
● significa que el valor es 0 u 8.
En nuestro caso el valor es FFF00000, esto es debido a que vamos a tener como
rango de este espacio de direcciones un rango que nos permita trabajar con
comodidad.
LAS1RR
Bit
Descripción
Valor
0
Mapeo en E/S
1
1
Rango de E/S de 2 bytes
0
7:2
Rango
x
27:8
Rango superior al permitido (para memoria)
1
31:28
Reservados
x
El valor del registro LAS1RR en hexadecimal del registro será:
XFFFFFX●
● significa que el valor es 1,9 o D.
En nuestro caso el valor es FFFFFF01, esto es debido a que vamos a tener como en
este espacio de dirección E/S. Además este valor cumple todas las condiciones y nos
permite trabajar con las dos tarjetas a la vez (direcciones ISA 300 y 3F0).
82
LAS0BRD
Bit
Descripción
Valor
0
Burst Enable
0
1
Permitimos ISA interface
1
2
BTERM Enable
0
4:3
Cuenta para el prefetch
x
5
Permitimos prefetch en memoria
1
10:6
NRAD Wait States
0
12:11
NRDD Wait States
0
14:13
NXDA Wait States
0
19:15
NXWA Wait States
0
21:20
NWDD Wait States
23:22
Anchura del bus
31:24
Otros valores
0
00 (8 bits) o 01
(16 bits)
x
El valor del registro LAS0BRD en hexadecimal del registro será:
XX●000*▼
● significa que el valor es 0 o 4.
* significa que el valor es 2 o 3.
▼ significa que el valor es 2 o B.
El valor en nuestro caso es 00400022, esto es debido a que cumplimos todas las
condiciones y además la anchura del bus debe ser de 16 bits para poder permitir que
bridge obtenga bien los datos que le lleguen de una forma que pueda pasarlos
correctamente a las tarjetas.
LAS1BRD
Bit
Descripción
Valor
0
Burst Enable
0
1
Permitimos ISA interface
1
2
BTERM Enable
0
4:3
Cuenta para el prefetch
0
5
Permitimos prefetch en memoria
1
10:6
NRAD Wait States
0
12:11
NRDD Wait States
0
14:13
NXDA Wait States
0
19:15
NXWA Wait States
0
21:20
NWDD Wait States
23:22
Anchura del bus
31:24
Otros valores
0
00 (8 bits) o 01
(16 bits)
x
83
El valor del registro LAS1BRD en hexadecimal del registro será:
XX●00022
● significa que el valor es 0 o 4.
El valor en nuestro caso es 00000022, esto es debido a que cumplimos todas las
condiciones y además la anchura del bus debe ser de 8 bits para poder permitir que la
tarjeta PCL812-PG trabaje correctamente.
LAS0BA
Bit
Descripción
Valor
0
Espacio Enable
1
1
Reservado
x
3:2
No usados
x
27:4
Dirección a la que se mapea
-
31:28
Reservados
x
El valor del registro LAS0RR en hexadecimal del registro será:
X------●
● significa que el valor es impar.
El valor de nuestro registro es 00800001, lo cual quiere decir que teniendo en cuenta el
rango anterior la dirección mapeada es la 800000 respecto a la dirección base de la
tarjeta, el 1 no del final no se utiliza para la dirección, sino que nos indica que este
espacio de direcciones está activado.
LAS1BA
Bit
Descripción
Valor
0
Espacio Enable
1
1
Reservado
x
27:2
Dirección a la que se mapea
-
31:28
Reservados
x
El valor del registro LAS0RR en hexadecimal del registro será:
X------●
● significa que el valor es impar.
84
El valor de nuestro registro es 00000301, lo cual quiere decir que teniendo en cuenta el
rango anterior la dirección mapeada es la dirección, en este caso ISA, 300 respecto a la
dirección base de la tarjeta. El 1 no del final no se utiliza para la dirección, sino que nos
indica que este espacio de direcciones está activado.
CS0BASE
Bit
Descripción
Valor
0
Chip Enable
1
27:1
31:28
Dirección ISA a la que se mapea
(hasta el primer 1 es rango, el resto
es la dirección).
Reservados
x
El valor del registro CS0BASE en hexadecimal del registro será:
X------●
● significa que el valor es impar.
El valor de nuestro registro es 00800001, porque debe ser igual que el del LAS0BA,
porque sino no se mapean correctamente las direcciones.
CS1BASE
Bit
Descripción
Valor
0
Chip Enable
1
27:1
31:28
Dirección ISA a la que se mapea
(hasta el primer 1 es rango, el resto
es la dirección).
Reservados
x
El valor del registro CS1BASE en hexadecimal del registro será:
X------●
● significa que el valor es impar.
El valor de nuestro registro es 00000301, porque debe ser igual que el del LAS1BA,
porque sino no se mapean correctamente las direcciones.
85
4.4.3 PLXLinux
Este elemento es muy importante a la hora de trabajar con el bridge PCI 9052,
ya que es una colección de software diseñada por la empresa fabricante del bridge
PCI9052, que es PLX. Este software está sujeto a la licencia GNU.
En PLXLinux están disponibles los siguientes elementos:
1. Drivers de los chipsets PCI9050, PCI9052, PCI9030, PCI9080, PCI9054
y otros muchos más.
2. Scripts para iniciar, pausar y parar estos drivers
3. Una API que permite trabajar con las funciones de bajo nivel de los
dispositivos de los que se dispone de driver. Esta API permite la
realización de drivers personalizados para los dispositivos enunciados
anteriormente.
4. Una aplicación que se ejecuta mediante consola que permite trabajar
directamente con los registros de los dispositivos y no sólo con eso, sino
que podemos ver los puertos asociados al dispositivo e incluso leer y
escribir en estos puertos.
5. Todos los ficheros make necesarios para compilar e instalar los
elementos anteriormente descritos de forma sencilla.
86
Capítulo 5: Instalación drivers
5.1 Instalación PCL812PG
En este apartado se van a explicar los pasos seguidos para la instalación de la
tarjeta de adquisición de datos pcl812pg. Para facilitar esta instalación se ha recurrido a
la instalación de un programa de la empresa PLXTech que es fácilmente obtenible sin
coste alguno, que nos permite ver y configurar de forma más sencilla el bridge
PCI9052. Para la instalación de este driver necesitamos tener disponibles los siguientes
elementos:
1. pcl812pg.c
2. pcl812pg.h
3. MATLAB con Simulink y Real-Time Workshop
4. grt_rtai.tmf
5. grt_rtai.tlc
6. grt_main.c
87
Los pasos seguidos son los siguientes:
1.
Para empezar nos pondremos en el usuario root, ya que vamos a necesitar
este usuario para realizar unas cuantas operaciones. Nos ponemos como
usuario root con el siguiente comando: sudo bash. Entonces nos pedirá
una contraseña a la que pondremos la contraseña respectiva.
2.
Antes de empezar a trabajar con el bridge debemos asegurarnos de que
este está conectado y es detectado por el equipo, para ello ejecutaremos
el siguiente comando: lspci. La salida por pantalla debería ser como la
que aparece a continuación:
De no aparecer la línea subraya, entonces el bridge no ha está siendo
detectado por el sistema, por lo que deberíamos apagar el ordenador y
revisar las conexiones
3.
En caso de no tener instalado el programa PLXLinux obtenemos este
desde
la
página
web
de
PLX
correspondiente
que
es:
http://www.plxtech.com/products/sdk/license_agreement.asp?sdk=compl
ete.
88
Si queremos obtener distinta versión del software de la que se
indica en este link, entonces debemos ir al siguiente link:
http://www.plxtech.com/products/io/pci9052.asp. Para poder obtener esta
y otras herramienta es necesario estar registrado en PLXTech.
4.
Ahora deberemos copiar el archivo desde donde se haya descargado a la
carpeta /usr/src. Para ello utilizamos el siguiente comando: cp (carpeta
desde donde se haya descargado)/PlxLinux.zip /usr/src
5.
Ahora deberemos descomprimir el archivo .zip
con el siguiente
comando: unzip PlxLinux.zip
6.
Tras la descompresión, aparecerá un archivo .tar, que es donde está la
aplicación. Deberemos descomprimir este archivo con el siguiente
comando: tar -xvf PlxSdk.tar
7.
Esto creará las carpetas correspondientes a la aplicación PlxLinux. Para
poder instalar la aplicación deberemos actualizar una variable de entorno,
lo
cual
realizaremos
con
el
siguiente
comando:
declare
–x
PLX_SDK_DIR=$HOME/PlxSdk.
8.
Ahora deberemos construir las aplicaciones que vienen junto a los
drivers. Para ello iremos a la carpeta donde están con el siguiente
comando: cd /usr/src/PlxLinux/linux/api. Una vez allí realizaremos el
make con el comando: make. Una vez hecho esto iremos a otra carpeta
donde
hay
aplicaciones
útiles
con
el
comando:
cd
/usr/src/PlxLinux/simples/DSlave, una vez allí haremos: make
9.
Ahora vamos a construir los drivers, para ello deberemos ir al directorio
donde
están
situados
con
el
siguiente
comando:
cd
/usr/src/PlxLinux/linux/driver. Una vez allí crearemos el driver
necesario para nuestro bridge con el siguiente comando: ./builddriver
9050. De esta forma ya tenemos el driver para nuestro bridge. También
podemos crear a la vez todos los drivers de los que dispone esta
aplicación con el siguiente comando: ./buildalldrivers. Una vez
89
realizados todos estos pasos el programa ya está instalado correctamente
y podemos pasar a instalar el driver de nuestra tarjeta DAQ.
10.
Tras la instalación del programa, deberemos configurar el bridge, para
ello deberemos inicializarlo por lo que utilizaremos el siguiente
comando: /usr/src/PlxLinux/bin/modload 9050. Si este comando falla,
puede ser por dos motivos, o bien no tenemos los permisos necesarios
por lo que deberíamos de pasar a ser administrador o bien el bridge no ha
sido detectado con lo que deberíamos reiniciar y asegurarnos de las
conexiones con el bridge.
11. Tras esto deberemos ejecutar una la aplicación PlxCm, para lo cual
ejecutaremos
el
siguiente
comando:
/usr/src/PlxLinux/linux/simples/PlxCm/App/PlxCm
12. En la ventana aparecerá un terminal, como la que aparece en la imagen:
13. Ahora deberemos poner el siguiente comando: eep. De esta forma nos
saldrá en pantalla todos los valores de los registros de la memoria
EEPROM.
14. Ahora deberemos cambiar los valores de la memoria EEPROM, esto se
hace con el comando: eep (dirección memoria registro) valor. Por
ejemplo tenemos los siguientes valores en la memoria EEPROM:
044: 54321456
Si queremos cambiar este valor a 00000022 entonces debemos utilizar el
comando: eep 44 22
90
15.
Ahora deberemos cambiar los valores de la memoria EEPROM para que
salgan los siguientes:
16.
Ahora debemos realizar el mapeo correctamente para lo cual deberemos
cambiar los valores de los siguientes registros PCR, que se cambian de la
misma forma, para que los valores sean los que salen por pantalla:
91
17.
Ahora debemos cambiar la dirección que viene por defecto en la tarjeta,
la dirección que debemos poner en la tarjeta es la dirección ISA 3F0,
para ello debemos poner los jumpers del 1 al 6 al valor 1. Además nos
debemos asegurar que la dirección base que está en el driver es el puerto
CCF0.
18.
Tras realizar estas modificaciones ya tenemos todos los valores correctos
en el bridge. Ahora deberemos instalar el driver. Primero nos crearemos
una carpeta donde estarán los drivers de esta tarjeta DAQ que se llamará
drivers para ello utilizaremos estos comandos: cd /usr/src,
mkdir
drivers y mkdir pcl812pg
19.
Ahora pondremos los archivos pcl812pg.c y pcl812pg.h en este
directorio. Ahora crearemos el directorio donde pondremos el programa
de ejemplo, en este caso hemos utilizado los siguientes comandos: cd
/usr y mkdir proyecto
20.
A continuación deberemos abrir MATLAB con el siguiente comando:
/usr/local/Matlabr14/bin/matlab
21.
Tras abrir MATLAB ahora deberemos ir al directorio donde están los
drivers y con el siguiente comando en la ventana de MATLAB crear el
archivo mex: mex pcl812pg.c. Esto crearé un archivo pcl812pg.mex que
deberemos llevar al directorio donde está situado el proyecto.
22.
Ahora deberemos irnos a la carpeta donde está el ejemplo y abrirlo con
Simulink y aparecerá lo siguiente:
92
23. Ahora deberemos construir el modelo pero nos deberemos asegurar de
que el “template makefile” y el fichero “target” son los correctos, además de
los valores, para más información mirar apartado 4.3.2 y 4.3.3. Tras
asegurarnos de esto le daremos al botón Build:
24. Tras la construcción deberemos solucionar los posibles fallos que hubiera
tanto en compilación como en ejecución, para más información mirar el
apartado 4.3.4. Si no hay ningún fallo podremos ver en MATLAB el
mensaje:
###Successful completion of Real-Time Workshop build procedure for
model: example
25. Ahora el driver se podrá ejecutar correctamente. Para ejecutarlo se
recomienda reiniciar y consultar el manual de ejecución de los drivers en el
apartado 5.3.
93
5.2 Instalación PWM
En este apartado se van a explicar los pasos seguidos para la instalación de la
tarjeta de adquisición de datos pcl812pg. Para facilitar esta instalación se ha recurrido a
la instalación de un programa de la empresa PLXTech que es fácilmente obtenible sin
coste alguno, que nos permite ver y configurar de forma más sencilla el bridge
PCI9052. Para la instalación de este driver necesitamos tener disponibles los siguientes
elementos:
1. pwmx2_fpga.c
2. pwmx2_fpga.h
3. MATLAB con Simulink y Real-Time Workshop
4. grt_rtai.tmf
5. grt_rtai.tlc
6. grt_main.c
94
Los pasos seguidos son los siguientes:
1. Para empezar nos pondremos en el usuario root, ya que vamos a
necesitar este usuario para realizar unas cuantas operaciones. Nos
ponemos como usuario root con el siguiente comando: sudo bash.
Entonces nos pedirá una contraseña a la que pondremos la contraseña
respectiva.
2. Antes de empezar a trabajar con el bridge debemos asegurarnos de que
este está conectado y es detectado por el equipo, para ello ejecutaremos
el siguiente comando: lspci. La salida por pantalla debería ser como la
que aparece a continuación:
De no aparecer la línea subraya, entonces el bridge no ha está siendo
detectado por el sistema, por lo que deberíamos apagar el ordenador y
revisar las conexiones.
En caso de tener instalado PLXLinux pasaremos al punto 10.
95
3. En caso de no tener instalado el programa PLXLinux obtenemos este
desde
la
página
web
de
PLX
correspondiente
que
es:
http://www.plxtech.com/products/sdk/license_agreement.asp?sdk=comp
lete.
Si queremos obtener distinta versión del software de la que se
indica en este link, entonces debemos ir al siguiente link:
http://www.plxtech.com/products/io/pci9052.asp. Para poder obtener esta
y otras herramienta es necesario estar registrado en PLXTech.
4. Ahora deberemos copiar el archivo desde donde se haya descargado a la
carpeta /usr/src. Para ello utilizamos el siguiente comando: cp (carpeta
desde donde se haya descargado)/PlxLinux.zip /usr/src
5. Ahora deberemos descomprimir el archivo .zip
con el siguiente
comando: unzip PlxLinux.zip
6. Tras la descompresión, aparecerá un archivo .tar, que es donde está la
aplicación. Deberemos descomprimir este archivo con el siguiente
comando: tar -xvf PlxSdk.tar
7. Esto creará las carpetas correspondientes a la aplicación PlxLinux. Para
poder instalar la aplicación deberemos actualizar una variable de
entorno, lo cual realizaremos con el siguiente comando: declare –x
PLX_SDK_DIR=$HOME/PlxSdk.
8. Ahora deberemos construir las aplicaciones que vienen junto a los
drivers. Para ello iremos a la carpeta donde están con el siguiente
comando: cd /usr/src/PlxLinux/linux/api. Una vez allí realizaremos el
make con el comando: make. Una vez hecho esto iremos a otra carpeta
donde
hay
aplicaciones
útiles
con
el
comando:
cd
/usr/src/PlxLinux/simples/DSlave, una vez allí haremos: make
9. Ahora vamos a construir los drivers, para ello deberemos ir al directorio
donde
están
situados
con
el
siguiente
comando:
cd
/usr/src/PlxLinux/linux/driver. Una vez allí crearemos el driver
necesario para nuestro bridge con el siguiente comando: ./builddriver
96
9050. De esta forma ya tenemos el driver para nuestro bridge. También
podemos crear a la vez todos los drivers de los que dispone esta
aplicación con el siguiente comando: ./buildalldrivers. Una vez
realizados todos estos pasos el programa ya está instalado correctamente
y podemos pasar a instalar el driver de nuestra tarjeta DAQ.
10. Tras la instalación del programa, deberemos configurar el bridge, para
ello deberemos inicializarlo por lo que utilizaremos el siguiente
comando: /usr/src/PlxLinux/bin/modload 9050. Si este comando falla,
puede ser por dos motivos, o bien no tenemos los permisos necesarios
por lo que deberíamos de pasar a ser administrador o bien el bridge no
ha sido detectado con lo que deberíamos reiniciar y asegurarnos de las
conexiones con el bridge.
En caso de tener ya modificado los valores del bridge pasaremos
al punto 17.
11. Tras esto deberemos ejecutar una la aplicación PlxCm, para lo cual
ejecutaremos el siguiente comando:
/usr/src/PlxLinux/linux/simples/PlxCm/App/PlxCm
12. En la ventana aparecerá un terminal, como la que aparece en la imagen:
13. Ahora deberemos poner el siguiente comando: eep. De esta forma nos
saldrá en pantalla todos los valores de los registros de la memoria
EEPROM.
14. Ahora deberemos cambiar los valores de la memoria EEPROM, esto se
hace con el comando: eep (dirección memoria registro) valor. Por
ejemplo tenemos los siguientes valores en la memoria EEPROM:
044: 54321456
Si queremos cambiar este valor a 00000022 entonces debemos utilizar el
comando: eep 44 22
97
15. Ahora deberemos cambiar los valores de la memoria EEPROM para que
salgan los siguientes:
16. Ahora debemos realizar el mapeo correctamente para lo cual debemos
cambiar los valores de los siguientes registros PCR, que se cambian de
la misma forma, para que los valores sean los que salen por pantalla:
98
17. En nuestro caso la dirección ISA de la tarjeta siempre será 300. Pero nos
debemos asegurar que la dirección base que está en el driver es el puerto
CC00 para comprobar que el mapeo del bridge es correcto.
18. Tras realizar estas modificaciones ya tenemos todos los valores
correctos en el bridge. Ahora deberemos instalar el driver. Primero nos
crearemos una carpeta donde estarán los drivers de esta tarjeta DAQ que
se llamará drivers para ello utilizaremos estos comandos: cd /usr/src,
mkdir drivers y mkdir pcl812pg
19. Ahora pondremos los archivos pwmx2_fpga.c y pwmx2_fpga.h en este
directorio. Ahora crearemos el directorio donde pondremos el programa
de ejemplo, en este caso hemos utilizado los siguientes comandos: cd
/usr y mkdir proyecto2
20. A continuación deberemos abrir MATLAB con el siguiente comando:
/usr/local/Matlabr14/bin/matlab
21. Tras abrir MATLAB ahora deberemos ir al directorio donde están los
drivers y con el siguiente comando en la ventana de MATLAB crear el
archivo mex: mex pwmx2_fpga.c. Esto crearé un archivo
pwmx2_fpga.mex que deberemos llevar al directorio donde está situado
el proyecto.
22. Ahora deberemos irnos a la carpeta donde está el ejemplo y abrirlo con
Simulink y aparecerá lo siguiente:
99
23. Ahora deberemos construir el modelo pero nos deberemos asegurar de
que el “template makefile” y el fichero “target” son los correctos,
además de los valores, para más información mirar apartado 4.3.2 y
4.3.3. Tras asegurarnos de esto le daremos al botón Build:
24. Tras la construcción deberemos solucionar los posibles fallos que
hubiera tanto en compilación como en ejecución, para más información
mirar el apartado 4.3.4. Si no hay ningún fallo podremos ver en
MATLAB el mensaje:
###Successful completion of Real-Time Workshop build procedure for
model: example
100
25. Ahora el driver se podrá ejecutar correctamente. Para ejecutarlo se
recomienda reiniciar y consultar el manual de ejecución de los drivers en
el apartado 5.3.
101
5.3 Manual Ejecución
En este apartado se van a explicar los pasos seguidos para la ejecución de los
drivers implementados en este proyecto. Suponemos que tenemos todos los elementos
instalados a los que hemos hecho referencia en los Manuales de Instalación de la
plataforma de los apartados 3.1 y 3.2 y los Manuales de Instalación de los respectivo
drivers de los apartados 5.1 y 5.2. Los pasos a seguir
1. Iniciar el ordenador en el modo RTAI, seleccionar RTAI en el menú de
arranque.
2. Tras arrancar y meternos con nuestra contraseña, deberemos ponernos
como usuario root, ya que vamos a necesitar este usuario para realizar
unas cuantas operaciones. Nos ponemos como usuario root con el
siguiente comando: sudo bash. Entonces nos pedirá una contraseña a la
que pondremos la contraseña respectiva.
3. Después iniciaremos el bridge con el siguiente comando:
/usr/src/PlxLinux/bin/modload 9050
4. Ahora si ya tenemos el modelo construido, de no ser así deberíamos
construirlo con Real-Time Workshop, tan sólo debemos ejecutar el
modelo con el comando respectivo, en este caso para la tarjeta
PCL812PG:
cd /usr/proyecto
./example –tf 0.001(o el tiempo que se estime oportuno)
La ejecución depende de la potencia que se le esté administrando a la
tarjeta, en este manual aparecen diferentes casos.
Si ponemos inf en vez de 0.001 el driver no parará su ejecución, si no
parará su ejecución cuando pase el tiempo indicado en segundos.
102
En el caso de 5 voltios:
En el caso de 3,125 voltios:
103
En el caso de 2,5 voltios a un canal y 3,125 voltios al otro:
En el caso de diferenciales alrededor de los 3 voltios:
104
5. Respectivamente para el caso de la tarjeta PWM:
cd /usr/proyecto
./example –tf inf
Si ponemos inf en vez de 0.001 el driver no parará su ejecución, si no
parará su ejecución cuando pase el tiempo indicado en segundos.
En este caso para comprobar el correcto funcionamiento podemos ver
cómo se enciende un LED cuando ejecutamos el driver.
105
Capítulo 6: Conclusiones
En este capítulo se van a explicar las conclusiones derivadas gracias a la
realización de este proyecto.
Las conclusiones de este proyecto son:
1.
Obtención de una arquitectura hardware compatible con los
ordenadores Dell GX280 disponibles en la universidad en particular y en
general con cualquier ordenador con buses PCI, que es el estándar que se
ha impuesto en los PCs actualmente.
2.
Obtención de un software que permite el funcionamiento de las
tarjetas PCL812PG y PWM con las últimas versiones software de los
distintos programas que se explican en el anexo B.
3.
La plataforma es sencilla de manejar, ya que sólo tenemos que
trabajar con el Real Time Workshop, y no tenemos que tener en cuenta
nada más de la implementación de esta a bajo nivel.
4.
Obtención de una plataforma adaptada a la universidad, ya que se
ha realizado con los componentes disponibles en la universidad.
5.
Realización de una documentación que puede servir de base tanto
para la instalación de esta arquitectura en más equipos dentro de la
universidad como para la futura actualización de esta arquitectura por
otra más mejorada.
106
Bibliografía
[PINZ07]
Pinzón Ardila, Omar (PINZ) “Compensación Selectiva de Armónicos
Mediante Filtros de Potencia”, Tesis para la obtención de grado de doctor,
Madrid 2007
[RTAI06] RTAI(RTAI) “RTAI 3.4 Users Manual rev 0.3”, Octubre 2006
[CORBE05] Jonathan. Corbet,Greg. Kroah-Hartman,Alessandro Rubini(CORBE)
Linux Device Driver 10, O´Really 2005
[UPCB02] bibliotecnica.upc.es/bustia/arxius/40194.pdf
[WIND07] www.windriver.com
[QNXH07] www.qnx.com
[RTER07] www.rtems.com
[DATM07] www.mathworks.com/access/helpdesk/help/toolbox/daq/daq.html
[CICL07] www.ciclope.info/labs/robot
[GAYU07] gayuba1.datsi.fi.upm.es/~dlopez/index.php
[SCIL07] www.scilab.org
[OCTV07] www.gnu.org/software/octave
[LINU07] www.linux-es.org
[UBUN07] www.ubuntu-es.org
[KERN07] kernelnewbies.org
[RTAI07] www.rtai.org
[CICR07] www.ciclope.info/doc/rtos/rtai.php
[RTAL07] www.rtai.org/RTAILAB/RTAI-Lab-tutorial.pdf
[EQUI07] www.equinox-project.org
[MESA07] www.mesa3d.org
[COME07] www.comedi.org
[MATH07] www.mathworks.com
[MATL07] www.mathworks.com/access/helpdesk/help/techdoc/
[SIMU07] www.mathworks.com/access/helpdesk/help/toolbox/simulink/
[RTW07] www.mathworks.com/access/helpdesk/help/toolbox/rtw/
[RTWE07] www.mathworks.com/access/helpdesk/help/toolbox/ecoder/
[TECI07] www.techfest.com/hardware/bus/isa.htm
[TECP07] www.techfest.com/hardware/bus/pci.htm#4.0
107
[PCL801] http://cclab.kaist.ac.kr/~chkim/temp/pcl812pgMan.html
[PLXP01] www.plxtech.com/products/io/pci9052.asp
[PCID01] www.plxtech.com/dts/download.asp?f=/PCI9000/9052/databook/9052db20.pdf
[UBUF07] www.ubuntu-es.org/index.php?q=forum
[RTMA07] www.rtai.org/RTAILAB/RTAI-TARGET-HOWTO.txt
[MATE07]www.mathworks.com/access/helpdesk/help/toolbox/rtw/index.html?/access/
helpdesk/help/toolbox/rtw/rn/bqn0dy8-1
[PLXB01] www.plxtech.com/pdf/technical/io/9052rdk-lite.pdf
[PLXL01] www.plxtech.com/products/sdk
[SEMP01] http://www.semiconductorstore.com/Pages/asp/search.asp
108
ANEXO A: Valoración Económica
Lo primero que vamos a calcular es el coste del esfuerzo de cada integrante del
proyecto, que aparece representado en la siguiente tabla:
Integrante
COORDINADOR
DIRECTOR
EQUIPO DE TRABAJO
Subtotal horas/hombre
Horas/Hombre
6
50
400
€/H
85
60
40
€
510
3000
16000
19510€
Ahora vamos a pasar a valorar el coste de los componentes hardware del proyecto:
Componente
Ordenador Pruebas
Ordenador Universidad
PCL812PG
PCI9052
Extensor PCI
Extensor ISA
Subtotal componentes
Tiempo uso
8 meses
4 meses
6 meses
6 meses
6 meses
6 meses
Coste componente(€)
1000
800
600
21
15
20
Coste proyecto (€)
70
88
60
10
15
10
253 €
En nuestro caso como para el proyecto se han utilizado software libre o componentes ya
disponibles hemos supuesto que el coste de este software es de 0 €.
Presupuesto Total:
Concepto
Coste
Personal
19510 €
Hardware
253 €
Software
0€
TOTAL
19763 €
109
ANEXO B: Componentes
En este anexo se van a describir y explicar las funcionalidades más importantes,
haciendo especial relevancia a las que se utilizan en este proyecto, de todos los
componentes utilizados, tanto software como hardware. Primero hablaremos de los
componentes software para después pasar a hablar de los componentes hardware.
Aparte de los componentes se va a hablar de los dos protocolos de bus utilizados en este
proyecto, PCI e ISA.
Este capítulo pretende dar a conocer la utilidad que tiene cada componente
dentro del proyecto. De esta forma en una posible actualización futura, se puede saber
mirando esta documentación qué papel juega cada componente y por qué componente
futuro se puede cambiar.
Los componentes utilizados son:
•
LINUX
•
KERNEL 2.6.17
•
RTAI
•
RTAI-LAB
•
eFLTK
•
MESA3D
•
COMEDI
•
MATLAB
•
SIMULINK
•
REAL TIME WORKSHOP
•
ISA
•
PCI
•
PCL812PG
•
PWM
•
PCI9052
110
LINUX
Descripción general
Linux es un Sistema Operativo. Es una implementación de libre distribución
UNIX para computadoras personales (PC), servidores, y estaciones de trabajo. Fue
desarrollado para el i386 y ahora soporta los procesadores i486, Pentium, Pentium Pro y
Pentium II, así como los clones AMD y Cyrix. También soporta máquinas basadas en
SPARC, DEC Alpha, PowerPC/PowerMac, y Mac/Amiga Motorola 680x0.
Como sistema operativo, Linux es muy eficiente y tiene un excelente diseño. Es
multitarea, multiusuario, multiplataforma y multiprocesador; en las plataformas Intel
corre en modo protegido; protege la memoria para que un programa no pueda hacer caer
al resto del sistema; carga sólo las partes de un programa que se usan; comparte la
memoria entre programas aumentando la velocidad y disminuyendo el uso de memoria;
usa un sistema de memoria virtual por páginas; utiliza toda la memoria libre para caché;
permite usar bibliotecas enlazadas tanto estática como dinámicamente; se distribuye con
código fuente; usa hasta 64 consolas virtuales; tiene un sistema de archivos avanzado
pero puede usar los de los otros sistemas; y soporta redes tanto en TCP/IP como en
otros protocolos.
Linux es una muy buena alternativa frente a los demás sistemas operativos. Más
allá de las ventajas evidentes de costo, ofrece algunas características muy notables. En
comparación con las otras versiones de Unix para PC, la velocidad y confiabilidad de
Linux son muy superiores. También está en ventaja sobre la disponibilidad de
aplicaciones, ya que no hay mucha difusión de estos otros Unixs (como Solaris, XENIX
o SCO) entre los usuarios de PC por sus altos costos.
Características de Linux
Aquí se expone una lista bastante completa con las principales características
de LINUX:
ƒ
Multitarea
ƒ
Multiusuario
111
ƒ
Multiplataforma
ƒ
Multiprocesador
ƒ
Protección de la memoria entre procesos, de manera que uno de ellos no
pueda colgar el sistema.
ƒ
Carga de ejecutables por demanda
ƒ
Política de copia en escritura para la compartición de páginas entre
ejecutables
ƒ
Memoria virtual usando paginación a disco
ƒ
Se realizan volcados de estado (core dumps) para posibilitar los análisis
post-mortem, permitiendo el uso de depuradores sobre los programas no
sólo en ejecución sino también tras abortar éstos por cualquier motivo.
ƒ
Todo el código fuente está disponible
ƒ
Control de tareas POSIX.
ƒ
Consolas virtuales múltiples
Toda la información aquí detallada es una recopilación que está disponible en las
referencias [LINU07], [UBUN07] y [KERN07]. Para más información acudir a estos
enlaces.
112
KERNEL 2.6.17
Descripción general
Aparte de las ventajas propias de Linux hay otras funcionalidades que ofrece el
kernel (núcleo) del sistema operativo Linux, las cuales vamos a desgranar a
continuación.
Ventajas del kernel 2.6:
Las funcionalidades más relevantes del kernel 2.6 respecto a la mejora y
flexibilidad para soportar diferentes arquitecturas hardware son:
™
Linux para sistemas empotrados
™
NUMA y Máquinas Grandes: Otro de los cambios fundamentales en el
kernel de Linux ha sido en la dirección exactamente opuesta al anterior: hacer
Linux un kernel aceptable en servidores tan grandes como sea posible.
™
Soporte de subarquitecturas: La nueva revisión del kernel también
incluye el concepto de subarquitectura, que aumenta el alcance de Linux a
nuevas categorías de hardware
™
Hyperthreading
Las ventajas del kernel 2.6 son:
™ Mejoras de escalabilidad
™ Interactividad y Velocidad de Respuesta
™ Mejora de la estabilidad
113
™ Infraestructura centralizada
™ Sistemas de archivo por red
Cambios en kernel 2.6.17
Después de ver los cambios más relevantes entre la versión 2.6 y la versión 2.4
vamos a ver los cambios introducidos en la versión 2.6.17 del kernel:
™
Se incorporó softmac cómo capa adicional al kernel
™
Soporte para LEAP
™
Soporte automático para SMP
™
Una mejora bestial (llega al 50% en algunos casos) en la implementación
del sistema de archivos EXT3
™
Soporte para el protocolo H.323 en iptables
™
La aparición de la función splice().
Toda la información aquí descrita es una traducción y está disponible en la
siguiente referencia [UBU07] y [KERN07]. Para más información acudir a estos
enlaces.
114
RTAI
Descripción general
Estrictamente RTAI no es un sistema operativo de tiempo real como pudieran
ser VxWorks o QNX. RTAI son unos parches que funcionan con Linux que permite
tener un sistema de tiempo real. Al ser de software libre es una solución económica para
conseguir un sistema de tiempo real. Estos parches realizan dos funciones principales:
1.
Toma la información del hardware, los interrumpe y si es
necesario pasa la interrupción a Linux. Para realizar esta función utiliza el
concepto de HAL (Hardware Abstraction Layer) para obtener la información de
Linux (que es el sistema operativo) y de las aplicaciones de Linux y para
obtener algunas funcionalidades de bajo nivel. El HAL proporciona nuevas
dependencias en Linux, aunque son pocas en este caso, además de una rápida
adaptación a cualquier distribución de Linux o versión del kernel.
2.
Unos servicios que permiten hacer los programas en tiempo real
de forma más sencilla.
RTAI también es una comunidad de código libre, lo cual permite una rápida
actualización ya que cualquiera que detecte un error puede comunicarlo a la comunidad
RTAI para que entre todos los programadores que componen esta comunidad puedan
solucionar este error y de esta forma ir mejorando RTAI.
115
Arquitectura
RTAI tiene una arquitectura similar a RTLinux. Al igual que RTLinux, RTAI
trata el kernel estándar de Linux como una tarea de tiempo real con la menor prioridad,
lo cual significa que el kernel de Linux se ejecuta cuando no hay ninguna tarea con
mayor prioridad ejecutándose. Las operaciones básicas de las tareas de tiempo real son
implementadas como módulos del kernel al igual que ocurre en
RTLinux. RTAI
maneja las interrupciones de periféricos que son atendidas por el kernel de linux
después de las acciones de tiempo real que hayan podido ser lanzadas como
consecuencia de las interrupciones.
Las interrupciones se originan en el procesador y en los periféricos. Las
originadas en el procesador (principalmente señales de error), son manejadas por el
kernel estándar, pero las interrupciones de los periféricos (como los relojes) son
manejadas por RTAI Interrupt Dispatcher. RTAI envía las interrupciones a los módulos
correspondientes del kernel estándar de linux cuando no hay ninguna tarea de tiempo
real activa en el kernel. Las instrucciones de activación y de desactivación de las
interrupciones del kernel estándar son reemplazadas por macros que se enlazan con las
instrucciones de RTAI. Cuando las interrupciones están desactivadas en el kernel
estándar, RTAI encola las interrupciones para ser repartidas después de que el kernel
estándar las active de nuevo. La siguiente figura muestra la arquitectura básica de
RTAI.
116
Adicionalmente, se puede ver en la figura el mecanismo de comunicación entre
procesos (IPC), que esta implementado de forma separado por Linux y por RTAI.
También existe un planificador (sheduler) distinto para Linux y para RTAI.
Ahora explicamos las dos partes fundamentales de esta arquitectura:
1.
HAL (Hardware Abstraction Layer): Los desarrolladores de RTAI
introducen el concepto de Real Time Hardware Abstraction Layer (RTHAL)
para interceptar las interrupciones hardware y procesarlas después. RTHAL es
una estructura instalada en el kernel de Linux que reúne los punteros a los datos
internos del hardware para el kernel y las funciones necesarias por RTAI para
operar. El objetivo de RTHAL es minimizar el número de cambios necesarios
sobre el código del kernel y por tanto mejorar el mantenimiento de RTAI y del
kernel de Linux. Con RTHAL, las diferentes operaciones se pueden cambiar ó
modificar sin tener que interferir con la implementación de Linux. Cuando
RTHAL es instalado en Linux, las funciones y las estructuras de datos
relacionada con la interacción con el hardware son reemplazadas por los
punteros a la estructura RTHAL.
2.
Planificación: La unidad de planificación en RTAI es la tarea. Siempre
hay al menos una tarea, llamada kernel de linux, que es la ejecución normal del
kernel de linux. Cuando aparecen las tareas de tiempo real, el planificador da
entonces mayor prioridad a éstas sobre la tarea del kernel de Linux. El
planificador proporciona servicios tales como suspender, reanudar, cosechar,
hacer periódica, esperar hasta, que son usadas en varios sistemas operativos de
tiempo real. El planificador es implementado como un módulo del kernel
dedicado (contrario a RTLinux) lo que facilita la implementación de
planificadores alternativos si es necesario.
Características:
Las características más destacadas de RTAI son las siguientes:
117
1.
Comunicación entre procesos: RTAI proporciona una gran
variedad de mecanismos para la comunicación entre procesos. Estos pueden ser
mediante IPC (Inter-process comunication) que utilizan FIFOs (First In First
Out), los semáforos, la memoria compartida, los mailboxes y los RPC (Remote
Procedure Call).
2.
Gestión de memoria: En las primeras versiones de RTAI la memoria
tenía que ser asignada estáticamente y no era posible la asignación en tiempo
real. Sin embargo en las actuales versiones se incluye un módulo gestor de
memoria que permite la asignación dinámica de memoria por parte de las tareas
de tiempo real usando un interfaz basado en una librería estándar de C.
3.
Posix Threads: RTAI tiene módulos que proporcionan la implementación
de threads de acuerdo al estándar POSIX.
Toda la información aquí descrita es una recopilación y/o traducción. La
información está disponible en las referencias [RTAI07] y [CICR07]. Para más
información acudir a estos enlaces.
118
RTAI-LAB
El RTAI-LAB viene incluido en la distribución RTAI, pero al ser una parte tan
importante en este proyecto es importante que sea explicada su funcionalidad aparte. El
RTAI-LAB proporciona una herramienta para desarrollar los diagramas de bloque que
pueden ser compilados y ejecutados sobre Linux con los parches RTAI. Los diagramas
de
bloque
pueden
ser
desarrollados
con
Scilab/Scicos
o
con
Matlab/Simulink/RealTimeWorkshop.
Las principales funcionalidades de RTAI-LAB son:
• Añaden una paleta RTAI-LIB de bloques de RTAI a Scicos para
desarrollar diagramas de bloque en tiempo real
• Permite al anfitrión y sistemas objetivo comunicar vía net_rpc
• Xrtailab el osciloscopio virtual y la supervisión del uso le deja actuar con
el en tiempo real ejecutable
• Generación de código automática en tiempo real de Scilab/Scicos
• Posibilidad de ejecutar proyectos de Matlab/Simulink/Real-TimeWorkshop en RTAI
• Interfaces para comunicar el hardware de adquisición y otros dispositivos
mediante Comedi
Toda la información aquí descrita es una recopilación y traducción. La
información está disponible en la referencias [RTAL07]. Para más información acudir a
estos enlaces.
119
eFLTK
FLTK es una librería de C ++ con un interfaz de usuario (GUI) y unas
instrucciones adaptado a diferentes sistemas operativos como UNIX /Linux, Microsoft
Windows y MacOS.
FLTK es utilizado para proporcionar muchos de los instrumentos básicos
necesarios para un sistema que funciona con ventanas- el gerente de ventana, el editor
de textos / el procesador de texto, la hoja de cálculos, la calculadora, etc. - así como
instrumentos de desarrollo como el FLUID.
OpenGL es el primer ambiente para desarrollar aplicaciones portables, que
muestren gráficos 2D y 3D.
GLUT es un juego de herramientas de tipo OpenGL, más concretamente una
herramienta que funcionan bajo un sistema de ventanas que permite la creación de
programas de tipo OpenGL. Lleva implementado una aplicación con una interfaz de
ventanas simple para OpenGL.
eFLTK es una modificación de FLTK. eFLTK proporciona una interfaz de
usuario (GUI) que apoya la programación gráfica 3D vía OpenGL e integra una
emulación de GLUT (OpenGL Utility Toolkit).
Toda la información aquí descrita es una recopilación y traducción. La
información está disponible en la referencia [EQUI07]. Para más información acudir a
estos enlaces.
120
MESA3D
Mesa3d es una implementación de código abierto de OpenGL (explicado
anteriormente), existe una gran variedad de dispositivos que permiten que Mesa pueda
ser utilizado en muchas plataformas diferentes. Este funcionamiento va desde la
emulación hasta su integración en hardware en los GPUs más actuales, procesadores
que están ubicados en las tarjetas gráficas.
A pesar de no ser una implementación oficial su uso se ha extendido y su
estructura, sintaxis e incluso la semántica de su API es como la de OpenGL. Mesa es
una librería muy útil porque se puede utilizar en prácticamente todas las plataformas y
sobretodo porque soporta varios tipos de aceleradores gráficos por hardware, también
puede ser compilado como un renderizador solamente de software.
Además Mesa3d se ha integrado en otros proyectos de código libre como puede
ser DRI (Direct Rendering Infraestructura) o X.org (un sistema de código abierto del
sistema X), un proyecto para dar soporte de OpenGL a usuarios de X (un sistema de
ventanas similar a Windows) en Linux, en FreeBSD y en otros sistemas operativos.
Toda la información aquí descrita es una recopilación y traducción. La
información está disponible en la referencia [MES07]. Para más información acudir a
estos enlaces.
121
COMEDI
Comedi es un proyecto de software libre para hacer un interfaz para las tarjetas
de adquisición de datos. Este proyecto se divide en dos partes fundamentales, Comedi,
Comedilib y Kcomedilib. Comedi funciona tanto con Linux como con Linux parcheado
mediante los parches de tiempo real RTAI y con RTLinux/GPL.
Comedi es una colección de drivers para una gran variedad de
tarjetas
adquisitoras de datos. Estos drivers están implementados como una combinación de los
siguientes elementos:
1.
Una módulo del kernel de Linux que proporciona las funciones
más comunes
2.
Módulos individuales para las funciones de bajo nivel para cada
dispositivo.
Comedilib es un paquete separado de Comedi que está compuesto por una
biblioteca que proporciona un interfaz de usuario para los dispositivos que utilizan
Comedi. Además en Comedilib está incluido la documentación, configuración y
unidades de calibración y programas de demostración.
Kcomedilib es un módulo del kernel de Linux, que viene en el mismo paquete
de Comedi, que proporciona el mismo interfaz que Comedilib, pero que está adaptado
para los sistemas de tiempo real. De esta forma todo el software Comedi puede ser
utilizado eficazmente en los sistemas de tiempo real.
Toda la información aquí descrita es una recopilación y traducción. La
información está disponible en la referencia [MES07]. Para más información acudir a
estos enlaces.
122
MATLAB
MATLAB es un lenguaje de alto rendimiento para la informática técnica. Esto
integra la computación, la visualización y programación en un ambiente amigable donde
los problemas y soluciones son expresados en notación matemática. Empleos típicos
incluyen:
•
Matemáticas y computación.
•
Desarrollo de algoritmos
•
Adquisición de datos
•
Modelado, simulación y prototipado.
•
Análisis de datos, exploración, y visualización
•
Gráficos científicos e ingenieriles.
•
Desarrollo de aplicaciones incluyendo interfaces de usuario.
MATLAB es un sistema cuyo elemento de datos básico es una serie que no
requiere dimensionarse. Esto le permite solucionar muchos problemas técnicos de
cálculo, sobre todo aquellos con la matriz y vectores, bastante más rápido que
programas escritos con otros lenguajes como C o Fortran.
Además MATLAB tiene una familia de toolboxes, que permiten solucionar
problemas concretos matemáticas e ingenieriles. Las toolboxes son colecciones de
funciones de MATLAB (los archivos m) que amplían el ambiente MATLAB para
solucionar tipos de problemas concretos. Las áreas en las cuales las toolboxes están
disponibles incluyen el tratamiento de señal, sistemas de control, redes neuronales, la
lógica borrosa, simulación y muchos otros.
MATLAB se compone de cinco componentes básicos:
1.
Desktop Tools y ambiente de desarrollo: este es el conjunto de
instrumentos que le ayudan a usar funciones de MATLAB y archivos.
2.
Librería de funciones matemáticas de MATLAB: es una colección de
algoritmos computacionales en las funciones elementales como la suma y el
123
seno y de otras más complejas como las funciones de Bessel y la transformada
de Fourier.
3.
Lenguaje MATLAB: es un lenguaje basado en matrices/series de alto
nivel con declaraciones de flujo de control, funciones, estructuras de datos,
entrada/salida.
4.
Gráficos: MATLAB tiene funcionalidades de mostrar vectores y matrices
como gráficos, así como anotar e imprimir estos gráficos.
5.
Interfaces externas de MATLAB/API
MATLAB es usado en ambientes académicos como el software básico para
cursos introductorios y avanzados en matemáticas, ingeniería, y la ciencia. En la
industria, MATLAB es el instrumento preferido para la investigación de productividad
alta, el desarrollo, y el análisis.
Toda la información aquí descrita es una traducción de la siguiente referencia
[MATL07]. Para más información acudir a estos enlaces.
124
SIMULINK
Simulink es un paquete de software para el modelado, el simulado, y el análisis
sistemas dinámicos. Se utiliza tanto para sistemas lineales como para no lineales,
modelados en el tiempo continuo, el tiempo discreto, o un híbrido de los dos. Simulink
permite tener acceso instantáneo a todas las herramientas de MATLAB mientras se
realiza el modelado lo cual permite el uso de cualquier función de MATLAB para el
modelado y el análisis de los modelos.
Simulink tiene un interfaz de usuario gráfico para construir modelos como
diagramas de bloque. Gracias este interfaz, se puede programar los modelos como si se
estuvieran dibujando con lápiz y papel. Simulink incluye una biblioteca de bloques con
las funcionalidades más utilizadas en los bloques lo que permite que con ajustar unos
pocos parámetros se pueda programar los bloques más básicos de los modelos de forma
sencilla, además también permite personalizar y crear sus propios bloques.
Al estar Simulink integrado con MATLAB permite la simulación tanto desde
Simulink como desde la ventana de comandos de la que dispone MATLAB y también
permite el acceso a las toolboxes que tiene MATLAB. Además Simulink posee una
amplia gama de menús que permite, entre otras funcionalidades, los resultados de la
simulación mientras se está ejecutando, lo cual es muy útil para el diagnóstico de
posibles fallos durante la simulación además de comprender más en profundidad el
funcionamiento de modelos desarrollados con esta herramienta.
Toda la información aquí descrita es una traducción de la siguiente referencia
[SIMU07]. Para más información acudir a estos enlaces.
125
REAL-TIME WORKSHOP
El Real-Time Workshop es una extensión de Simulink
y MATLAB
que
permite generar, empaquetar y compilar automáticamente el modelo creado mediante
Simulink para crear aplicaciones de software que funcionen con tiempo real. Además
proporciona un entorno de generación de código para un prototipado rápido y
despliegue de aplicaciones. Conjuntamente con otros instrumentos que proporciona
MATLAB el Real-Time Workshop proporciona las siguientes funcionalidades:
•
Generación de código adaptada para una variedad de plataformas, así
como una variedad de modelos.
•
Soporta arquitecturas con SO monoproceso, multiproceso e incluso sin
SO.
•
Una rápida implementación de los sistemas diseñados para el tiempo real.
•
Integración con MATLAB y Simulink.
•
Permite la supervisión del código dentro o fuera de Simulink.
•
Optimización de código para una mayor velocidad de ejecución de los
modelos.
•
Proporciona herramientas para la personalización del código así como
para su integración.
•
Un interfaz de usuario simple.
•
Una arquitectura abierta y flexible.
126
El proceso de generación de código que utiliza Real-Time Workshop utiliza el
siguiente esquema:
Toda la información aquí descrita es una recopilación y traducción de las
siguientes referencias. Toda la información aquí descrita es una traducción de la
siguiente referencia [RTW07] y [RTWE07]. Para más información acudir a estos
enlaces.
127
ISA
Descripción general
ISA se creó como un sistema de 8 bits para el PC en 1981, y se extendió en 1983
como el “XT bus architecture”. El nuevo estándar de 16 bits se introduce en 1984 y se le
llama habitualmente “AT bus architecture”. Diseñado para conectar tarjetas de
ampliación a la placa madre, el protocolo también permite el bus mastering aunque sólo
los primeros 16 MB de la memoria principal están disponibles para acceso directo. El
bus de 8 bits funciona a 4,77 MHz (la misma velocidad que el procesador Intel 8088),
mientras que el de 16 bits opera a 8 MHz (el del Intel 80286). Está también disponible
en algunas máquinas que no son compatibles PC, como el AT&T Hobbit (de corta
historia), los Commodore Amiga 2000 y los BeBox basados en PowerPC.
Los usuarios de máquinas basadas en ISA tenían que disponer de información
especial sobre el hardware que iban a añadir al sistema. Aunque un puñado de tarjetas
era esencialmente Plug-and-play, no era lo habitual. Frecuentemente había que
configurar varias cosas al añadir un nuevo dispositivo, como la IRQ, las direcciones de
entrada/salida, o el canal DMA.
Estos problema con la configuración llevaron a la creación de ISA PnP, un
sistema Plug-and-play que usa una combinación de modificaciones al hardware, la
BIOS del sistema, y el software del S.O. que automáticamente maneja los detalles más
comunes. En realidad, ISA PnP acabó convirtiéndose en un problema, debido a su mala
funcionalidad y a que nunca fue bien soportado excepto al final de la historia de ISA.
El ancho de banda máximo del bus ISA de 16 bits es de 16 MB/segundo. Salvo
para usos industriales especializados, ya no se emplea ISA. Aunque son físicamente
bastante diferentes, LPC se presenta ante el software como ISA, por lo que las
peculiaridades de ISA como el límite de 16 MB para DMA seguirán todavía presentes
por un tiempo.
128
Señales ISA
•
SA19 a SA0: Estas señales son usadas para direccionar la memoria y
dispositivos E/S dentro del sistema. Estas señales pueden ser usadas conjuntamente con
LA23 a LA17 para poder llegar hasta 16 MB de memoria.
•
LA23 a LA17: Estas señales son usadas para direccional la memoria
dentro del sistema.
•
AEN: Esta señal permite delegar el control de las operaciones DMA al
microprocesador y a otros dispositivos.
•
BALE: Esta señal se utiliza para poder cerrar el valor de LA23-LA17 y
descifrar el valor de estas señales.
•
CLK: Esta es la señal del reloj del sistema y su velocidad es de un rango
de 8MHz a 10MHz, aunque su frecuencia exacta no está garantizada. Este reloj se
utilizan en muchas tarjetas ISA para sincronizarse con el reloj del microprocesador.
•
SD15 a SD0: Estas señales sirven como datos para los dispositivos que
utilizan el bus ISA. SD15 es el bit más significativo y así sucesivamente hasta llegar a
SD0 que es el bit menos significativo.
•
DACK0 a DACK3 y DACK5 a DACK7: Estas señales son utilizadas
para reconocer las peticiones DMA sobre DRQ0-DRQ3 y DRQ5-DRQ7.
•
DRQ0-DRQ3 y DRQ5-DRQ7: Estas señales son utilizadas por las
tarjetas ISA para solicitar al DMA o al maestro del bus el control del bus.
•
I/O CH CK: Esta señal es activada por las tarjetas ISA para pedir que una
NMI(Non Maskerable Interrupt) pueda ser generado por el microprocesador.
129
•
I/O CH RDY: Esta señal permite alargar los ciclos de reloj del bus
mediante la inserción de ciclos de espera. Esta señal indica que el estado normal es
activo.
•
IOR: Esta señal sirve para indicar cuál es el dispositivo que va a escribir
en el bus.
•
IOW: Esta señal sirve para indicar cuál es el dispositivo que va a leer del
•
IRQ3-IRQ7, IRQ9- IRQ12 y IRQ14- IRQ15: Estas señales son utilizadas
bus.
para indicar al microprocesador que un dispositivo ISA requiere inmediata atención.
Estas señales son generadas cuando es activada la señal IRQ.
•
SMEMR: Esta señal permite a un dispositivo de memoria leer los datos
del bus. Esta señal sólo está activa cuando la memoria lee los datos en el MB menos
significativo.
•
SMEMW: Esta señal permite a un dispositivo de memoria enviar los
datos por el bus. Esta señal sólo está activa cuando la memoria escribe los datos en el
MB menos significativo.
•
MEMR: Esta señal permite a un dispositivo leer del bus y sólo está
activada en los ciclos de lectura.
•
MEMW: Esta señal permite a un dispositivo escribir en el bus y sólo está
activada en los ciclos de escritura.
•
REFRESH: Esta señal permite el refresco de una operación de memoria
que está teniendo lugar.
130
•
OSC: Esta señal es un reloj con un periodo de 70 ns que no está
sincronizada con la señal del reloj.
•
RESET DRV: Esta señal permite la inicialización de una unidad lógica o
como consecuencia la inicialización de todo el sistema.
•
TC: Esta señal proporciona un pulso que permite conocer que una
operación DMA ha sido terminada satisfactoriamente.
•
MASTER: Esta señal es utilizada por una tarjeta ISA conjuntamente con
la señal DQR para obtener el control del bus.
•
MEM CS16: Esta señal es controlada por un dispositivo esclavo de
memoria que puede transferir datos de 16 bits. Esta señal es conducida gracias a la
decodificación de las señales LA23-LA17.
•
I/O CS16: Esta señal es controlada por un dispositivo E/S que es capaz
de realizar transferencias de datos de 16 bits. Esta señal es conducida gracias a la
decodificación de las señales SA15-SA0.
•
0WS: Esta señal es producida por un dispositivo esclavo del bus ISA
para indicar la capacidad de realizar un ciclo de reloj sin insertar cualquier estado de
espera adicional. Para realizar un ciclo de 16 bits sin estados de espera, esta señal es
deshabilitada.
•
SBHE: Esta señal indica una transferencia a realizar sólo sobre la mitad
más significativa del bus de datos (D15-D8).
131
Uso de las señales ISA
Esta tabla indica el uso de las señales en una tarjeta ISA:
Nombre señal
AEN
BALE
CLK
DACK
DRQ
IO CS16
I/O CH CK
I/O CH RDY
IOR
IOW
IRQ
LA
MASTER
Uso en el sistema
S
S
S
S
E
E
E
E/S
E/S
E/S
E
E/S
E
Nombre señal
MEM CS16
MEMR
MEMW
OSC
REFRESH
RESET DRV
SA
SD
SBHE
SMEMR
SMEMW
TC
0WS
Uso en el sistema
E/S
E/S
E/S
S
E/S
S
E/S
E/S
E/S
E/S
E/S
E/S
E
La siguiente tabla muestra el uso de las diferentes tarjetas de expansión ISA:
Nombre señal
ISA
Bus
Maestro
ISA
16-bit
Mem Esclava
ISA 16-bit
E/S Esclava
AEN
BALE
CLK
DACK
DRQ
IO CS16
I/O CH CK
I/O CH RDY
IOR
IOW
IRQ
LA (23:17)
MASTER
MEM CS16
MEMR
MEMW
OSC
REFRESH
RESET DRV
SA(16:0)
SA(19:17)
SD(7:0)
SD(15:8)
SBHE
SMEMR
SMEMW
TC
0WS
(E)
E
S
E
(S)
E
S
S
(S)
S
S
E
S
S
(E)
(S)
E
S
E/S
E/S
S
-
E
(E)
(S)
(S)
(S)
E
S
E
E
(E)
E
E
E
(E)
E/S
E/S
E
(S)
E
(E)
S
(S)
(S)
E
E
(S)
(E)
E
E
E/S
E/S
E
E
E
-
132
ISA 8-bit
Mem Esclava
(E)
(E)
(S)
(S)
(S)
(E)
(E)
(E)
(E)
E
E
E
(E)
E/S
(S)
ISA
8-bit
E/S Esclava
ISA DMA
Dispositivo
E
(E)
(S)
(S)
E
E
(S)
(E)
E
E
E/S
(S)
(E)
E
S
(S)
E
E
(S)
(E)
E
E/S
(E/S)
(E)
-
Conectores ISA
Esta es la distribución de los conectores ISA en las tarjetas ISA para cada señal:
133
Toda la información aquí disponible es una traducción. Toda la información está
disponible en la referencia [TECI07]. Para más información acudir a estos enlaces.
134
PCI
Descripción general
PCI es un bus de alto rendimiento para interconectar chips, tarjetas y
subsistemas de procesador/memoria. A diferencia de los buses ISA, el bus PCI permite
configuración dinámica de un dispositivo periférico. En el tiempo de arranque del
sistema, las tarjetas PCI y el BIOS interactúan y negocian los recursos solicitados por la
tarjeta PCI. Esto permite asignación de IRQs y direcciones del puerto por medio de un
proceso dinámico diferente del bus ISA, donde las IRQs tienen que ser configuradas
manualmente usando jumpers externos. Aparte de esto, el bus PCI proporciona una
descripción detallada de todos los dispositivos PCI conectados a través del espacio de
configuración PCI.
Descripción del protocolo
PCI es una arquitectura sincrónica de bus con todas las transferencias realizadas
bajo un reloj de sistema (CLK). En la especificación PCI inicial de reloj trabaja a un
período de 33 MHz. Más tarde, la Revisión 2.1 de PCI amplió el período de reloj a 66
MHz.
PCI tiene direcciones de 32 bits multiplexadas y el bus de Datos (el AD 31:0]).
Este protocolo permite una compatibilidad con buses de 64 bits. En 33 MHz, una ranura
32 bits tiene unas tasas de transferencia de datos máxima de 132MB/S, y con 64 bits
una tasa de 264MB/S.
La multiplexación de direcciones y el bus de datos permiten una localización del
pin en el conector PCI que un coste más bajo y el uso de paquetes más pequeños para
los conectores PCI. El PCI de 32 bits añade - en la pasarela se usan aproximadamente
50 pines de señales sobre el conector PCI de cual 32 es la dirección multiplexada y el
bus de datos. Los ciclos del bus PCI son iniciados por una señal de una dirección en
AD[31:0] durante el inicio de un ciclo de reloj. Esta fase es indicada en el bus por la
135
activación de la señal FRAME. En el siguiente período de reloj comienza el primero de
una o varias fases en las cuales los datos son transferidos en AD[31:0].
Una transferencia PCI consiste en una fase de direccionamiento y un número
indeterminado de fases de transferencias de datos. Las operaciones de entrada-salida
que tienen acceso a registros dentro de PCI normalmente tienen sólo una fase de
transferencias de datos. Las transferencias de memoria que mueven varios bloques de
datos consisten en múltiples fases de transferencias de datos que leen o escriben
múltiples posiciones de memoria consecutivas. Tanto el maestro como el esclavo
pueden terminar una transferencia de bus en cualquier momento.
PCI tiene un mecanismo de configuración automática. Cada dispositivo PCI
incluye un juego de registros de configuración que permiten la identificación del tipo
de dispositivo (SCSI, vídeo, Ethernet, etc.) y la empresa que lo fabricó. Otros registros
permiten la configuración de las direcciones de entrada-salida del dispositivo,
direcciones de memoria, niveles de las interrupciones, etc.
PCI apoya la dirección de 64 bits, a diferencia de la opción de bus de datos de 64
bits que requiere un conector más largo con 32 bits adicionales en el bus de datos, los
64 bits pueden ser apoyados bajo un bus de 32 bits. PCI define la posibilidad de
trabajar tanto a 5 voltios como a 3.3 voltios.
PCI incluye datos específicos para asegurar la calidad de señal requerida en
operaciones a 33 y 66 MHz.
La velocidad máxima de PCI limita el slots sobre un bus a 3 o 4, bastante menos
que en anteriores arquitecturas que permitían 6 o 7. Para permitir más slots, el PCI SIG
ha definido unos puentes de PCI-to-PCI. Puentes PCI-to-PCI son básicamente ASICs
(Application-specific Integrated Circuits) que aíslan eléctricamente dos buses PCI
permitiendo además transferencias de un bus a otro.
136
Descripción de las señales de PCI
•
CLK: La señal del reloj proporciona la referencia para la sincronización
de todas las operaciones sobre PCI. Todas las operaciones PCI son ejecutadas al
iniciarse el ciclo de reloj. Todos los datos de tiempo de acceso al bus son
definidos en relación al período del reloj.
•
RST: Esta señal sirve para resetear los dispositivos PCI. La activación de
esta señal supone la inicialización de los registros de configuración, de la
máquina de estados y de las señales de salida.
•
AD[31:0]: Las direcciones y los datos son indicadas en estas señales.
AD[31:0] transfiere una dirección de 32 bits durante las "fases de dirección", y
transfiere datos de 32 bits durante las "fases de datos". Una fase de dirección
ocurre durante periodo de reloj se desactiva la señal FRAME. Una fase de datos
ocurre cuando IRDY y TRDY están desactivadas. Durante las fases de escritura
el maestro conduce los datos válidos sobre AD[31:0] durante cada ciclo. El
maestro también conduce TRDY desactivado cuando el dispositivo es capaz de
aceptar los datos que escritos. Cuando IRDY y TRDY son bajos, el maestro
captura los datos escritos y la transacción es completada. Para las transacciones
de lecturas el proceso es el opuesto. El bit 31 es el bit más significativo y así
sucesivamente hasta el bit 0, que es el menos significativo.
•
C/BE[3:0]: Esta señal sirve para indicar la instrucción correspondiente.
Durante la fase de dirección de una transacción estas señales llevan la
instrucción del bus que define el tipo de transferencia a realizar. Aquí debajo se
adjunta una tabla con la codificación de estas señales y el mandato que indica
cada codificación:
C/BE[3:0]
Comando
0000
Interrupción
0001
Ciclo especial
0010
E/S lectura
137
0011
E/S escritura
0100
Reservado
0101
Reservado
0110
Lectura memoria
0111
Escritura memoria
1000
Reservado
1001
Reservado
1010
Leer configuración
1011
Escribir configuración
1100
Lectura múltiple memoria
1101
Ciclo dual direcciones
1110
Leer línea memoria
1111
Escritura memoria e invalidación
•
PAR: Esta señal indica la paridad entre las señales AD[31:0] y
C/BE[3:0]. Esta se indica diciendo si hay un número par de '1's en las dos
señales anteriores conjuntamente con la señal PAR. La señal de PAR se
distribuye de la misma forma que el AD[31:0] señala, pero su valor está
retrasado por un ciclo para tener el tiempo suficiente para calcular la paridad
válida.
•
FRAME: Esta señal indica el inicio de una nueva transacción en el bus.
La fase de dirección ocurre durante el primer ciclo de reloj estando desactivada
la señal FRAME. Si el maestro tiene la intención de realizar una transacción con
sólo una fase de datos, entonces esto devolverá el FRAME activado después de
un ciclo. Si múltiples fases de datos deben ser realizadas, el iniciador sostendrá
el FRAME desactivado en todas las fases excepto en la última.
•
IRDY: Esta señal indica que el dispositivo está listo para completar la
fase de datos actual de la transacción. Durante las fases de escritura esta señal
indica que los datos son válidos para AD[31:0]. Durante las fases de lectura esta
señal indica que los datos colocados en AD[31:0] son válidos. Una vez
confirmado, el iniciador sostiene IRDY desactivado hasta que TRDY esté
desactivado para completar la transferencia, para abortarlo mediante la señal
138
STOP. IRDY permite al iniciador insertar estados de espera para reducir la tasa
de transferencia de datos.
•
TRDY: Esta señal indica que el dispositivo está listo para completar la
fase de datos completa de la transacción. Durante las fases de escritura esta señal
indica que el objetivo está listo para aceptar datos en AD[31:0]. Durante las
fases de lectura esta señal indica que los datos colocados en AD[31:0] son
válidos. Una vez confirmado, el objetivo mantiene TRDY desactivado hasta que
IRDY esté activado. TRDY permite al objetivo insertar estados de espera para
reducir la tasa de transferencia de datos.
•
STOP: Esta señal sirve para cancelar o abortar la transacción en curso.
En el caso de que un objetivo requiere un período largo de tiempo para
responder a una transacción, señal se puede utilizar para suspender la
transacción y poder atender a otras que estén esperando y requieran un menor
tiempo.
•
LOCK: Esta señal se utiliza para que un dispositivo pueda indicar un
acceso selectivo a otro dispositivo con el fin de realizar una serie de
transacciones con un objetivo concreto. Esto impide a otros dispositivos que
puedan acceder a memoria hasta que el dispositivo que realiza las transacciones
acabe todas estas. Sólo una parte específica de memoria (como mínimo 16 bits)
es bloqueada para este acceso exclusivo.
•
IDSEL: Esta señal se utiliza como un chip-select en el momento de la
configuración de las transacciones tanto de lectura como de escritura. Esta señal
permite a la configuración de PCI direccionar unívocamente cada dispositivo
PCI del sistema.
•
DEVSEL: Esta señal está desactivada cuando es detectada la dirección de
un dispositivo PCI en el bus PCI. DEVSEL puede aparecer en uno, dos, o tres
periodos de reloj después de la fase de direccionamiento.
139
•
REQ: Esta señal se utiliza para que un dispositivo pida el uso del bus.
Cada dispositivo PCI tiene una señal REQ propia.
•
GNT: Esta señal se utiliza para que un dispositivo pida el uso del bus.
Cada dispositivo PCI tiene una señal GNT propia.
•
PERR: Esta es una señal de error indica un error de paridad durante las
transacciones excepto en ciclos especiales. PERR está desactivado dos períodos
de reloj después de la fase de datos con la paridad errónea.
•
SERR: Esta señal sirve para indicar errores de paridad de dirección,
errores de paridad de datos durante un ciclo especial, o cualquier otro error de
sistema.
•
INTA, INTB, INTC, INTD: Estas señales son de interrupción que piden
a los dispositivos PCI atención inmediata a las transacciones de estos
dispositivos.
Además de las señales anteriormente indicadas hay otras señales optativas
que permiten aumentar la funcionalidad de PCI.
140
Esta es un esquema de la distribución de las señales PCI:
Toda la información aquí disponible es una traducción. Toda la información está
disponible en la referencia [TECP07]. Para más información acudir a estos enlaces.
141
PCL-812PG
Descripción general
PCL-812PG es una tarjeta de adquisición de datos multifunción, de alto
rendimiento para IBM PC/XT/AT y ordenadores compatibles. Las especificaciones de
esta tarjeta y el software de apoyo que viene con ella lo hacen el ideal para una amplia
gama de usos en ambientes industriales y de laboratorio. Estos usos incluyen la
adquisición de datos, el control de procedimiento, pruebas automáticas y la
automatización de procesos de una fábrica.
Características
Las características más relevantes de esta tarjeta son:
1.
16 canales de entrada analógicos.
2.
Un convertidor industrial estándar de entradas analógicas a entradas de
12 bits(HADC574Z).
3.
Un software programable para un amplio rango de entrada de la señal
analógica.
4.
Bipolar: +/- 5V, +/- 2.5 V, +/- 1.25V +/- 0.625 V +/- 0.3125 V
5.
Tres métodos de hacer trigger con A/D: software trigger, programmable
pacer trigger y external pulse trigger
6.
La capacidad de transferir datos de entrada digitalizados por el programa
de control, interrumpir la rutina de tratamiento de las transferencias DMA.
7.
Un temporizador/contador programable Intel 8253-5 que nos proporciona
una salida (con un pulso de trigger) a una tasa de 0.5 MHz a 35 minutos/pulso.
El tiempo base del temporizador es 2 MHz. Un contador de 16 bits es reservado
para usos de configuración de aplicaciones del usuario.
142
8.
Dos canales de 12 bits de salida que realizan la conversión D/A. El rango
de salida de 0 a +5V o 0 a +10V puede ser creado utilizando en la tarjeta una
referencia de -5v o de-10v. Esta precisión en la referencia es obtenida por el
conversor A/D. La corriente alterna externa o corriente continua también pueden
ser usadas generar diferentes rangos de salidas D/A.
9.
16 entradas digitales compatibles con TTL/DTL y 16 canales de salida
digitales.
Especificaciones técnicas
Entrada analógica:
Canales
Resolución
Rango Entradas
Sobre-Voltaje
Tipo de conversión
Conversor
Exactitud
Linealidad
Método Trigger
Transferencia datos
Trigger Externo
16 canales de una sola dirección
12 bits
Bipolar +/- 10V, +/- 5V, +/- 2.5V, +/- 1.25V, +/- 0.625V, +/- 0.3125V.
+/-30 V de forma sostenible máximo
Aproximaciones sucesivas
HADC574Z
0.015% de lecturas +/- 1 bit
+/- 1 bit
Mediante software, temporizador o externo.
Mediante programa, interrupciones o DMA
TTL o compatible
Salida analógica:
Canales
Resolución
Rango salidas
Voltaje
Tipo de conversión
Dispositivos analógicos
Linealidad
Conductor salida
Tiempo colocación
2 canales
12 bits
De +10V a -10V como máximo
-5V, -10V interno y DC o AC, +/- 10 V máx. externo
Multiplicación monolítica de 12 bits
AD7541AKN o equivalente
+/- 1 o 2 bits
+/- 5mA máximo
30 microsegundos
Entrada digital:
Canales
Niveles
Voltaje entrada
Voltaje carga
16 bits
TTL o compatible
De 0.8V a 2.0V como mínimo
De 0.4V a 0.5V como mínimo y de 0.05V a 2.7V como máximo
143
Salida digital:
Canales
Niveles
Voltaje salida
16 bits
TTL o compatible
De 8 mA a 0.5V como mínimo y de -0.4mA a 2.4V como máximo
Temporizador/contador programable:
Dispositivo
Contadores
Puerta entrada
Tiempo base
Salida
Intel 8253
3 canales de 16 bits, 2 canales conectados al reloj y uno libre
TTL/DTL/CMOS o compatible
2MHz
35 minutos/pulso a 0.5 MHz
Canales de interrupción:
Niveles
Activados
IRQ 2 a 7,10,11,12,14,15 jumpers seleccionables
Por S0,S1 y S2 del registro de control
Canales DMA:
Niveles
Activados
1 o 3 jumpers seleccionables
Por S0,S1 y S2 del registro de control
Especificaciones Generales:
Consumo energía
+5V: typ. 500 mA, max 1A
+12 V: typ. 50 mA, max 100 mA
Conectores E/S
-12V: typ. 14 mA, max 20 mA
20 pins para conexiones de E/S.
Direcciones base E/S
Adaptador disponible para conversores de 37 pins.
Necesita 16 direcciones consecutivas.
Temperaturas funcionamiento
Temperaturas almacenamiento
Peso
La dirección base viene definida en el switch DIP en las
líneas A8-A4.
De 0 a +50 C
De -20 a +65 C
243 gramos
144
Diagrama de bloques
Este es el diagrama de bloques de la tarjeta PCL-812PG:
145
Registros
Los registros de E/S son los siguientes:
Localización
Lectura
Escritura
Dirección base + 0
Dirección base + 1
Dirección base + 2
Dirección base + 3
Dirección base + 4
Dirección base + 5
Dirección base + 6
Dirección base + 7
Dirección base + 8
Dirección base + 9
Dirección base + 10
Dirección base + 11
Dirección base + 12
Dirección base + 13
Dirección base + 14
Dirección base + 15
Contador 0
Contador 1
Contador 2
No usado
A/D byte bajo
A/D byte alto
D/I byte bajo
D/I byte alto
No usado
No usado
No usado
No usado
No usado
No usado
No usado
No usado
Contador 0
Contador 1
Contador 2
Control contador
CH1 D/A byte bajo
CH1 D/A byte alto
CH2 D/A byte bajo
CH2 D/A byte alto
Limpiar petición interrupción
Ganar control
Control MUX
Control modo
A/D trigger de software
D/O byte bajo
D/O byte alto
No usado
Los datos de los registros A/D son:
Registro
Bit 0
Bit 1
Bit 2
Bit 3
Bit 4
Bit 5
Bit 6
Bit 7
A/D byte alto
A/D byte bajo
Control MUX
D/I byte bajo
D/0 byte bajo
D/I byte alto
D/O byte alto
CH1 D/A byte bajo
CH1 D/A byte alto
CH2 D/A byte bajo
CH2 D/A byte alto
Ganar control
Control modo
Control controlador
AD8
AD0
CL0
DI0
DO0
DI8
DO8
DA0
DA8
DA0
DA8
R0
S0
BCD
AD9
AD1
CL1
DI1
DO1
DI9
DO9
DA1
DA9
DA1
DA9
R1
S1
M0
AD10
AD2
CL2
DI2
DO2
DI10
DO10
DA2
DA10
DA2
DA10
R2
S2
M1
AD11
AD3
CL3
DI3
DO3
DI11
DO11
DA3
DA11
DA3
DA11
X
X
M2
DRDY
AD4
X
DI4
DO4
DI12
DO12
DA4
X
DA4
X
X
X
RW0
0
AD5
X
DI5
DO5
DI13
DO13
DA5
X
DA5
X
X
X
RW1
0
AD6
X
DI6
DO6
DI14
DO14
DA6
X
DA6
X
X
X
SC0
0
AD7
X
DI7
DO7
DI15
DO15
DA7
X
DA7
X
X
X
SC1
AD11-AD0 son los datos de analógico a digital, es decir la entrada analógica, y
van de menos significativo a más significativo.
DRDY es la señal de lectura de datos, cuando los datos A/D aún no están listos
está señal está a 1. Este bit toma el valor 0 cuando una conversión se ha completado y
vuelve a 1 cuando se está leyendo el registro de A/D byte bajo.
CL3-CL0 son el número del canal multiplexado
146
DA11-DA0 son los datos de digital a analógico y van de menos significativo a
más significativo. El registro D/A byte bajo está guardado doblemente ya que cuando
estamos escribiendo en el D/A byte alto el D/A byte bajo se envía a D/A conversor al
mismo tiempo.
R2-R0 tiene los posibles valores:
R2
0
0
0
0
1
1
1
1
R1
0
0
1
1
0
0
1
1
R0
0
1
0
1
0
1
0
1
Ganar control
1
2
4
8
16
Invalido
Invalido
Invalido
S2-S0 tiene los siguientes valores posibles:
•
S2
0
0
0
1
JP1 es interno:
S1
0
0
1
1
•
S2
0
0
1
S0
0
1
0
0
Modo
Deshabilitar software y pacer trigger
Habilitado trigger de software y sólo transferencias. ON
Habilitado pacer trigger y sólo transferencias DMA
Habilitado pacer trigger y transferencias o interrupciones.
JP1 es externo
S1
0
1
1
S0
X
0
0
Modo
Habilitar sólo trigger externo
Habilitar trigger externo y transferencias DMA
Habilitar transferencias e interrupciones usando trigger externo
SC1-SC0 tienen los posibles valores:
SC1
0
0
1
1
SC0
0
1
0
1
Contador
0
1
2
Ilegal
RW1-RW0 tienen los posibles valores:
147
RW1
0
0
1
1
RW0
0
1
0
1
Operación
Lanzar contador
Leer/Escribir LSB
Leer/Escribir MSB
Leer/Escribir LSB primero, luego leer/escribir MSB
M2-M0 tienen los posibles valores:
M2
0
0
X
X
1
1
M1
0
0
1
1
0
0
M0
0
1
0
1
0
1
Modo
Interrupción en el contador
Un pulso programable
Generador de reloj
Generador de onda cuadrada
Trigger de software
Trigger de hardware
BCD es el bit de contador BCD, si tiene valor 0 es un contador binario de 16
bits(0-65535), en cambio si tiene valor 1 es un contador decimal (0-9999).
Toda la información aquí disponible es una traducción. Toda la información está
disponible en la referencia [PCL801]. Para más información acudir a estos enlaces.
148
PWM
Descripción general
Esta es la tarjeta de modulación que ha sido diseñada y desarrollada por D. Omar
Pinzón Ardilla en la elaboración de su tesis titulada Compensación Selectiva de
Armónicos Mediante Filtros Activos de Potencia.
La función principal de esta tarjeta es el control de los disparos de los inversores
de los motores trifásicos, realizando de interfaz entre el programa de control y los
interruptores de potencia de los inversores. Esta placa tiene la singularidad de poder
controlar dos inversores trifásicos simultáneamente.
El tiempo de muestreo del programa de control es independiente del tiempo de
conmutación de la modulación de ancho de pulso y la frecuencia de conmutación de la
modulación de ancho de pulso puede hacerse mayor que la frecuencia de muestreo. La
frecuencia de la tarjeta es de 8.333 KHz. Los registros de la tarjeta tienen un tamaño de
2 bytes (1 palabra).
La dirección está fijada en la placa de circuito impreso, esta dirección es de tipo
ISA y su valor es 0x300.
Esta tarjeta tiene una memoria FPGA, por ello se debe programar si se quiere
trabajar con ella, pero esto se sale del ámbito de nuestro proyecto.
Como característica relevante podemos destacar que esta tarjeta necesita ser
alimentada directamente, es decir no obtiene la potencia mediante el bus, para ello tiene
dos conectores asignados. Uno de ellos está asignado a la zona de la memoria y el
encoger, el cual debe estar siempre conectado, mientras que el otro está conectado a las
salidas, y debemos tenerlo conectado para conocer el valor de estas salidas.
149
Registros
Los registros de esta tarjeta son:
Dirección
00h
Nombre
REG0_R1 /REG_ENCODER
Función
Datos
02h
REG0_R2
Datos
04h
REG0_R3
Datos
06h
REG0_R4
Datos
08h
REG0_R5
Datos
0Ah
REG0_R6
Datos
0Ch
GATE
Datos
1Ch
REG_CTL
Inicia la tarjeta y la para
1Eh
REG_INT
Para controlar las interrupciones
Los registros aquí mostrados son los utilizados, aunque existen más direcciones
de memoria, registros, que de momento no han sido utilizados. La dirección está puesta
como relativa
a la dirección base de la tarjeta, que como se ha mencionado
anteriormente es 0x300 dentro del bus ISA.
150
PCI 9052
Descripción general
Este es el componente hardware que nos permitirá hacer la conversión entre el
bus PCI existente en los PCs y el bus ISA al que deben ir conectadas las tarjetas. A
continuación vamos a pasar a explicar los puntos principales de este bridge y de la
conversión entre los diferentes protocolos de bus. El diagrama de bloques del bridge es
el siguiente:
151
Registros de configuración PCI
Dirección de
Registros
Configuración
PCI
Para asegurar la compatibilidad con otras versiones de la familia PCI 9052 y otros
dispositivos, todos los bits no utilizados deben estar a 0.
31
24 23
16
15
8 7
0
Modificables
por PCI
Modificables
por
Serial
EEPROM
00h
Device ID
Vendor ID
No
Si
04h
Status
Command
Si
No
08h
Class Code
Revision ID
No
Solo[31:8]
0Ch
Built-In Self Test (No
soportado)
Cache Line Size
Solo[7:0]
No
10h
PCI Base Address 0 for Memory Accesses to Local Configuration Registers
Si
No
14h
PCI Base Address 1 for I/O Accesses to Local Configuration Registers
Si
No
18h
PCI Base Address 2 for Accesses to Local Address Space 0
Si
No
1Ch
PCI Base Address 3 for Accesses to Local Address Space 1
Si
No
20h
PCI Base Address 4 for Accesses to Local Address Space 2
Si
No
24h
PCI Base Address 5 for Accesses to Local Address Space 3
Si
No
28h
PCI Cardbus Information Structure (CIS) Pointer (No soportado)
No
No
2Ch
Subsystem ID
No
Si
30h
PCI Expansion ROM Base Address
Si
No
34h
Reservados
No
No
38h
Reservados
No
No
3Ch
Maximum
Latency
(No soportado)
Solo[7:0]
Solo[15:8]
PCI Bus Latency
Timer
(No
soportado)
Header Type
Subsystem Vendor ID
Minimum
Grant
(No soportado)
Interrupt Pin
Interrupt Line
Información registro 00h
Bit
Descripción
Lectura
Escritura
Valor
después
reset
15:0
Vendor ID. Identifica al fabricante de dispositivo. Este valor depende del PCI SIGissued ID o del número PLX, o está en blanco si no hay ninguna EEPROM.
Si
Serial
EEPROM
10B5h
31:16
Device ID. Identifica el dispositivo particular. Este valor depende del número del
PLX para el interfaz PCI o está en blanco si no hay ninguna EEPROM.
Si
Serial
EEPROM
9050h
152
Información registro 04h (Status)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
I/O Space. El valor de 1 permite al dispositivo responder a accesos de E/S. El valor de
0 impide al dispositivo responder a accesos de E/S.
Si
Si
0
1
Memory Space. El valor de 1 permite al dispositivo responder a accesos a memoria.
Un valor de 0 impide al dispositivo responder a accesos a memoria.
Si
Si
0
2
Master Enable. No soportado.
Si
No
0
3
Special Cycle. No soportado.
Si
No
0
4
Memory Escritura/Invalidate.No soportado.
Si
No
0
5
VGA Palette Snoop.No soportado.
Si
No
0
Si
Si
0
6
Parity Error Response. El valor de 0 indica que los errores de paridad son ignorados.
El valor de 1 indica que permiten los errores de paridad son tenidos en cuenta. [PERR
y SERR, si permiten SERR está activo entonces PCICR [8] =1]. El error de la paridad
siempre es obtenido en PCISR[15].
7
Wait Cycle Control. Controla si el dispositivo hace pasos de dirección/datos. El
valor de 0 indica que el dispositivo nunca sigue estos pasos. El valor de 1 indica que el
dispositivo siempre sigue estos pasos.
Nota: Valor predeterminado a 0.
Si
No
0
8
SERR# Enable. El valor de 1 permite el funcionamiento de SERR. El valor de 0
impide el funcionamiento de SERR.
Si
Si
0
9
Fast Back-to-Back Enable. Indica qué tipo de transferencias rápidas de un
dispositivo a otro puede hacer el maestro en el bus. El valor de 1 indica que
transferencias rápidas de un dispositivo a otro pueden ocurrir a cualquier agente sobre
el bus. El valor de 0 indica que transferencias rápidas de un dispositivo a otro sólo
pueden ocurrir mismo agente que el ciclo anterior.
Si
No
0
15:10
Reservado
Si
No
0h
153
Información registro 04h(Command)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
6:0
Reservado
Si
No
0h
7
Fast Back-to-Back Capable. El valor de 1 indica que el adaptador puede aceptar
transacciones rápidas de un dispositivo a otro. El valor de 0 indica que el adaptador no
puede aceptar transacciones rápidas de un dispositivo a otro.
Si
No
1
8
Master Data Parity Error Detected. No soportado.
Si
No
0
10:9
DEVSEL Timing. Indica el tiempo para la aceptación de DEVSEL. El valor de 01 es
medio.
Si
No
01
11
Signaled Target Abort. El valor de 1 indica que el PCI 9052 señaló un Aborto
Objetivo. El valor de 1 limpia el bit (0).
Si
Si/Clr
0
12
Received Target Abort. El valor de 1 indica que el PCI 9052 recibió una señal de
Aborto Objetivo. No soportado.
Si
No
0
13
Received Master Abort. El valor de 1 indica que el PCI 9052 recibió una señal de
Aborto del maestro. No soportado.
Si
No
0
14
Signaled System Error. El valor de 1 indica que el PCI 9052 recibió un error de
sistema en la señal SERR. El valor de 1 el bit(0).
Si
Si/Clr
0
Detected Parity Error. El valor de 1 indica que el PCI 9052 detectó en un bus del
PCI un error de paridad, aunque el tratamiento de este error esté desactivado [el bit
Parity Error Response de Command está a 0,PCICR [6] =0]. Una de estas dos
condiciones puede hacer este bit sea fijado cuando el PCI 9052 detecta un error de
paridad:
1) Durante una fase de la direccionamiento del PCI;
2) Cuando era objeto de una escritura. Escribir 1 deja este bit a 0.
Si
Si/Clr
0
15
Información registro 08h(Revision ID)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
7:0
Revision ID. PCI 9052 Silicon revisión.
Si
No
2h
Información registro 08h(Class Code)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
7:0
Specific Register Level Programming Interface. Ninguno especificado.
Si
Serial
EEPROM
00h
15:8
Subclass Encoding (80h). (Otro dispositivo bridge)
Si
Serial
EEPROM
80h
23:16
Base Class Encoding. (Dispositivo bridge)
Si
Serial
EEPROM
06h
154
Información registro 0Ch(Header Type)
Bit
Descripción
Lectura
Escritura
Valor después
reset
6:0
Configuration Layout Type. Especifica la disposición de registros 10h por 3Fh en el
espacio de configuración. El tipo 0 es definido para todos los dispositivos PCI excepto
puentes de PCI-TO-PCI (el tipo es 1) y puentes de Cardbus (el tipo es 2).
Si
No
0h
Si
No
0
7
Multi-Function Device. El valor 1 indica múltiple (hasta ocho) funcionalidad en cada
dispositivo, el espacio de configuración direccionable es de 64 Lwords.
Note: Valor predeterminado a 0 (es decir, no hay multifunción).
Información registro 0Ch(System Cache Line Size)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
7:0
System Cache Line Size. Especifica el tamaño de la línea de caché en Lwords de 32
bites. Puede ser escrito y leído, sin embargo, el valor no afecta a las operaciones de
PCI 9052.
Si
Si
0h
Lectura
Escritura
Valor
después
reset
Si
No
0
Si
No
00
Información registro 10h
Bit
0
2:1
Descripción
Memory Space Indicator. El valor de 0 indica que el mapa de registros está en el
espacio de Memoria. El valor de 1 indica que el mapa de registros está en el espacio
de E/S.
Note: Valor predeterminado a 0.
Register Location. Valores:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
Nota: Valor predeterminado a 0.
3
Prefetchable. El valor a 1 indica que no hay ningún efecto en las lecturas.
Nota: Valor predeterminado a 0.
Si
No
0
6:4
Memory Base Address. La dirección base de memoria para el acceso a los registros
de configuración locales. (Usa 128 bytes).
Nota: Valor predeterminado a 0.
Si
No
000
31:7
Memory Base Address. Dirección base de memoria para acceso a registros de
configuración locales.
Si
Si
0h
155
Información registro 14h
Bit
0
Descripción
Memory Space Indicator. . El valor de 0 indica que el mapa de registros está en el
espacio de Memoria. El valor de 1 indica que el mapa de registros está en el espacio
de E/S.
Nota: Valor predeterminado a 1.
Lectura
Escritura
Valor
después
reset
Si
No
1
1
Reservado.
Si
No
0
6:2
I/O Base Address La dirección base de E/S para el acceso a los registros de
configuración locales. (Usa 128 bytes).
Nota: Valor predeterminado a 0.
Si
No
0h
31:7
I/O Base Address. Dirección base de E/S para acceso a registros de configuración
locales.
Si
Si
0h
Lectura
Escritura
Valor
después
reset
Si
No
0
Si
Mem: No
E/S: Bit 1
No, Bit 2 Si
00
Si
Mem: No
E/S: Si
0
Si
Si
0h
Información registro 18h
Bit
0
2:1
3
31:4
Descripción
Memory Space Indicator. El valor de 0 indica que el mapa de registros está en el
espacio de Memoria. El valor de 1 indica que el mapa de registros está en el espacio
de E/S. (Especificado en el registro LAS0RR.)
Register Location (If Memory Space). Valores:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
(Especificado en el registro LAS0RR.)
Si hay espacio de E/S, el bit 1 está siempre a 0 y el 2 está incluido en la dirección
base.
Prefetchable (If Memory Space). El valor a 1 indica que no hay ningún efecto en las
lecturas. Refleja el valor de LAS0RR [3] y proporciona sólo el estado al sistema. No
afecta a las operaciones de PCI 9052. El registro LAS0BRD asociado al bus controla
las funciones de prefetching de este espacio de dirección. Si hay espacio de E/S
entonces el bit 3 es incluido en la dirección base.
Base Address. Dirección base, para el acceso local al espacio 0.
156
Información registro 1Ch
Bit
0
2:1
3
31:4
Descripción
Memory Space Indicator. El valor de 0 indica que el mapa de registros está en el
espacio de Memoria. El valor de 1 indica que el mapa de registros está en el espacio de
E/S. (Especificado en el registro LAS1RR)
Register Location. Valores:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
(Especificado en el registro LAS1RR.)
Si hay espacio de E/S, el bit 1 está siempre a 0 y el 2 está incluido en la dirección base.
Prefetchable (If Memory Space). El valor a 1 indica que no hay ningún efecto en las
lecturas. Refleja el valor de LAS1RR [3] y proporciona sólo el estado al sistema. No
afecta a las operaciones de PCI 9052. El registro LAS1BRD asociado al bus controla
las funciones de prefetching de este espacio de dirección. Si hay espacio de E/S
entonces el bit 3 es incluido en la dirección base.
Base Address. Dirección base, para el acceso local al espacio 1.
Lectura
Escritura
Valor
después
reset
Si
No
0
Si
Mem: No
E/S: Bit 1
No, Bit 2 Si
00
Si
Mem: No
E/S: Si
0
Si
Si
0h
Lectura
Escritura
Valor
después
reset
Si
No
0
Si
Mem: No
E/S: Bit 1
No, Bit 2 Si
00
Si
Mem: No
E/S: Si
0
Si
Si
0h
Información registro 20h
Bit
0
2:1
3
31:4
Descripción
Memory Space Indicator. El valor de 0 indica que el mapa de registros está en el
espacio de Memoria. El valor de 1 indica que el mapa de registros está en el espacio de
E/S. (Especificado en el registro LAS2RR)
Register Location. Valores:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
(Especificado en el registro LAS2RR.)
Si hay espacio de E/S, el bit 1 está siempre a 0 y el 2 está incluido en la dirección base.
Prefetchable (If Memory Space). El valor a 1 indica que no hay ningún efecto en las
lecturas. Refleja el valor de LAS2RR[3] y proporciona sólo el estado al sistema. No
afecta a las operaciones de PCI 9052. El registro LAS2BRD asociado al bus controla
las funciones de prefetching de este espacio de dirección. Si hay espacio de E/S
entonces el bit 3 es incluido en la dirección base.
Base Address. Dirección base, para el acceso local al espacio 2.
157
Información registro 24h
Bit
0
2:1
3
31:4
Descripción
Memory Space Indicator. El valor de 0 indica que el mapa de registros está en el
espacio de Memoria. El valor de 1 indica que el mapa de registros está en el espacio de
E/S. (Especificado en el registro LAS3RR)
Register Location. Valores:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
(Especificado en el registro LAS3RR)
Si hay espacio de E/S, el bit 1 está siempre a 0 y el 2 está incluido en la dirección base.
Prefetchable (If Memory Space). El valor a 1 indica que no hay ningún efecto en las
lecturas. Refleja el valor de LAS3RR[3] y proporciona sólo el estado al sistema. No
afecta a las operaciones de PCI 9052. El registro LAS3BRD asociado al bus controla
las funciones de prefetching de este espacio de dirección. Si hay espacio de E/S
entonces el bit 3 es incluido en la dirección base.
Base Address. Dirección base, para el acceso local al espacio 3.
Lectura
Escritura
Valor
después
reset
Si
No
0
Si
Mem: No
I/O: Bit 1
No, Bit 2 Si
00
Si
Mem: No
I/O: Si
0
Si
Si
0h
Información registro 28h
Bit
Descripción
Lectura
Escritura
Valor
después
reset
31:0
Cardbus Information Structure (CIS) Pointer for PC Cards. No Soportado.
Si
No
0h
Lectura
Escritura
Valor
después
reset
Si
Serial
EEPROM
0h
Información registro 2Ch(Subsytem Vendor ID)
Bit
15:0
Descripción
Subsystem Vendor ID. Identificador unívoco del vendedor.
Nota: PCISVID es un registro sólo para leer. Sin embargo, una configuración de
escritura para compensar 2Ch superpone el valor en el PCI e interrumpen el registro
de Línea (PCIILR), posiblemente incapacitando la capacidad de PCI.
Información registro 2Ch(Subsytem ID)
Bit
Descripción
Lectura
158
Escritura
Valor después
reset
15:0
Subsystem ID. Identificador unívoco del subsitema.
Nota: PCISID es un registro sólo para leer. Sin embargo, una configuración de
escritura para compensar 2Ch superpone el valor en el PCI e interrumpen el
registro de Línea (PCIILR), posiblemente incapacitando la capacidad de) PCI.
Serial
EEPROM
Si
0h
Información registro 30h
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Address Decode Enable. El valor de 1 indica que un dispositivo acepta accesos a las
extensiones ROM de memoria. El valor de 0 indica que un dispositivo no acepta
accesos a las extensiones ROM de memoria.
Si
Si
0
10:1
Reservado
Si
No
0h
31:11
Expansion ROM Base Address (upper 21 bits).
Si
Si
0h
Lectura
Escritura
Valor
después
reset
Si
Si
0h
Lectura
Escritura
Valor después
reset
Si
Serial
EEPROM
Información registro 3Ch(Interrupt Line)
Bit
7:0
Descripción
Interrupt Line Routing Value. Indica el sistema que interrumpe el control cuando
esta esté conectada. El PCI 9052 no usa este valor, más bien el valor es usado por otros
dispositivos y sistemas para prioridades e información. Los valores en este registro
son la arquitectura de sistema específica.
Para ordenadores personales x86-basados, los valores en este registro corresponden a
números de IRQ (0 a 15) el estándar 8259 interrumpe la configuración de regulador.
El valor 255 no es definido como "desconocido" " o ninguna conexión " al regulador.
Los valores de 15 a 255 son reservados.
Información registro 3Ch(Interrupt Pin)
Bit
7:0
Descripción
Interrupt Pin Register. Indica el pin que interrumpe el dispositivo:
0h = Ninguno
1h = INTA
2h = INTB
3h = INTC
4h = INTD
PCI 9052 sólo apoya INTA. Si PCIHTR [7] =0, los valores 2h, 3h, y 4h no tiene
ningún significado. Los demás valores (05h por FFH) son reservados por PCI r2.2.
159
1h
Registros de configuración local
PCI
(Offset
from
Local
Base Address)
To ensure software compatibility with other versions of the PCI 9052 family and to
ensure compatibility with future enhancements, write 0 to all unused bits.
31
0
Modificable
por PCI
Modificable
por Serial
EEPROM
00h
Local Address Space 0 Range
SI
SI
04h
Local Address Space 1 Range
SI
SI
08h
Local Address Space 2 Range
SI
SI
0Ch
Local Address Space 3 Range
SI
SI
10h
Expansion ROM Range
SI
SI
14h
Local Address Space 0 Local Base Address (Remap)
SI
SI
18h
Local Address Space 1 Local Base Address (Remap)
SI
SI
1Ch
Local Address Space 2 Local Base Address (Remap)
SI
SI
20h
Local Address Space 3 Local Base Address (Remap)
SI
SI
24h
Expansion ROM Local Base Address (Remap)
SI
SI
28h
Local Address Space 0 Bus Region Descriptors
SI
SI
2Ch
Local Address Space 1 Bus Region Descriptors
SI
SI
30h
Local Address Space 2 Bus Region Descriptors
SI
SI
34h
Local Address Space 3 Bus Region Descriptors
SI
SI
38h
Expansion ROM Bus Region Descriptors
SI
SI
3Ch
Chip Select 0 Base Address
SI
SI
40h
Chip Select 1 Base Address
SI
SI
44h
Chip Select 2 Base Address
SI
SI
48h
Chip Select 3 Base Address
SI
SI
4Ch
Interrupt Control/Status
SI
SI
50h
User I/O, Direct Slave Response, Serial EEPROM, and Initialization Control
SI
SI
160
Información registro (LAS0RR;00h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Memory Space Indicator. El valor 0 indica que el mapa de espacio de dirección
local 0 está en el espacio de memoria PCI. El valor 1 indica que el mapa de espacio de
dirección local 0 está en el espacio de memoria E/S.
Si
Si
0
2:1
Cuando trazado un mapa en el espacio de Memoria, la codificación es así:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
Cuando se está mapeando en E/S entonces el bit 1 es 0.
El bit 2 se une a los bits [27:3] para indicar el rango de decodificación.
Si
Si
00
Si
Si
0
Si
Si
FF0000h
Si
No
0h
3
27:4
31:28
Cuando estamos trazado un mapa en el espacio de memoria, el valor 1 indica que la
lectura es prefetchable (no afecta en las operaciones PCI 9052, pero es usado para el
estado de sistema). Cuando trazado un mapa de en el espacio de E/S, es incluido con
los bits[27:2] para indicar el rango de decodificación
Especifica la dirección de PCI usada para descifrar un acceso local al PCI en el
espacio de direcciones locales 0. Cada bit corresponde a un bit de Dirección de PCI. El
bit 27 corresponde al bit de dirección 27. Se escribirá 1 en todos los bits utilizados en
la decodificación y 0 a los demás (usado conjuntamente con PCIBAR2). El valor por
defecto es 1 MB.
Notas: Los rangos (no los del registro) debe ser potencia de 2. El valor de los rangos
de los registros es complemento a 2. El usuario debería limitar el mapeo de cada
espacio E/S con 256 bytes por PCI r2.2.
Reservado. (Los bits[31:28] de direcciones PCI están siempre incluidos en la
decodificación)
Información registro (LAS1RR;04h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Memory Space Indicator. El valor 0 indica que el mapa de espacio de dirección
local 1 está en el espacio de memoria PCI. El valor 1 indica que el mapa de espacio de
dirección local 1 está en el espacio de memoria E/S.
Si
Si
0
2:1
Cuando trazado un mapa de en el espacio de Memoria, la codificación es así:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
Cuando se está mapeando en E/S entonces el bit 1 es 0.
El bit 2 se une a los bits [27:3] para indicar el rango de decodificación.
Si
Si
00
Si
Si
0
Si
Si
FF0000h
Si
No
0h
3
27:4
31:28
Cuando estamos trazado un mapa de en el espacio de memoria, el valor 1 indica que la
lectura es prefetchable (no afecta en las operaciones PCI 9052, pero es usado para el
estado de sistema). Cuando trazado un mapa de en el espacio de E/S, es incluido con
los bits[27:2] para indicar el rango de decodificación
Especifica la dirección de PCI usada para descifrar un acceso local al PCI en el
espacio de direcciones locales 0. Cada bit corresponde a un bit de Dirección de PCI. El
bit 27 corresponde al bit de dirección 27. Se escribirá 1 en todos los bits utilizados en
la decodificación y 0 a los demás (usado conjuntamente con PCIBAR2). El valor por
defecto es 1 MB.
Notas: Los rangos (no los del registro) debe ser potencia de 2. El valor de los rangos
de los registros es complemento a 2. El usuario debería limitar el mapeo de cada
espacio E/S con 256 bytes por PCI r2.2.
Reservado. (Los bits[31:28] de direcciones PCI están siempre incluidos en la
decodificación)
161
Información registro (LAS2RR;08h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Memory Space Indicator. El valor 0 indica que el mapa de espacio de dirección
local 2 está en el espacio de memoria PCI. El valor 1 indica que el mapa de espacio de
dirección local 2 está en el espacio de memoria E/S.
Si
Si
0
2:1
Cuando trazado un mapa de en el espacio de Memoria, la codificación es así:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
Cuando se está mapeando en E/S entonces el bit 1 es 0.
El bit 2 se une a los bits [27:3] para indicar el rango de decodificación.
Si
Si
00
Si
Si
0
Si
Si
FF0000h
Si
No
0h
3
27:4
31:28
Cuando estamos trazado un mapa de en el espacio de memoria, el valor 1 indica que la
lectura es prefetchable (no afecta en las operaciones PCI 9052, pero es usado para el
estado de sistema). Cuando trazado un mapa de en el espacio de E/S, es incluido con
los bits[27:2] para indicar el rango de decodificación
Especifica la dirección de PCI usada para descifrar un acceso local al PCI en el
espacio de direcciones locales 0. Cada bit corresponde a un bit de Dirección de PCI. El
bit 27 corresponde al bit de dirección 27. Se escribirá 1 en todos los bits utilizados en
la decodificación y 0 a los demás (usado conjuntamente con PCIBAR2). El valor por
defecto es 1 MB.
Notas: Los rangos (no los del registro) debe ser potencia de 2. El valor de los rangos
de los registros es complemento a 2. El usuario debería limitar el mapeo de cada
espacio E/S con 256 bytes por PCI r2.2.
Reservado. (Los bits[31:28] de direcciones PCI están siempre incluidos en la
decodificación)
Información registro (LAS3RR;0Ch)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Memory Space Indicator. El valor 0 indica que el mapa de espacio de dirección
local 0 está en el espacio de memoria PCI. El valor 1 indica que el mapa de espacio de
dirección local 0 está en el espacio de memoria E/S.
Si
Si
0
2:1
Cuando trazado un mapa de en el espacio de Memoria, la codificación es así:
00 = Localizados en el espacio de memoria de 32 bits
01 = PCI r2.1, Localizados debajo del espacio de Memoria de 1MB
PCI r2.2, Reservado
10 = Localizados en el espacio de memoria de 64 bits
11 = Reservado
Cuando se está mapeando en E/S entonces el bit 1 es 0.
El bit 2 se une a los bits [27:3] para indicar el rango de decodificación.
Si
Si
00
Si
Si
0
Si
Si
FF0000h
Si
No
0h
3
27:4
31:28
Cuando estamos trazado un mapa de en el espacio de memoria, el valor 1 indica que la
lectura es prefetchable (no afecta en las operaciones PCI 9052, pero es usado para el
estado de sistema). Cuando trazado un mapa de en el espacio de E/S, es incluido con
los bits[27:2] para indicar el rango de decodificación
Especifica la dirección de PCI usada para descifrar un acceso local al PCI en el
espacio de direcciones locales 0. Cada bit corresponde a un bit de Dirección de PCI. El
bit 27 corresponde al bit de dirección 27. Se escribirá 1 en todos los bits utilizados en
la decodificación y 0 a los demás (usado conjuntamente con PCIBAR2). El valor por
defecto es 1 MB.
Notas: Los rangos (no los del registro) debe ser potencia de 2. El valor de los rangos
de los registros es complemento a 2. El usuario debería limitar el mapeo de cada
espacio E/S con 256 bytes por PCI r2.2.
Reservado. (Los bits[31:28] de direcciones PCI están siempre incluidos en la
decodificación)
162
Información registro (EROMRR; 10h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Address Decode Enable. Sólo puede ser accedido por el serial EEPROM. Para
deshabilitarlo, se debe poner el bit de permiso de decodificación de direcciones de la
memoria ROM de expansión a 0 (PCIERBAR [0] =0).
No
Serial
EEPROM
0
10:1
Reservado.
Si
No
0h
27:11
Indica los bits de la dirección PCI utilizados para decodificar la ROM de expansión de
PCI al bus local. Cada uno de los bits corresponde a un bit de la dirección. El valor 1
indica que esos bits deben ser incluidos en la decodificación. El valor 0 indica a los
demás (se usan conjuntamente con los PCIERBAR). El tamaño por defecto es 64 KB y
el mínimo es de la gama 2 KB, y el tamaño máximo en PCI r2.2 es 16 MB.
Notes: El rango(no el del registr5o) debe ser potencia de 2. El valor del rango del
registro es complemento a 2. EROMRR normalmente debe ser programado por el
serial EEPROM a un valor de 0h, a no ser que la memoria de lectura extendida esté
presente sobre el bus local. Si el valor no es 0h (el valor por defecto es 64 KB), la
BIOS del sistema puede intentar asignar la memoria de lectura extendida para luego
poder ser accedida gracias a la dirección base existente en EROMBA (el valor por
defecto es 1 MB) para determinar si la imagen de memoria de lectura expandida es
válida. Si la imagen no es válida, la BIOS del sistema traza un mapa de la memoria
sólo de lectura extendida que dirigen el espacio al que asignó al principio, escribiendo
0h a PCIERBAR [31:0].
Si
Si
1111111111
1100000
Si
No
0h
31:28
Reservado. (Los bits[31:28] de direcciones PCI están siempre incluidos en la
decodificación)
Información registro (LAS0BA;14h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Space 0 Enable. El valor 1 permite decodificar la dirección PCI para acceso directo
para el espacio de direcciones locales 0.
Note: PCIBAR2 puede ser activado o desactivado gracias a este bit
Si
Si
0
1
Reservado.
Si
Si
0
Si
Si
00
Si
Si
0h
Si
No
0h
3:2
27:4
31:28
Si el espacio de direcciones locales 0 está mapeado en espacio de memoria este bit no
se utiliza. Si está mapeado es espacio de E/S, se utilizan estos bits junto con los
bits[27:4] para remapearlos.
Remap PCI Address to Local Address Space 0 into Local Address Space. Estos
bits se utilizan para remapear direcciones PCI en direcciones
Nota: El valor del remapeo de direcciones debe ser múltiplo del rango (no del registro
del rango).
Reservado. (Los bits[31:28] de direcciones locales no existen en PCI 9052.)
163
Información registro (LAS1BA;18h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Space 1 Enable. El valor 1 permite decodificar la dirección PCI para acceso directo
para el espacio de direcciones locales 1.
Note: PCIBAR2 puede ser activado o desactivado gracias a este bit
Si
Si
0
1
Reservado.
Si
Si
0
Si
Si
00
Si
Si
0h
Si
No
0h
3:2
27:4
31:28
Si el espacio de direcciones locales 1 está mapeado en espacio de memoria este bit no
se utiliza. Si está mapeado es espacio de E/S, se utilizan estos bits junto con los
bits[27:4] para remapearlos.
Remap PCI Address to Local Address Space 1 into Local Address Space. Estos
bits se utilizan para remapear direcciones PCI en direcciones
Nota: El valor del remapeo de direcciones debe ser múltiplo del rango (no del registro
del rango).
Reservado. (Los bits[31:28] de direcciones locales no existen en PCI 9052.)
Información registro (LAS2BA;1Ch)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Space 2 Enable. El valor 1 permite decodificar la dirección PCI para acceso directo
para el espacio de direcciones locales 2.
Note: PCIBAR2 puede ser activado o desactivado gracias a este bit
Si
Si
0
1
Reservado.
Si
Si
0
Si
Si
00
Si
Si
0h
Si
No
0h
3:2
27:4
31:28
Si el espacio de direcciones locales 2 está mapeado en espacio de memoria este bit no
se utiliza. Si está mapeado es espacio de E/S, se utilizan estos bits junto con los
bits[27:4] para remapearlos.
Remap PCI Address to Local Address Space 2 into Local Address Space. Estos
bits se utilizan para remapear direcciones PCI en direcciones
Nota: El valor del remapeo de direcciones debe ser múltiplo del rango (no del registro
del rango).
Reservado. (Los bits[31:28] de direcciones locales no existen en PCI 9052.)
Información registro (LAS3BA;20h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Space 3 Enable. El valor 1 permite decodificar la dirección PCI para acceso directo
para el espacio de direcciones locales 3.
Note: PCIBAR2 puede ser activado o desactivado gracias a este bit
Si
Si
0
1
Reservado.
Si
Si
0
Si
Si
00
Si
Si
0h
Si
No
0h
3:2
27:4
31:28
Si el espacio de direcciones locales 3 está mapeado en espacio de memoria este bit no
se utiliza. Si está mapeado es espacio de E/S, se utilizan estos bits junto con los
bits[27:4] para remapearlos.
Remap PCI Address to Local Address Space 3 into Local Address Space. Estos
bits se utilizan para remapear direcciones PCI en direcciones
Nota: El valor del remapeo de direcciones debe ser múltiplo del rango (no del registro
del rango).
Reservado. (Los bits[31:28] de direcciones locales no existen en PCI 9052.)
164
Información registro (EROMBA; 24h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
10:0
Reservado.
Si
No
0h
27:11
Remap PCI Expansion ROM Space into Local Address Space. Los bits en este
nuevo mapa de registro sustituyen los bits de dirección PCI utilizados en la
decodificación de direcciones locales. El valor por defecto es 1 MB.
Nota: Este valor debe ser un múltiplo del rango (no del rango del registro).
Si
Si
000000010
00000000
Si
No
0h
31:28
Reservado. (Los bits[31:28] de direcciones locales no existen en PCI 9052.)
165
Información registro (LAS0BRD; 28h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Burst Enable. El valor 1 indica que la ráfaga está lista. El valor 0 indica que la opción
de ráfaga está desactivado. La ráfaga ocurre si el contador de prefetch es distinto de 00.
Si
Si
0
1
LRDYi Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado.
Si
Si
0
2
BTERM Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado. La longitud de la ráfaga se limita a 4 palabras Lword.
Si
Si
0
4:3
Prefetch Count. Es el número de Lwords a las que se puede hacer prefetch durante un
ciclo de lectura de memoria.
Se usa sólo si el valor de 5 está activado. Valores:
00 =No hay prefetch. Sólo se leen las líneas especificadas.
01 = Prefetch 4 Lwords if bit 5 está activado.
10 = Prefetch 8 Lwords if bit 5 está activado.
11 = Prefetch 16 Lwords if bit 5 está activado.
Si
Si
00
Si
Si
0
5
Prefetch Count Enable. El valor 1permite hacer prefetch del número de palabras
Lword especificadas en el contador. El valor 0 ignora el contador y hace prefetch hasta
el final del bus PCI. Para deshabilitar el prefetch LAS0BRD[5:3]=100b.
10:6
NRAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la lectura del primer dato. (0-31)
Si
Si
0h
12:11
NRDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos. (0-3)
Si
Si
00
14:13
NXDA Wait States. Es el número de estados de espera entre un ciclo de lectura o
escritura de datos y un ciclo de direccionamiento (0-3).
(Estados de espera entre dos peticiones consecutivas del bus. Estos estados de espera
sólo son insertados después del último ciclo de transferencia de datos en un acceso
directo por parte del esclavo)
Si
Si
00
19:15
NWAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la escritura del primer dato. (0-31). El dato a escribir es válido durante los ciclos de
espera NWAD.
Si
Si
0h
21:20
NWDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos (0-3).
Si
Si
00
Si
Si
10
Si
Si
0
Si
Si
0
Si
Si
00
Si
Si
00
Si
Si
00
23:22
24
25
27:26
29:28
31:30
Bus Width. Valores:
00 = 8-bit
01 = 16-bit
10 = 32-bit
11 = Reservado
Byte Ordering. El valor 1 significa que se utilizará Big Endian. El valor 0 indica que se
utilizará Little Endian.
Big Endian Byte Lane Mode. El valor 1 significa que se utilizará Big Endian de la
siguiente manera, los bits [31:16] serán utilizados para el bus en caso de utilizar 16-bits,
los bits [31:24] se utilizarán para el bus en caso de utilizar 8-bits.
El valor 0 significa que se utilizará Big Endian de la siguiente manera, los bits [15:0]
serán utilizados para el bus en caso de utilizar 16-bits, los bits [7:0] se utilizarán para el
bus en caso de utilizar 8-bits.
Read Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
RD es confirmado (0-3). El valor debe ser menor que NRAD para que RD pueda ser
confirmado.
Write Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
WR es confirmado (0-3). El valor debe ser menor que NWAD para que WR pueda ser
confirmado.
Write Cycle Hold. El número de ciclos de reloj desde que WR es confirmado hasta el
final del ciclo(0-3). Los datos(LAD[31:0]) se deben mantener válidos, y BLAST
confirmado durante estos ciclos de espera.
166
Información registro (LAS1BRD; 2Ch)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Burst Enable. El valor 1 indica que la ráfaga está lista. El valor 0 indica que la opción
de ráfaga está desactivado. La ráfaga ocurre si el contador de prefetch es distinto de 00.
Si
Si
0
1
LRDYi Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado.
Si
Si
0
2
BTERM Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado. La longitud de la ráfaga se limita a 4 palabras Lword.
Si
Si
0
4:3
Prefetch Count. Es el número de Lwords a las que se puede hacer prefetch durante un
ciclo de lectura de memoria.
Se usa sólo si el valor de 5 está activado. Valores:
00 =No hay prefetch. Sólo se leen las líneas especificadas.
01 = Prefetch 4 Lwords if bit 5 está activado.
10 = Prefetch 8 Lwords if bit 5 está activado.
11 = Prefetch 16 Lwords if bit 5 está activado.
Si
Si
00
Si
Si
0
5
Prefetch Count Enable. El valor 1permite hacer prefetch del número de palabras
Lword especificadas en el contador. El valor 0 ignora el contador y hace prefetch hasta
el final del bus PCI. Para deshabilitar el prefetch LAS1BRD[5:3]=100b.
10:6
NRAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la lectura del primer dato. (0-31)
Si
Si
0h
12:11
NRDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos. (0-3)
Si
Si
00
14:13
NXDA Wait States. Es el número de estados de espera entre un ciclo de lectura o
escritura de datos y un ciclo de direccionamiento (0-3).
(Estados de espera entre dos peticiones consecutivas del bus. Estos estados de espera
sólo son insertados después del último ciclo de transferencia de datos en un acceso
directo por parte del esclavo)
Si
Si
00
19:15
NWAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la escritura del primer dato. (0-31). El dato a escribir es válido durante los ciclos de
espera NWAD.
Si
Si
0h
21:20
NWDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos (0-3).
Si
Si
00
Si
Si
10
Si
Si
0
Si
Si
0
Si
Si
00
Si
Si
00
Si
Si
00
23:22
24
25
27:26
29:28
31:30
Bus Width. Valores:
00 = 8-bit
01 = 16-bit
10 = 32-bit
11 = Reservado
Byte Ordering. El valor 1 significa que se utilizará Big Endian. El valor 0 indica que se
utilizará Little Endian.
Big Endian Byte Lane Mode. El valor 1 significa que se utilizará Big Endian de la
siguiente manera, los bits [31:16] serán utilizados para el bus en caso de utilizar 16-bits,
los bits [31:24] se utilizarán para el bus en caso de utilizar 8-bits.
El valor 0 significa que se utilizará Big Endian de la siguiente manera, los bits [15:0]
serán utilizados para el bus en caso de utilizar 16-bits, los bits [7:0] se utilizarán para el
bus en caso de utilizar 8-bits.
Read Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
RD es confirmado (0-3). El valor debe ser menor que NRAD para que RD pueda ser
confirmado.
Write Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
WR es confirmado (0-3). El valor debe ser menor que NWAD para que WR pueda ser
confirmado.
Write Cycle Hold. El número de ciclos de reloj desde que WR es confirmado hasta el
final del ciclo(0-3). Los datos(LAD[31:0]) se deben mantener válidos, y BLAST
confirmado durante estos ciclos de espera.
167
Información registro (LAS2BRD; 30h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Burst Enable. El valor 1 indica que la ráfaga está lista. El valor 0 indica que la opción
de ráfaga está desactivado. La ráfaga ocurre si el contador de prefetch es distinto de 00.
Si
Si
0
1
LRDYi Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado.
Si
Si
0
2
BTERM Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado. La longitud de la ráfaga se limita a 4 palabras Lword.
Si
Si
0
4:3
Prefetch Count. Es el número de Lwords a las que se puede hacer prefetch durante un
ciclo de lectura de memoria.
Se usa sólo si el valor de 5 está activado. Valores:
00 =No hay prefetch. Sólo se leen las líneas especificadas.
01 = Prefetch 4 Lwords if bit 5 está activado.
10 = Prefetch 8 Lwords if bit 5 está activado.
11 = Prefetch 16 Lwords if bit 5 está activado.
Si
Si
00
Si
Si
0
5
Prefetch Count Enable. El valor 1permite hacer prefetch del número de palabras
Lword especificadas en el contador. El valor 0 ignora el contador y hace prefetch hasta
el final del bus PCI. Para deshabilitar el prefetch LAS2BRD[5:3]=100b.
10:6
NRAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la lectura del primer dato. (0-31)
Si
Si
0h
12:11
NRDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos. (0-3)
Si
Si
00
14:13
NXDA Wait States. Es el número de estados de espera entre un ciclo de lectura o
escritura de datos y un ciclo de direccionamiento (0-3).
(Estados de espera entre dos peticiones consecutivas del bus. Estos estados de espera
sólo son insertados después del último ciclo de transferencia de datos en un acceso
directo por parte del esclavo)
Si
Si
00
19:15
NWAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la escritura del primer dato. (0-31). El dato a escribir es válido durante los ciclos de
espera NWAD.
Si
Si
0h
21:20
NWDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos (0-3).
Si
Si
00
Si
Si
10
Si
Si
0
Si
Si
0
Si
Si
00
Si
Si
00
Si
Si
00
23:22
24
25
27:26
29:28
31:30
Bus Width. Valores:
00 = 8-bit
01 = 16-bit
10 = 32-bit
11 = Reservado
Byte Ordering. El valor 1 significa que se utilizará Big Endian. El valor 0 indica que se
utilizará Little Endian.
Big Endian Byte Lane Mode. El valor 1 significa que se utilizará Big Endian de la
siguiente manera, los bits [31:16] serán utilizados para el bus en caso de utilizar 16-bits,
los bits [31:24] se utilizarán para el bus en caso de utilizar 8-bits.
El valor 0 significa que se utilizará Big Endian de la siguiente manera, los bits [15:0]
serán utilizados para el bus en caso de utilizar 16-bits, los bits [7:0] se utilizarán para el
bus en caso de utilizar 8-bits.
Read Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
RD es confirmado (0-3). El valor debe ser menor que NRAD para que RD pueda ser
confirmado.
Write Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
WR es confirmado (0-3). El valor debe ser menor que NWAD para que WR pueda ser
confirmado.
Write Cycle Hold. El número de ciclos de reloj desde que WR es confirmado hasta el
final del ciclo(0-3). Los datos(LAD[31:0]) se deben mantener válidos, y BLAST
confirmado durante estos ciclos de espera.
168
Información registro (LAS3BRD; 34h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Burst Enable. El valor 1 indica que la ráfaga está lista. El valor 0 indica que la opción
de ráfaga está desactivado. La ráfaga ocurre si el contador de prefetch es distinto de 00.
Si
Si
0
1
LRDYi Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado.
Si
Si
0
2
BTERM Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado. La longitud de la ráfaga se limita a 4 palabras Lword.
Si
Si
0
4:3
Prefetch Count. Es el número de Lwords a las que se puede hacer prefetch durante un
ciclo de lectura de memoria.
Se usa sólo si el valor de 5 está activado. Valores:
00 =No hay prefetch. Sólo se leen las líneas especificadas.
01 = Prefetch 4 Lwords if bit 5 está activado.
10 = Prefetch 8 Lwords if bit 5 está activado.
11 = Prefetch 16 Lwords if bit 5 está activado.
Si
Si
00
Si
Si
0
5
Prefetch Count Enable. El valor 1permite hacer prefetch del número de palabras
Lword especificadas en el contador. El valor 0 ignora el contador y hace prefetch hasta
el final del bus PCI. Para deshabilitar el prefetch LAS3BRD[5:3]=100b.
10:6
NRAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la lectura del primer dato. (0-31)
Si
Si
0h
12:11
NRDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos. (0-3)
Si
Si
00
14:13
NXDA Wait States. Es el número de estados de espera entre un ciclo de lectura o
escritura de datos y un ciclo de direccionamiento (0-3).
(Estados de espera entre dos peticiones consecutivas del bus. Estos estados de espera
sólo son insertados después del último ciclo de transferencia de datos en un acceso
directo por parte del esclavo)
Si
Si
00
19:15
NWAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la escritura del primer dato. (0-31). El dato a escribir es válido durante los ciclos de
espera NWAD.
Si
Si
0h
21:20
NWDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos (0-3).
Si
Si
00
Si
Si
10
Si
Si
0
Si
Si
0
Si
Si
00
Si
Si
00
Si
Si
00
23:22
24
25
27:26
29:28
31:30
Bus Width. Valores:
00 = 8-bit
01 = 16-bit
10 = 32-bit
11 = Reservado
Byte Ordering. El valor 1 significa que se utilizará Big Endian. El valor 0 indica que se
utilizará Little Endian.
Big Endian Byte Lane Mode. El valor 1 significa que se utilizará Big Endian de la
siguiente manera, los bits [31:16] serán utilizados para el bus en caso de utilizar 16-bits,
los bits [31:24] se utilizarán para el bus en caso de utilizar 8-bits.
El valor 0 significa que se utilizará Big Endian de la siguiente manera, los bits [15:0]
serán utilizados para el bus en caso de utilizar 16-bits, los bits [7:0] se utilizarán para el
bus en caso de utilizar 8-bits.
Read Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
RD es confirmado (0-3). El valor debe ser menor que NRAD para que RD pueda ser
confirmado.
Write Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
WR es confirmado (0-3). El valor debe ser menor que NWAD para que WR pueda ser
confirmado.
Write Cycle Hold. El número de ciclos de reloj desde que WR es confirmado hasta el
final del ciclo(0-3). Los datos(LAD[31:0]) se deben mantener válidos, y BLAST
confirmado durante estos ciclos de espera.
169
Información registro (EROMBRD; 38h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Burst Enable. El valor 1 indica que la ráfaga está lista. El valor 0 indica que la opción
de ráfaga está desactivado. La ráfaga ocurre si el contador de prefetch es distinto de 00.
Si
Si
0
1
LRDYi Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado.
Si
Si
0
2
BTERM Input Enable. El valor 1 significa que está activado. El valor 0 indica que está
desactivado. La longitud de la ráfaga se limita a 4 palabras Lword.
Si
Si
0
4:3
Prefetch Count. Es el número de Lwords a las que se puede hacer prefetch durante un
ciclo de lectura de memoria.
Se usa sólo si el valor de 5 está activado. Valores:
00 =No hay prefetch. Sólo se leen las líneas especificadas.
01 = Prefetch 4 Lwords if bit 5 está activado.
10 = Prefetch 8 Lwords if bit 5 está activado.
11 = Prefetch 16 Lwords if bit 5 está activado.
Si
Si
00
Si
Si
0
5
Prefetch Count Enable. El valor 1permite hacer prefetch del número de palabras
Lword especificadas en el contador. El valor 0 ignora el contador y hace prefetch hasta
el final del bus PCI. Para deshabilitar el prefetch EROMBRD[5:3]=100b.
10:6
NRAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la lectura del primer dato. (0-31)
Si
Si
0h
12:11
NRDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos. (0-3)
Si
Si
00
14:13
NXDA Wait States. Es el número de estados de espera entre un ciclo de lectura o
escritura de datos y un ciclo de direccionamiento (0-3).
(Estados de espera entre dos peticiones consecutivas del bus. Estos estados de espera
sólo son insertados después del último ciclo de transferencia de datos en un acceso
directo por parte del esclavo)
Si
Si
00
19:15
NWAD Wait States. Es el número de estados de espera entre la lectura de la dirección y
la escritura del primer dato. (0-31). El dato a escribir es válido durante los ciclos de
espera NWAD.
Si
Si
0h
21:20
NWDD Wait States. Es el número de estados de espera entre dos ciclos de lectura de
datos consecutivos (0-3).
Si
Si
00
Si
Si
10
Si
Si
0
Si
Si
0
Si
Si
00
Si
Si
00
Si
Si
00
23:22
24
25
27:26
29:28
31:30
Bus Width. Valores:
00 = 8-bit
01 = 16-bit
10 = 32-bit
11 = Reservado
Byte Ordering. El valor 1 significa que se utilizará Big Endian. El valor 0 indica que se
utilizará Little Endian.
Big Endian Byte Lane Mode. El valor 1 significa que se utilizará Big Endian de la
siguiente manera, los bits [31:16] serán utilizados para el bus en caso de utilizar 16-bits,
los bits [31:24] se utilizarán para el bus en caso de utilizar 8-bits.
El valor 0 significa que se utilizará Big Endian de la siguiente manera, los bits [15:0]
serán utilizados para el bus en caso de utilizar 16-bits, los bits [7:0] se utilizarán para el
bus en caso de utilizar 8-bits.
Read Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
RD es confirmado (0-3). El valor debe ser menor que NRAD para que RD pueda ser
confirmado.
Write Strobe Delay. El número de ciclos de reloj desde el principio del ciclo hasta que
WR es confirmado (0-3). El valor debe ser menor que NWAD para que WR pueda ser
confirmado.
Write Cycle Hold. El número de ciclos de reloj desde que WR es confirmado hasta el
170
final del ciclo(0-3). Los datos(LAD[31:0]) se deben mantener válidos, y BLAST
confirmado durante estos ciclos de espera.
Información registro (CS0BASE; 3Ch)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Chip Select 0 Enable. El valor 1 significa que está habilitado. El valor 0 significa que
está deshabilitado.
Si
Si
0
Si
Si
0h
Si
No
0h
27:1
31:28
Local Base Address of Chip Select 0. Escribir ceros en los bits menos significativos
define el rango del Chip Select 0. Empezando desde el bit 1 y hasta el 27 se define el
tamaño. Los bits más significativos excluyendo el bit donde se encuentra el primer 1
definen la dirección base.
Reservado.
Información registro (CS1BASE; 40h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Chip Select 1 Enable. El valor 1 significa que está habilitado. El valor 0 significa que
está deshabilitado.
Si
Si
0
Si
Si
0h
Si
No
0h
27:1
31:28
Local Base Address of Chip Select 1. Escribir ceros en los bits menos significativos
define el rango del Chip Select 1. Empezando desde el bit 1 y hasta el 27 se define el
tamaño. Los bits más significativos excluyendo el bit donde se encuentra el primer 1
definen la dirección base.
Reservado.
Información registro (CS2BASE; 44h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Chip Select 2 Enable. El valor 1 significa que está habilitado. El valor 0 significa que
está deshabilitado.
Si
Si
0
Si
Si
0h
Si
No
0h
27:1
31:28
Local Base Address of Chip Select 2. Escribir ceros en los bits menos significativos
define el rango del Chip Select 2. Empezando desde el bit 1 y hasta el 27 se define el
tamaño. Los bits más significativos excluyendo el bit donde se encuentra el primer 1
definen la dirección base.
Reservado.
171
Información registro (CS3BASE; 48h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
Chip Select 3 Enable. El valor 1 significa que está habilitado. El valor 0 significa que
está deshabilitado.
Si
Si
0
Si
Si
0h
Si
No
0h
27:1
31:28
Local Base Address of Chip Select 3. Escribir ceros en los bits menos significativos
define el rango del Chip Select 3. Empezando desde el bit 1 y hasta el 27 se define el
tamaño. Los bits más significativos excluyendo el bit donde se encuentra el primer 1
definen la dirección base.
Reservado.
Información registro (INTCSR; 4Ch)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
LINTi1 Enable. El valor 1 indica que LINTi1 está habilitado. El valor cero indica que
está deshabilitado.
Si
Si
0
1
LINTi1 Polarity. El valor 1 indica que el valor de LINTi1 es 1. El valor 0 indica que
el valor de LINTi1 es 0.
Si
Si
0
2
LINTi1 Status. El valor 1 indica que LINTi1 está activado. El valor 0 indica que
LINTi1 está desactivado.
Si
No
0
3
LINTi2 Enable. El valor 1 indica que LINTi2 está habilitado. El valor cero indica que
está deshabilitado.
Si
Si
0
4
LINTi2 Polarity. El valor 1 indica que el valor de LINTi2 es 1. El valor 0 indica que
el valor de LINTi2 es 0.
Si
Si
0
5
LINTi2 Status. El valor 1 indica que LINTi2 está activado. El valor 0 indica que
LINTi2 está desactivado.
Si
No
0
6
PCI Interrupt Enable. El valor 1 permite generar interrupciones PCI.
Si
Si
0
7
Software Interrupt. El valor 1 genera interrupciones PCI (INTA confirmado) si PCI
Interrupt Enable está activado (INTCSR[6]=1).
Si
Si
0
Si
Si
0
Si
Si
0
8
9
LINTi1 Select Enable. El valor 1 indica que se pueden hacer interrupciones Edge
Triggerable. El valor 1 indica que se pueden hacer interrupciones Level Triggerable.
Note: Estas operaciones sólo se pueden hacer en modo de alta polaridad
(INTCSR[1]=1).
LINTi2 Select Enable. . El valor 1 indica que se pueden hacer interrupciones Edge
Triggerable. El valor 1 indica que se pueden hacer interrupciones Level Triggerable.
Note: Estas operaciones sólo se pueden hacer en modo de alta polaridad
(INTCSR[4]=1).
10
Local Edge Triggerable Interrupt Clear. Poner este bit a uno resetea LINTi1.
Si
Si
0
11
Local Edge Triggerable Interrupt Clear. Poner este bit a uno resetea LINTi2.
Si
Si
0
12
ISA Interface Mode Enable. Poner este bit a 1 permite el uso del interfaz ISA. Poner
este bit a 0 deshabilita el uso del interfaz ISA.
Si
Serial
EEPROM
0
31:13
Reservado.
Si
No
0
172
Información registro (CNTRL; 50h)
Bit
Descripción
Lectura
Escritura
Valor
después
reset
0
User I/O 0 or WAITO# Pin Select. Selecciona entre las funciones del pin de USER0
y WAITTO. El valor 1 selecciona WAITTO y el valor 0 selecciona USER0.
Si
Si
0
1
User I/O 0 Direction. El valor 0 significa que es una entrada. El valor 1 significa que
es una salida. El pin es siempre de salida si WAITTO está seleccionada.
Si
Si
0
Si
Si
0
2
3
User I/O 0 Data. Si está programada como salida escribir 1 provoca que el pin se
active. Si está programada como una entrada el valor que tiene es el estado del pin
correspondiente.
User I/O 1 or LLOCKo# Pin Select. Selecciona entre las funciones del pin de
USER1 y LLOCK0. El valor 1 selecciona LLOCK0 y el valor 0 selecciona USER1.
Si
Si
0
4
User I/O 1 Direction. El valor 0 significa que es una entrada. El valor 1 significa que
es una salida. El pin es siempre de salida si LLOCK0 está seleccionada.
Si
Si
0
5
User I/O 1 Data. Si está programada como salida escribir 1 provoca que el pin se
active. Si está programada como una entrada el valor que tiene es el estado del pin
correspondiente.
Si
Si
0
6
User I/O 2 or CS2# Pin Select. Selecciona entre las funciones del pin de USER2 y
CS2. El valor 1 selecciona CS2 y el valor 0 selecciona USER2.
Si
Si
0
7
User I/O 2 Direction. El valor 0 significa que es una entrada. El valor 1 significa que
es una salida. El pin es siempre de salida si CS2 está seleccionada.
Si
Si
0
8
User I/O 2 Data. Si está programada como salida escribir 1 provoca que el pin se
active. Si está programada como una entrada el valor que tiene es el estado del pin
correspondiente.
Si
Si
0
9
User I/O 3 or CS3# Pin Select. Selecciona entre las funciones del pin de USER3 y
CS3. El valor 1 selecciona CS3 y el valor 0 selecciona USER3.
Si
Si
0
10
User I/O 3 Direction. El valor 0 significa que es una entrada. El valor 1 significa que
es una salida. El pin es siempre de salida si CS3 está seleccionada.
Si
Si
0
Si
Si
0
Si
Si
00
Si
Si
0
Si
Si
0
Si
Si
0
11
13:12
14
15
16
User I/O 3 Data. Si está programada como salida escribir 1 provoca que el pin se
active. Si está programada como una entrada el valor que tiene es el estado del pin
correspondiente.
PCI Configuration Base Address Register (PCIBAR) Enables. Valores:
00, 11 = PCIBAR0 (Memoria) and PCIBAR1 (E/S) habilitados
01 = Sólo PCIBAR0 (Memoria)
10 = Sólo PCIBAR1 (E/S)
Nota: PCIBAR0 y PCIBAR1 deben estar habilitados para PCs.
PCI r2.1 Features Enable. Cuando está a 1 entonces PCI9052 hace todas las
transacciones PCI en modo PCI r2.1. Esto permite la lectura retardada 32K para el
reintento en las interrupciones del reloj, ajustar las latencias para 16 bits y 8 bits y
además la opción de escoger el modo de operar de lectura pero no escritura.
Cuando está a 0 provoca que TRDY tenga que ser confirmado para que el dato que se
vaya a leer esté disponible. Si el dato a leer no está disponible antes de que el contador
“PCI acceso directo esclavo de retrasos” expire (CNTRL[22:19]) entonces se
reintentará la lectura.
PCI Read with Write Flush Mode. Cuando CNTRL [14] =1, el valor 1 elimina un
posible ciclo de lectura pendiente si se detecta un ciclo de escritura. Cuando CNTRL
[14] =0 no afectan los retrasos en las lecturas.
PCI Read No Flush Mode. El valor 1 no limpia la FIFO de lectura si el ciclo de
lectura PCI es completado (acceso esclavo en modo lectura adelantada). El valor 0
limpia la FIFO de lectura si el ciclo de lectura PCI es completado (acceso esclavo en
modo lectura adelantada).
El modo de lectura adelantada implica que debe estar activado en los registros
LASxBRD el prefetch para el mapeo de los espacios de memoria que utilizan la
lectura adelantada. PCI9052 limpia la pila FIFO de lectura por cada acceso de E/S.
173
17
PCI Read No Write Mode (PCI Retries for Writes). Cuando CNTRL [14] =1, el
valor 1 obliga al dispositivo a hacer un reintento si intentamos una escritura cuando
hay una lectura pendiente. El valor 0 no obliga al dispositivo a hacer nada.
Si
Si
0
18
PCI Write Release Bus Mode Enable. El valor 1 hace que el dispositivo se
desconecte si la FIFO de escritura se llama. El valor 0 confirma TRDY hasta que haya
espacio disponible en la FIFO de escritura (modo mantenimiento PCI escritura).
Si
Si
0
22:19
PCI Direct Slave Retry Delay Clocks. Es el número de ciclos de reloj PCI
(multiplicados por 8) desde el principio hasta el acceso directo en modo esclavo
después de un reintento PCI. Este valor para lecturas sólo si CNTRL[14]=0. Este valor
es válido para escrituras sólo si CNTRL[18]=0.
Si
Si
4h
Si
Si
0
Si
Si
0
23
24
Direct Slave LOCK# Enable. El valor 1 permite que se bloquee una secuencia de
acceso en modo esclavo. El valor 0 no permite que se bloquee una secuencia de
acceso en modo esclavo.
Serial EEPROM Clock for PCI Bus Reads or Writes to Serial EEPROM. El
cambio de este bit genera un ciclo de reloj del serial EEPROM.
25
Serial EEPROM Chip Select. Para que el bus PCI lea o escriba en el serial
EEPROM tener este bit a 1 para tener acceso al Chip Select del EEPROM.
Si
Si
0
26
Write Bit to Serial EEPROM. Para las escrituras este bit es el dato a escribir en el
serial EEPROM.
Si
Si
0
27
Read Serial EEPROM Data Bit. Para las lecturas este bit es el dato enviado por el
serial EEPROM.
Si
No
—
28
Serial EEPROM Present. El valor 1 indica un espacio en blanco o que el serial
EEPROM está presente.
Si
No
0
29
Reload Configuration Registers. Cuando está a 0, escribir 1 produce que PCI9052
recargue la configuración local desde el serial EEPROM.
Si
Si
0
Si
Si
0
Si
No
0
30
31
PCI Adapter Software Reset. El valor 1 resetea el PCI 9052 y Value of 1 resets el
PCI 9052 y envía un reset al bus. PCI 9052 mantiene el reseteo hasta que el PCI
cambie este bit de valor. El contenido de PCI y de los registros de configuración no es
reseteados, tampoco es reseteado el interfaz PCI.
Nota: Si está permitido el modo de lectura adelanta en acceso esclavo
(CNTRL[16]=1), quitar ésta provocará un reset de software o después de un reset de
software se realice un acceso esclavo de lectura a cualquier dirección del bus,
excepto a la siguiente secuencia de palabra referenciada por el último acceso de
lectura, una limpia la FIFO de lectura.
Mask Revision.
174
Pines
Potencia, Toma de tierra y pines no utilizados
Símbolo
Nombre señal
Pines
Tipo
Número Pin
Función
Pines no conectados tanto en modo multiplexado como en
modo no multipliexado. En el interfaz de modo no
multiplexado ISA CHRDY está asignado al pin 45, y NOWS al
67.
Test pin. Se activa para testar o para entrar en estado de baja
potencia. Mantener desactivado para el modo de trabajo
normal. Cuando TEST está activado todas las salidas excepto
RD se colocan en estado de alta impedancia. RD proporciona
una salida NANDTREE cuando TEST está activado.
NC
Spare
2
N/A
45, 67
TEST
Test
1
I
99
VDD
Power
10
I
1, 10, 27, 41, 50,
66, 81, 103, 121,
146
Dan la potencia necesaria (5V).
VSS
Ground
10
I
65, 80, 104,
Pines de toma de tierra.
23
Total
Pines del serial EEPROM
Símbolo
Nombre señal
Pines
Tipo
Número Pin
Función
EECS
Serial EEPROM
Chip Select
1
O TP 8
mA
142
Chip select del serial EEPROM
EEDI
EEDO
EEPROM
EEPROM
1
1
TP
I
145
143
Escribir datos al serial EEPROM.
Leer datos desde el serial EEPROM.
EESK
Serial
Clock
1
O TP 8
mA
144
Reloj del Serial EEPROM
Total
Data
4
175
Pines del interfaz PCI
Pines
Símbolo
Nombre señal
AD[31:0]
Dirección
datos
C/BE[3:0]
Tipo
Número pines
32
E/S
PCI
Comados bus
4
I PCI
158, 12, 22, 33
CLK
Reloj
1
I
149
DEVSEL
Selección
dispositivo
1
O
STS
PCI
16
FRAME
Ciclo Frame
1
I PCI
13
IDSEL
Selección
inicialización
dispositivo
1
I PCI
159
INTA
Interrupción A
1
IRDY
Iniciador Listo
1
O
OD
PCI
I PCI
LOCK
Bloqueo
1
I PCI
PAR
Paridad
1
I/O
PCI
PERR
Error paridad
1
O
STS
PCI
19
RST
Reset
1
I PCI
148
SERR
Error Sistema
1
O OD PCI
20
STOP
Parada
1
TRDY
Objetivo listo
1
Total
y
TS
150-157, 2-8, 11, 23-25, 28-32, 34-39, 42-43
44
14
18
TS
O
STS
PCI
STS
21
17
15
49
176
Pines del bus local
Pines
Símbolo
BCLKO
Nombre señal
Reloj del Buffer
1
Tipo
O TP 24
mA
O TS 8
mA
Número pines
63
CS[1:0]
Chip Select
2
131, 130
LCLK
Reloj bus local
1
I
135
LHOLD
Petición
1
I
134
LHOLDA
Aceptación
1
O TP 8
mA
133
LINTi1
Interrupción
local 1 In
1
I
137
LINTi2
Interrupción
local 2 In
1
I
136
LRESET
Reset local
1
O TP 8 mA
132
MODE
Modo Bus
1
I
68
USER0 WAITO
User E/S
WAIT Out
0
1
I/O TS 8 mA
138
USER1 LLOCKo
User E/S
LLOCK Out
1
1
I/O TS 8 mA
139
USER2 CS2
User E/S 2 Chip
Select
2 Out
1
I/O TS 8 mA
140
USER3 CS3
User E/S 3 Chip
Select 3 Out
1
I/O TS 8 mA
141
14
Total
Pines independientes del bus local de transferencias de datos
Pines
Símbolo
Nombre señal
Tipo
Número pines
ADS
Dirección Strobe
1
O TS 12 mA
123
ALE
Permiso
lanzamiento
dirección
1
O TS 8 mA
64
BLAST
Última ráfaga
1
O TS 8 mA
124
LRDYi
Lectura local In
1
128
LW/R
Escritura/Lectura
1
I
O TS 8 mA
RD
WR#
Lectura Strobe
Escritura Strobe
1
1
O TS 12 mA
O TS 12 mA
126
125
Total
7
177
127
Pines dependientes del bus local de transferencias de datos
Pines
Símbolo
Nombre señal
Tipo
Número pines
BTERM
Final ráfaga
LA[27:2]
Bus dirección
1
I
129
26
O TS 8 mA
122, 119-105, 102-100, 98-92
LAD[31:0]
Bus datos
32
I/O TS 8 mA
52-62, 69-79, 82-91
LBE[3:0]
Bytes permitidos
4
O TS 12 mA
46-49
63
Total
Pines del bus de datos ISA (modo no multiplexado)
Pines
Símbolo
Nombre señal
Tipo
Número pines
BALE
Lanzamiento bus de
dirección permitido
1
O TS 8 mA
64
CHRDY
Canal preparado
1
I
45
IORD
Lectura E/S
1
O TS 8 mA
138
IOWR
Escritura E/S
1
O TS 8 mA
139
ISAA[1:0]
Bus dirección ISA
2
LA[23:2]
Bus dirección
22
LAD[7:0]
Bus datos
8
LAD[15:0]
Bus datos
16
LRESET
Interfaz ISA RESET
DRV de salida
1
O TP 8 mA
132
1
1
O TS 8 mA
O TS 8 mA
130
131
1
I
67
1
O TS
mA
MEMRD
MEMWR
NOWS
SBHE
Total
Lectura memoria
Escritura memoria
Ningún estado de
espera
Byte alto del sistema
habilitado
O TS 12
mA
O TS 8 mA
I/O TS 8
mA
I/O TS 8
mA
57
178
12
48, 49
116-105, 102-100, 98-92
84-91
74-79, 82-91
46
Descargar