Introducción a CAN bus: Descripción, ejemplos y aplicaciones de...

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA DESISTEMAS INFORMÁTICOS

PROYECTO FIN DE MÁSTER

Introducción a CAN bus: Descripción, ejemplos yaplicaciones de tiempo real

Autor:Adrián Martínez Requena

Tutor:Javier García Martín

Curso académico:2016 - 2017

Departamento de Sistemas Informáticos

4 de julio de 2017

http://www.upm.es/institucional

http://www.etsisi.upm.es/

http://www.etsisi.upm.es/

http://www.jamessmith.com

«Los hombres geniales empiezan grandes obras, los hombres trabajadores las terminan.»

Leonardo da Vinci

II

AbstractCAN technology is a communication protocol widely used in real-time and high-integrity environ-

ments. Due to its guarantees, it is frecuently used in the automotive and aeronautics industry, where thereliability in communications is crucial for the right operation of the systems.

With the elaboration of this project the intention is to establish a base when developing or implement-ing projects with the CAN bus technology, developing a guide using different solutions and techniquesfor the implementation, deployment and utilization of this protocol.

With this goal in mind, specific designs, examples and functional applications will be developed andproposed to make the use of the protocol more simple in other developements, and to ease the load ofinvestigation wich entails to start with CAN protocol without a previous base, trying to foment its usesin projets where originaly wasn’t planned due to a lack of time or resources.

Key words: CAN bus, Real Time, High integrity, Raspberry, Arduino.

IV

ResumenLa tecnología CAN es un protocolo de comunicaciones ampliamente usado en entornos y sistemas

con requisitos de tiempo real. Debido a sus garantías, es frecuentemente utilizado en el sector de la au-tomoción o la aeronáutica, en donde la fiabilidad en las comunicaciones es de vital importancia para elfuncionamiento de los sistemas.

Con la elaboración de este trabajo, se pretende aportar una base sobre la que apoyarse a la hora dedesarrollar e implementar proyectos con la tecnología CAN bus, desarrollando una guía que muestradiversas soluciones y técnicas para la implementación, despliegue y utilización de este protocolo.

Con este objetivo en mente, se van a plantear y desarrollar librerías, ejemplos y aplicaciones funcio-nales concretas para facilitar la utilización del protocolo en otros desarrollos, y así aligerar la carga deinvestigación e implementación que supone comenzar a utilizar el protocolo CAN sin una base previa.Se trata de fomentar así su utilización en proyectos en los que inicialmente no se había planteado su usopor falta tiempo o recursos.

Palabras clave: CAN bus, Tiempo real, Alta integridad, Raspberry, Arduino.

VI

Reconocimientos

A mi familia, por animarme a seguir adelante y a mejorar cada día.

A mi tutor, Javier García, por su apoyo y su orientación.

VIII

Índice general

Abstract IV

Resumen VI

Reconocimientos VIII

1 Introducción 11.1 Objetivos del proyecto y motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Otros buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Protocolo CAN 42.1 Ventajas del protocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Descripción del protocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Capa física del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Control de acceso al medio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Formato de las tramas CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5.1 Tramas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.2 Tramas de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Estados de los nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Desarrollo del proyecto 123.1 Desarrollo de bajo nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.2 Dispositivos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Circuito diseñado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.4 Programación de Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.5 Ejecución y resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Desarrollo con el módulo PiCAN2 CAN-Bus Board . . . . . . . . . . . . . . . . . . . . 223.2.1 Instalación y configuración del módulo PiCAN2 CAN-Bus Board . . . . . . . . 25

3.2.1.1 Módulo PiCAN2 CAN-Bus Board . . . . . . . . . . . . . . . . . . . 253.2.1.2 Instalación y configuración . . . . . . . . . . . . . . . . . . . . . . . 263.2.1.3 Pruebas de envío y recepción . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2 Librerías CAN desarrolladas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.2.1 Librería en C canLib.c . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.2.2 Librería en ADA can.adb . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Ejemplo de aplicación CAN - Control de tráfico . . . . . . . . . . . . . . . . . . . . . . 403.3.1 Objetivos del proyecto original . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.2 Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.3 Planificación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

X

4 Resultados 564.1 Resultados del ejemplo de aplicación de control de tráfico . . . . . . . . . . . . . . . . . 564.2 Objetivos logrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Conclusión y trabajos futuros 605.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 Impactos sociales y ambientales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Trabajos futuros y mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Glosario 65

Bibliografía 69

A Librería can.h de Linux 71

B Librería Interfaces.C de ADA 77

XI

Índice de figuras

1.1 Ejemplo de reducción de las comunicaciones necesarias . . . . . . . . . . . . . . . . . . 1

2.1 Velocidad de transmisión del CAN bus con respecto a la distancia . . . . . . . . . . . . 52.2 Niveles de tensión del CAN bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Formato de las tramas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Formato de las tramas de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Estado de error de los nodos CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Esquemático de la placa arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Esquemático del transceptor MCP2551 . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Esquemático del microcontrolador MCP2515 . . . . . . . . . . . . . . . . . . . . . . . 153.4 Esquemático del circuito CAN diseñado . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5 Tabla de relación entre frecuencias y capacidad de los condensadores . . . . . . . . . . . 173.6 Conexiones finales entre las placas Arduino . . . . . . . . . . . . . . . . . . . . . . . . 183.7 Trazas del puerto serie de Arduino. Recepción CAN (encima) y envío de CAN (debajo) . 223.8 Diagrama de la Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.9 Esquema de pines de la Raspberry Pi modelo B . . . . . . . . . . . . . . . . . . . . . . 243.10 PiCAN2 CAN-Bus Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.11 Esquemático del fabricante de la placa PiCAN2 CAN-Bus Board . . . . . . . . . . . . . 263.12 Interfaz can0 activa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.13 Envío de tramas CAN desde Raspberry a Arduino . . . . . . . . . . . . . . . . . . . . . 293.14 Envío de tramas CAN desde Arduino a Raspberry . . . . . . . . . . . . . . . . . . . . . 303.15 Envío de tramas entre dos placas Raspberry . . . . . . . . . . . . . . . . . . . . . . . . 313.16 Esquema interno de un nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.17 Conexiones entre los cuatro nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.18 Atributos temporales y dependencias de las tareas . . . . . . . . . . . . . . . . . . . . . 533.19 Estudio de planificabilidad con la herramienta RTA . . . . . . . . . . . . . . . . . . . . 55

XII

Índice de cuadros

3.1 Parámetros asignados a las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Tiempo empleado en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2 Coste aproximado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

XIII

Lista de Abreviaturas

CAN Controller Area NetworkMVB Multifunction Vehicle BusFIP Factory Implementation ProtocolISO International Organization for StandardizationACK ACKnowledgementEOF End Of FileE/S Entrada / SalidaHW HardWareARM Acorn RISC MachineCPU Central Processing UnitLED Light-Emitting DiodeTB TeraByteGB GigaByteMB MegaByteB ByteOSI Open System InterconnectionTDMA Time Division Multiple AccessPWM Pulse Width ModulationIDE Integrated Development EnvironmentPDIP Plastic Dual In-line PackageSPI Serial Peripheral InterfaceIP Internet ProtocolSW SoftWareTCP Transmision Control ProtocolUI User InterfaceUSB Universal Serial Bus

XIV

Lista de Símbolos

T Tiempo sC Capacidad eléctrica µFF Frecuencia Hz

V Voltaje VR Resistencia ΩI Intensidad A

MHz MegaherciospF Picofaradios

MB/s Megabytes por segundoKB/s Kilobytes por segundoh Horass Segundosms Milisegundosµs Microsegundos

B BytesMb MegabytesB Bytes

m MetrosKm Kilómetros

XV

Capítulo 1

Introducción

La tecnología CAN es un protocolo de comunicaciones ampliamente usado en entornos y sistemas con

requisitos de tiempo real, desarrollado por la compañía Robert Bosch GmbH en 1986, surgido por la

necesidad de conectar cada vez más y más dispositivos electrónicos en el interior de los coches. Debido

a sus garantías, es frecuentemente utilizado en el sector de la automoción o la aeronáutica, en donde la

fiabilidad en las comunicaciones es de vital importancia para el funcionamiento de los sistemas.

La implantación de este modelo de comunicaciones supuso un avance en cuanto a la cantidad de

conexiones entre dispositivos que eran necesarias para mantener todos los elementos comunicados, ya

que el protocolo CAN emplea un único bus de comunicaciones, compartido por todos los dispositivos y

evita la necesidad de establecer una conexión puto a punto con cada uno de ellos.

FIGURA 1.1: Ejemplo de reducción de las comunicaciones necesarias

1

Capítulo 1. Introducción 2

1.1 Objetivos del proyecto y motivación

Con este trabajo, se pretende elaborar una documentación concisa que sirva para desarrollar proyectos

con la tecnología CAN bus. Esta documentación tendrá inicialmente forma de guía, describiendo diver-

sas soluciones técnicas para la implementación, despliegue y utilización de este protocolo.

Con este objetivo en mente, se van a desarrollar librerías, ejemplos y aplicaciones funcionales con-

cretas para facilitar la implementación de este protocolo en otros proyectos, aportando así herramientas,

documentación y una base sobre la que trabajar, para así tratar de fomentar su uso en proyectos y ámbi-

tos en los que inicialmente no se había planteado su utilización.

Los ejemplos desarrollados utilizarán el bus en distintas configuraciones y tendrán distinto grado de

dificultad. Finalmente se presentará un ejemplo de aplicación de tiempo real, orientada al control del

tráfico, que utilizará el bus con restricciones estrictas en el tiempo de respuesta y se desarrollarán los

análisis correspondientes.

Una de las motivaciones para el desarrollo de este proyecto, surgió en parte en el desarrollo de un

trabajo previo [1], centrado en un sistema distribuido en tiempo real, en el que, a pesar de las ventajas

de este protocolo y las contraindicaciones de emplear un protocolo no orientado a sistemas de tiempo

real, no se llegó a incluir en el mismo debido al tiempo requerido para su desarrollo e investigación con

respecto a otros protocolos de comunicación mas extendidos.

1.2 Otros buses

A pesar de ser CAN uno de los protocolos de comunicaciones mas utilizados en entornos de tiempo real

y de alta integridad, también existen otros protocolos diseñados para tal fin.

• MVB: Siglas de Multifunction Vehicle Bus, es un protocolo principalmente empleado en la in-

dustria ferroviaria para comunicar diversos sistemas críticos dentro del tren. Posee detección de

colisiones y garantías temporales y de entrega.

Capítulo 1. Introducción 3

• FIP: Siglas de Factory Implementation Protocol, es un protocolo de comunicaciones en tiempo

real poco extendido, que funciona sobre Ethernet, proporcionando garantías de tiempo y de entrega

[2].

A pesar de existir otras tecnologías alternativas al CAN bus, están mucho menos extendidas que éste

y se localizan principalmente en diversos ámbitos industriales específicos. Ya que el objetivo del pro-

yecto es facilitar el uso de un protocolo de comunicaciones para sistemas de tiempo real, se ha elegido

el protocolo CAN por ser el mas usado y el mas extendido.

Capítulo 2

Protocolo CAN

2.1 Ventajas del protocolo CAN

Uno de los puntos fuertes de esta tecnología, y lo que la ha hecho perdurar en el tiempo a pesar de la

aparición de otros protocolos de comunicación con mayor velocidad o capaces de transmitir a mayor

distancia, son las garantías de comunicación que ofrece, las cuales son muy importantes a la hora de

desarrollar sistemas con características de tiempo real o de alta integridad.

• Posee herramientas para la detección de errores en la transmisión, así como la capacidad de re-

transmisión automática de las tramas erróneas.

• Capacidad de discernir entre errores puntuales en la transmisión, o errores producidos por el fallo

de un nodo, en cuyo caso, tiene la capacidad de desconectarlo para evitar que el error sature la

red.

• Priorización de mensajes y garantía en los tiempos de latencia en la entrega de los mismos. Ésta es

una de las características por las que este protocolo de comunicaciones es ampliamente utilizado

en el ámbito de los sistemas de tiempo real.

• Garantías en la consistencia de los datos.

• Flexibilidad en la configuración de la red, tanto en número de nodos, como en la disposición de los

mismos, pudiendo añadirse o quitarse nodos de forma dinámica sin afectar al protocolo. Pueden

conectarse hasta 110 nodos a una red CAN.

4

Capítulo 2. Protocolo CAN 5

2.2 Descripción del protocolo CAN

El protocolo CAN está especificado en el estándar ISO 11898[3], el cual contiene diversas normas espe-

cíficas para distintos aspectos del protocolo y diversos tipos de funcionamiento. Por ejemplo, la norma

ISO 11898-2 estandariza el protocolo CAN del alta velocidad, pudiendo alcanzar velocidades de hasta

1 MB/s, o la norma ISO 11898-3, que estandariza el protocolo CAN de baja velocidad tolerante a fallos.

FIGURA 2.1: Velocidad de transmisión del CAN bus con respecto a la distancia

Un módulo CAN se compone de dos elementos básicos:

• Controlador: Gestiona el montaje de las tramas CAN, comprobación de errores en la transmisión,

o en otros nodos, así como de la detección de colisiones,

• Transmisor / Receptor: También llamado transceptor. Este módulo es el encargado de la codi-

ficación y decodificación de los mensajes en el bus, sincronización, control de los niveles de la

señal o del control de acceso al medio.

El controlador CAN, así como el transceptor, son módulos independientes de los nodos, lo que per-

mite que éstos no tengan que destinar recursos en la gestión de las comunicaciones, acceso al medio o

colisiones entre otros. A pesar de que algunos microcontroladores poseen módulos CAN en un único

encapsulado, internamente son circuitos independientes en la mayoría de los casos.

Cualquier dispositivo conectado al bus puede mandar mensajes, y todos los nodos conectados al

mismo lo recibirán. Para discriminar los tipos de mensajes, éstos llevan un identificador asociado. De

este modo, cada nodo puede procesar los mensajes que le interesen o por el contrario, descartarlos.


2.3 Capa física del protocolo

Posee una topología en forma de bus, en la que únicamente son necesarios dos cables trenzados y con

una impedancia de 120 Ω, para interconectar todos los dispositivos en una misma red. Las señales de

estos cables se denominan CAN_H (CAN high) y CAN_L (CAN low) y dependiendo del voltaje de las

mismas, el bus puede encontrarse en modo recesivo, con ambos cables con el mismo nivel de tensión,

o en modo dominante, con una diferencia de tensión entre los cables de al menos 1,5V. Este modo de

comunicación tiene como objetivo proporcionar una mayor protección frente a interferencias electro-

magnéticas.

Esta protección viene dada, debido a que la lectura de los bits se basa en la diferencia de voltaje entre

los dos cables trenzados, por lo que en caso de verse sometidas a la misma influencia electromagnética,

a pesar de la variación señal en los cables, la diferencia de voltaje entre ellos se mantiene constante.

FIGURA 2.2: Niveles de tensión del CAN bus

https://es.wikipedia.org/wiki/Bus_CAN


2.4 Control de acceso al medio

El protocolo CAN tiene otra característica denominada arbitraje, mediante la cual se controla el acceso

al medio por parte de los nodos y se evitan posibles colisiones en las comunicaciones. Esta caracterís-

tica forma parte del control de acceso al medio implementado por el protocolo CAN, CSMA/CD+CR

(Carrier Sense, Multiple Access/Collision Detection + Collision Resolution o Acceso Múltiple con de-

tección de portadora, detección de colisión más Resolución de colisión)

En el bus, los bits dominantes equivalen al nivel lógico "0", y los bits recesivos al valor lógico "1".

Al inicio de las tramas enviadas por los nodos, se encuentra un campo dedicado específicamente al ar-

bitraje, que coincide con el identificador propio del nodo. Antes de transmitir, los nodos deben vigilar

el bus durante un período en el que no puede haber actividad en él, tras ésto, y cuando dos nodos tratan

de transmitir de forma simultánea, los bits dominantes prevalecen sobre los bits recesivos, por lo que

el nodo que trata de transmitir la trama con bits dominantes (numero de identificación menor) es capaz

de detectar la colisión con los bits recesivos (numero de identificación mayor). Para que la detección de

colisiones sea eficaz, los nodos deben tener una correcta sincronización, manteniendo las frecuencias de

reloj de los controladores CAN dentro de los valores tolerados[4].

El nodo que detecta la colisión, deja de transmitir inmediatamente y espera hasta finalizar la comu-

nicación del otro nodo para intentarlo de nuevo.

2.5 Formato de las tramas CAN

El protocolo CAN contempla diferentes formatos de tramas, cada una orientada a un propósito específico

dentro del funcionamiento del protocolo. Las mas importantes son:

• Tramas de datos: Tramas utilizadas para el paso de información entre nodos, que puede ser

enviada y recibida por uno o varios de ellos.

• Tramas de error: Tramas utilizadas cuando algún nodo de la red detecta un error en alguno de

los mensajes transmitidos por otros nodos. Violan las normas del formato de tramas CAN.

• Tramas de petición remota: Tramas utilizadas para solicitar el envío de información a otro nodo.

Se envía una trama con el identificador del nodo del que se requiere el envío de información, éste

lo recibe y devuelve la información con una trama de datos.


• Tramas de sobrecarga: Al igual que las tramas de error, violan las normas del formato de tramas

CAN. Es enviada por un nodo cuando éste está sobrecargado, lo que provoca que el bus incluya

un retardo extra entre tramas.

Cuando el bus está en reposo (no hay intercambio de tramas), se mantiene de manera constante un

nivel recesivo en el bus. Cuando se tienen que enviar mensajes que ocupan mas de una trama de datos,

éstas se separan entre si por una secuencia predeterminada, llamada espacio inter-trama, compuesta por

3 bits recesivos.

2.5.1 Tramas de datos

Este tipo de tramas es capaz de enviar hasta 8 Bytes de información. Poseen al inicio un identificador,

que puede ser con el formato estándar de 11 bits o con el formato extendido, de 29 bits.

FIGURA 2.3: Formato de las tramas de datos

https://es.wikipedia.org/wiki/Bus_CAN

Las tramas se inician con un un único bit dominante, empleado para la sincronización con el resto de

nodos. Posteriormente se encuentra el campo del identificador, que a parte de servir como identificador

del nodo, también representa la prioridad de la trama en la red. Conociendo los identificadores de todos

las tramas que intentan ser transmitidas, se puede establecer de manera determinista el orden en el que

son transmitidas. Así, una trama CAN con identificador más bajo (mayor número de bits dominantes

en las primeras posiciones) tiene más prioridad que una trama con identificador más alto. En el formato

estándar está compuesta por 11 bits, terminado con un bit adicional empleado para diferenciar entre

tramas de datos (valor 0), o tramas de petición remota (valor 1).


En el campo de control, los dos bits iniciales están reservados para un uso futuro, y posteriormente

se encuentran cuatro bits, que definen el tamaño del campo de datos de la trama que se encuentra a

continuación. La parte de la trama coloreada en rojo en la figura 2.3 contiene el campo de datos, que

puede abarcar desde los 0 a los 8 Bytes.

Por último, se encuentra el campo de CRC (Código de redundancia cíclica), que se encarga de

asegurar la integridad de los datos enviados. La trama termina con un bit recesivo para el delimitador

CRC, un campo de dos bits empleado como celda de reconocimiento o ACK y el fin de trama o EOF,

consistente en 7 bits recesivos sucesivos. La trama debe contener al final de la misma el espaciado re-

glamentario entre tramas, compuesto por tres bits recesivos.

2.5.2 Tramas de error

El protocolo CAN posee una norma de relleno de bits en las tramas, que consiste en que cada secuencia

de cinco bits con el mismo valor, se introduce un bit de valor inverso. Esto provoca que el formato de

las tramas de error incumplan esta norma y puedan ser detectadas sobre las tramas de datos.

Las tramas de error pueden ser generadas por cualquier nodo que detecte un error en las comunica-

ciones. El formato de las mismas es:

FIGURA 2.4: Formato de las tramas de error

http://wiki.csie.ncku.edu.tw/embedded/CAN

Se componen de dos campos. En la parte inicial, se encuentra el indicador de error, o error flag,

cuyo formato depende el tipo de nodo que haya detectado el error. Si el error ha sido detectado por un


nodo en estado de error activo (véase 2.6), interrumpe inmediatamente la comunicación, rellenando el

valor de este campo con 6 bits dominantes e incumpliendo las normas de relleno de bits, por lo que es

detectada por el resto de nodos, y estos generan a su vez tramas de error.

Si el error ha sido detectado por un nodo con estado de error pasivo (véase 2.6), rellena el campo del

indicador de error con 6 bits recesivos. Al enviarse bits recesivos, la comunicación no se ve interrumpida

y no es detectada por ningún otro nodo de la red, únicamente es detectada por el nodo que envía la trama

y se tiene en cuenta a la hora de determinar el estado de error de ese nodo.

En la parte final se encuentra el delimitador de error, o error delimiter, compuesto por 8 bits recesivos

seguidos, que indican el final de la trama de error y la posibilidad de continuar con las comunicaciones

normalmente.

2.6 Estados de los nodos

Para evitar que un nodo con errores condicione el funcionamiento de la red o pueda provocar fallos o

saturaciones, el protocolo dispone de medidas para desconectar de la red este tipo de nodos. Éstos se

pueden encontrar en tres estados diferentes:

• Error activo: El nodo puede enviar mensajes y tramas de error normalmente. Es el estado normal

de un nodo.

• Error pasivo: El nodo cambia el formato de sus tramas de error, enviando 12 bits recesivos. De

este modo, el resto de nodos no son capaces de detectarlas y no realentiza las comunicaciones.

• Bus off o Anulado: El nodo se auto-desconecta del bus, se deshabilita su transceptor y no participa

en la comunicación.

Todos los nodos detectan errores, en el momento en el que uno de los nodos detecta un error, envía

al resto de nodos una trama de error, compuesta por 6 bits dominantes, y 6 bits recesivos, la cual viola

las reglas del formato de las tramas CAN. Todos los nodos descartan el mensaje erróneo y el emisor lo

retransmite de nuevo. Tras la detección de un error, se incrementa el valor de los contadores de errores

de transmisión (TEC) y de errores de recepción (REC), incluidos en el controlador de comunicaciones

del emisor. Los sucesivos envíos o recepciones correctas de mensajes, decrementan el valor de estos


contadores.

El valor de estos dos contadores, determina el estado del nodo, pudiendo variar entre los tres estados

mencionados anteriormente, y comportándose de la siguiente forma:

FIGURA 2.5: Estado de error de los nodos CAN

http://canbus.pl/index.php?id=4&lang=en

Cuando un nodo se desconecta de la red, se resetea, configura y se conecta de nuevo a la red, pero

no podrá comenzar a transmitir de nuevo hasta no haber recibido 128 secuencias de 11 bits recesivos sin

errores en el bus.

Capítulo 3

Desarrollo del proyecto

El planteamiento del proyecto se ha tratado de orientar para abarcar el mayor número de situaciones

posible, por lo que durante el desarrollo del mismo, se han dividido los esfuerzos en diversos ámbitos

que hemos considerado de mas utilidad, dada la intención del proyecto.

Inicialmente se ha comenzado por un desarrollo a más bajo nivel, diseñando e implementando un

circuito CAN bus sobre una placa de prototipado, capaz de establecer comunicación entre dos dispositi-

vos Arduino.

Posteriormente, y componiendo el grueso del trabajo, los esfuerzos se han orientado al desarrollo

en la placa Raspberry Pi, empleando una placa compatible independiente para el protocolo CAN. Se ha

configurado y probado, y se han desarrollado librerías en C para su uso.

Finalmente se han empleado estas librerías en un proyecto codificado en el lenguaje de programa-

ción ADA, para demostrar y comprobar su correcto funcionamiento y utilidad.

3.1 Desarrollo de bajo nivel

Uno de los primeros planteamientos a los que se le pretendía dar solución, era dar soporte a los sistemas

mas simples o de bajo nivel, que estuvieran en la necesidad de implementar este protocolo de comuni-

caciones, y que no dispusieran de protocolo de comunicación ya implantado por un sistema operativo.

Para ello se ha diseñado una implementación basada en dos chips de la empresa Microchip, acompañada

del circuito necesario para su funcionamiento, dando así la oportunidad de desarrollar placas a medida,

compatibles tanto con Arduino como con otro tipo de Microcontroladores o Microprocesadores. Para

12

Capítulo 3. Desarrollo del proyecto 13

probar el diseño del circuito y que la comunicación funciona correctamente, se ha empleado placas Ar-

duino.

3.1.1 Arduino

La placa de Arduino utilizada ha sido la placa Arduino Uno. Es una pequeña placa que da soporte

electrónico al microcontrolador ATmega328P [5] que lleva incorporado. Dispone además de 14 pines

digitales de entrada/salida, pudiendo ser empleados 6 de ellos como señales PWM.

Las ventajas que aporta el desarrollo en esta placa con respecto a los microcontroladores tradiciona-

les, es la sencillez de uso, ya que posee todo el circuito necesario impreso en la misma placa y está lista

para su uso. Además, posee una interfaz USB, que permite la posibilidad de conectarla directamente al

ordenador y programarlo a través de un entorno de desarollo (IDE) específico de Arduino.

Es por ello que su uso está muy extendido y el motivo por el que se ha empleado para este primer

desarrollo del proyecto.

FIGURA 3.1: Esquemático de la placa arduino

https://aprendiendoarduino.wordpress.com


3.1.2 Dispositivos utilizados

El peso de la parte electrónica del protocolo CAN recae principalmente en los dispositivos del fabri-

cante Microchip empleados, los modelos empleados han sido MCP2551 para el transceptor CAN y el

MCP2515 para el controlador CAN.

• MCP2551[6]: Este transceptor es el encargado del control de la parte física del protocolo CAN,

la gestión de la codificación de los bits en el medio y el control de los niveles de tensión. Puede

operar con velocidades de hasta 1 MB/s y soporta la conexión de hasta 112 nodos de forma

simultánea a la red.

FIGURA 3.2: Esquemático del transceptor MCP2551

http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf

Se ha empleado el modelo con encapsulamiento PDIP, ya que la implementación física del circuito

de prueba se ha llevado a cabo sobre una placa de prototipado. El dispositivo dispone de dos

patillas, RXD (recibir) y TXD (transmitir), por las que se comunica con el módulo MCP2515, y

dos patillas CAN_H (can high) y CAN_L (can low) encargadas de la conexión con el bus CAN,

además de las patas de alimentación VSS y VDD.

• MCP2515[7]: Este microcontrolador se encarga de la implementación de la especificación del

protocolo CAN, capaz de transmitir tanto tramas estándar como tramas extendidas. La comunica-

ción de conexión que ofrece es mediante protocolo serie (Serial Peripheral Interface o SPI).


FIGURA 3.3: Esquemático del microcontrolador MCP2515

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

Se ha empleado el modelo con encapsulamiento PDIP de 18 pines, ya que la implementación fí-

sica del circuito de prueba se ha llevado a cabo sobre una placa de prototipado. Además de las

entradas mas comunes en los microcontroladores, como pueden ser la entrada de alimentación

o de tierra (entradas VSS y VDD), requiere además de la entrada de una señal de reloj externa

(entradas OSC1 y OSC2).

También posee tres entradas específicas para la comunicación con el exterior mediante SPI (pines

CS, SO, SI y SCK), dos para la comunicación con el transceptor CAN (pines TXCAN y RXCAN),

una para el RESET del microcontrolador y una salida específica de interrupciones, que se activa

para notificar la recepción de una trama CAN (pin INT).

3.1.3 Circuito diseñado

Tras la elección de los microcontroladores a utilizar, se ha diseñado el circuito electrónico necesario

para su funcionamiento, alimentado a 5V y siguiendo las especificaciones del datasheet del fabricante.

Se han comprado los componentes y se ha diseñado y probado de la siguiente forma.


FIGURA 3.4: Esquemático del circuito CAN diseñado


Se han conectado los pines TXCAN y RXCAN del microcontrolador MCP2515 a los pines TXD y

RXD del microcontrolador MCP2551 respectivamente, los cuales con responsables de la comunicación

entre éstos. Se les ha añadido también a ambas conexiones una bombilla LED roja, conectada por segu-

ridad a una resistencia de 150 Ω, que se ilumina o parpadea cuando hay actividad en la conexión.

Se ha desarrollado un circuito de reloj según la tabla de especificaciones del datasheet, empleando

un reloj de 16 MHz, acompañado de dos condensadores de 22 pF conectados en paralelo.

FIGURA 3.5: Tabla de relación entre frecuencias y capacidad de los condensadores

Se han conectado, con una resistencia de 10 KΩ los pines de RESET del componente MCP2515 a

5V, ya que son pines activos a nivel bajo, para evitar un reseteo indeseado. También se ha añadido una

bombilla LED roja, con una resistencia de 150 Ω por seguridad, conectado entre el pin INT del compo-

nente MCP 2515 y la fuente de 5V para señalar de manera visual las interrupciones producidas por la

recepción de nuevas tramas CAN.


Se ha añadido una resistencia de 120 Ω, necesaria como terminación para el bus CAN.

Por último, se ha conectado una resistencia de 47 KΩ entre el pin RS del microcontrolador MCP2551

y la toma de tierra a 0V, para seleccionar el modo de operación del componente. Conectándola de esta

manera, el modo de operación seleccionado es HIGH-SPEED o alta velocidad.

FIGURA 3.6: Conexiones finales entre las placas Arduino

3.1.4 Programación de Arduino

Se han desarrollado dos programas de ejemplo de uso y de comprobación de funcionamiento para Ar-

duino, uno para cada placa que se comunica. Una de ellas actuará como emisora de tramas CAN, y la

otra como receptora de tramas CAN.

Se ha empleado la librería CAN_BUS_Shield-master[8], bajo licencia MIT, que aporta las funciones

básicas para operar con la interfaz y el protocolo CAN, y la librería SPI nativa de Arduino, para la co-

municación con el microcontrolador. La librería CAN_BUS_Shield-master, al no ser una librería nativa


de Arduino, tiene que ser importada expresamente desde el menú del entorno de desarrollo de Arduino.

El código de la placa Arduino que envía las tramas CAN es el siguiente:

// demo: CAN-BUS Shield, send data

#include <mcp_can.h>

#include <SPI.h>

MCP_CAN CAN0(10); // Set CS to pin 10

void setup()

Serial.begin(115200);

Serial.print("=== INIT ====\r\n");

if(CAN0.begin(CAN_500KBPS) == CAN_OK) // init can bus

Serial.print("can init ok!!\r\n");

else Serial.print("Can init fail!!\r\n");

unsigned char stmp[8] = 0, 1, 2, 3, 4, 5, 6, 7;

void loop()

// send data: id = 0x00, standrad frame, data len = 8, stmp: data buffer

CAN0.sendMsgBuf(0x00, 0, 8, stmp);

delay(100); // send data per 100ms

La función Setup() configura el puerto serie a 115200 baudios y envía una traza para comprobar que

funciona correctamente, después inicializa el protocolo CAN con una frecuencia de 500 KB/s. Final-

mente, envía en bucle una trama CAN predeterminada cada 100 ms.

El código de la placa Arduino que recibe las tramas CAN es el siguiente:


#include <mcp_can.h>

#include <SPI.h>

long unsigned int rxId;

unsigned char len = 0;

unsigned char rxBuf[8];

MCP_CAN CAN0(10); // Set CS to pin 10

void setup()

Serial.begin(115200);

Serial.print("=== INIT ====\r\n");

CAN0.begin(CAN_500KBPS); // init can bus : baudrate = 500k

pinMode(2, INPUT); // Setting pin 2 for /INT input

Serial.println("MCP2515 Library Receive Example...");

void loop()

if(!digitalRead(2)) // If pin 2 is low, read receive buffer

// Read data: len = data length, buf = data byte(s)

CAN0.readMsgBuf(&len, rxBuf);

rxId = CAN0.getCanId(); // Get message ID

Serial.print("ID: ");

Serial.print(rxId, HEX);

Serial.print(" Data: ");

for(int i = 0; i<len; i++) // Print each byte of the data

// If data byte is less than 0x10, add a leading zero

if(rxBuf[i] < 0x10)


Serial.print("0");

Serial.print(rxBuf[i], HEX);

Serial.print(" ");

Serial.println();

Al igual que el programa de envío de tramas, la función Setup() configura el puerto serie a 115200

baudios y envía una traza para comprobar que funciona correctamente, después inicializa el protocolo

CAN con una frecuencia de 500 KB/s. Como añadido adicional, configura el pin 2 de la placa de arduino

como entrada, para recibir los cambios el pin INT del microcontrolador MCP2515.

Posteriormente, se lee en bucle el pin 2 de la placa, esperando un cambio que indique la recepción

de una trama CAN. Cuando esa recepción se produce, se lee el mensaje y se almacena en un buffer de

8 Bytes. Por último imprime el ID de la trama CAN recibida y el contenido de los datos, en formato

hexadecimal.

3.1.5 Ejecución y resultados

Se ha probado físicamente el circuito diseñado con todos sus componentes, y se han conectado los dos

módulos CAN a los pines especificados de la placa Arduino. Tras ésto, se han compilado y cargado a

cada una de las placas Arduino, los programas de recepción y envío de tramas CAN con las librerías

necesarias.

Se han reiniciado las placas para arrancar las aplicaciones cargadas y, empleando una herramienta

específica del entorno de desarrollo de Arduino, se han monitorizado los puertos serie de ambas placas,

a la frecuencia establecida de 115200 baudios, para comprobar si las trazas recibidas eran correctas.


FIGURA 3.7: Trazas del puerto serie de Arduino. Recepción CAN (encima) y envío deCAN (debajo)

Tras ésto, se ha podido comprobar que el circuito funciona correctamente y que todos los LEDS se

comportan según lo esperado. También, a través del puerto serie, se ha comprobado que la inicialización

el protocolo CAN es correcta y que se ha establecido la comunicación entre las dos placas Arduino,

tanto de recepción como de envío de tramas, dando así la prueba como satisfactoria.

3.2 Desarrollo con el módulo PiCAN2 CAN-Bus Board

Como siguiente fase del proyecto, nos hemos centrado en la implementación del bus CAN en el compu-

tador de placa única Raspberry Pi. Es una placa del tamaño de una tarjeta de crédito con el system-on-a-

chip Broadcom BCM2835, un procesador de ARM ARM1176JZF-S a 700 MHz, el procesador gráfico

VideoCore IV y una memoria RAM de 512 MB. Funciona con una alimentación de 5V, proporcionada


a través de un conector micro USB. Estas características nos proporcionan la potencia y funcionalidades

necesarias para implementar el protocolo CAN bus en ella. (véase figura 3.8).

FIGURA 3.8: Diagrama de la Raspberry Pi

https://tecnovortex.com/locos-por-el-raspberry-pi/

Existen diferentes modelos de este tipo de placa, que han ido desarrollándose y mejorándose con el

tiempo, añadiendo mas potencia, dispositivos adicionales o funcionalidades. El modelo de placa Rasp-

berry pi elegido es el B+, ya que dispone de la potencia y conexiones necesarias para la ejecución de

los ejemplos sobre CAN, además de ofrecer compatibilidad con el módulo externo CAN elegido para la

implementación del protocolo.

La Raspberry Pi modelo B+ posee un total de 40 pines digitales para dar soporte a la conexión de

diversos elementos, tal como se muestra en la figura 3.9.


FIGURA 3.9: Esquema de pines de la Raspberry Pi modelo B

http://www.element14.com

De todos estos pines, los que nos interesan son los GPIO, que nos dan la posibilidad de leer y escribir

de ellos, pudiendo interactuar con el entorno y el resto de elementos. La placa posee 27 pines de este tipo.

Al inicio del proyecto se planteó la utilización del sistema operativo de Hard Real-Time Mar-

teOS[9], desarrollado por la Universidad de Cantabria, especialmente pensado para dispositivos em-

potrados. Este sistema operativo proporciona un verdadero entorno de tiempo real para ejecutar aplica-

ciones con este tipo de requerimientos. Finalmente, y debido a lo reciente del desarrollo de este sistema

operativo en este tipo de arquitecturas ARM[10] y la complejidad para implementarlo, se descartó su

uso.

Finalmente, como sistema operativo, se empleó Raspbian, un sistema operativo oficial para Rasp-

berry Pi basado en Debian y por lo tanto, libre.


3.2.1 Instalación y configuración del módulo PiCAN2 CAN-Bus Board

3.2.1.1 Módulo PiCAN2 CAN-Bus Board

Para la parte Hardware de control y transmisión del protocolo CAN bus, en este desarrollo sobre Rasp-

berry, se ha decidido emplear una placa ya fabricada específica para este propósito, pero con la parti-

cularidad de que los microcontroladores sobre los que ha basado su desarrollo, son los mismos que los

empleados en el desarrollo sobre Arduino, el MCP 2551 y el MCP2515.

La placa escogida es la PiCAN2 CAN-Bus Board, del fabricante SK Pang Electronics, la cual se

encarga de gestionar tanto la parte física como la parte de control y aplicación de protocolo CAN, tal y

como se comportaba el circuito desarrollado para Arduino, siendo éstos totalmente compatibles entre si.

FIGURA 3.10: PiCAN2 CAN-Bus Board

http://skpang.co.uk/catalog/pican2-canbus-board-for-raspberry-pi-23-p-1475.html

Este módulo soporta velocidades de hasta 1 MB/s, siendo capaz de enviar tramas en formato están-

dar o en formato extendido. También posee en la placa un resistencia de 120 Ω para poder ser utilizada

como terminación del bus CAN, para la cual es necesario insertar y soldar dos pines en el conector JP3

(véase figura 3.11) y unirlos para hacer válida la conexión. El pin de interrupción para la recepción de

tramas CAN se encuentra en el pin GPIO25 de la Raspberry.

Las conexiones con el bus CAN puede hacerse mediante un conector D-sub de nueve pines, o me-

diante la conexión directa de los cables CAN_H y CAN_L atornillándolos a los terminales. La conexión


con Raspberry se realiza sobre los pines de entrada/salida de la misma placa mediante un adaptador de

40 pines a medida sobre el que está construido el módulo PiCAN2 CAN-Bus Board.

FIGURA 3.11: Esquemático del fabricante de la placa PiCAN2 CAN-Bus Board

http://skpang.co.uk/catalog/images/raspberrypi/pi_2/pican2_rev_B.pdf

Como se puede apreciar en el esquemático del fabricante de la placa, las bases sobre la que está cons-

truida esta placa y la placa diseñada para el circuito de Arduino son similares, al emplearse los mismos

microcontroladores en ambos casos. Esta placa hace uso de los pines SPI_CE0, SPI_SCLK, SPI_MOSI

y SPI_MISO para la comunicación serie con la placa Raspberry y el pin GPIO25 para las interrupciones.

3.2.1.2 Instalación y configuración

Una vez escogida la placa CAN bus a utilizar, instalada en la placa Raspberry con el sistema operativo

Raspbian funcionando correctamente en la misma, se procede a especificar los pasos necesarios para


su instalación y puesta en funcionamiento, para que la placa Raspberry pueda detectar el módulo CAN

como una interfaz propia de comunicaciones.

Lo primero que necesitamos, es que el kernel tenga compilado la librería mcp251x. El kernel de

Raspbian sí que la tiene compilada por defecto, para comprobarlo, en un terminal de linux en la Rasp-

berry escribimos:

modprobe mcp251x

Tras ésto, tenemos que habilitar la interfaz SPI de la placa Raspberry, utilizada para la comunicación

con la placa PiCAN2 CAN-Bus Board, mediante la utilidad raspi-config.

cd /usr/bin

sudo ./raspi-config

Tras ésto se abrirá un menú, por el que deberemos navegar a través de:

Advanced Options > SPI > Enable > Ok

Con esta opción activada, el kernel cargará al inicio el módulo SPI por defecto. Tras ésto, deberemos

asegurarnos de que disponemos de las últimas versiones de los paquetes, para lo que lo comprobaremos

con un update y, tras ésto, reiniciaremos la placa para hacer efectivos los cambios.

sudo apt-get update

sudo apt-get upgrade

sudo reboot

Al arrancar de nuevo, procederemos a configurar la interfaz que va a ser utilizada para la comunica-

ción CAN. Editamos el fichero /boot/config.txt.

sudo nano /boot/config.txt

Y añadimos al final del mismo las siguientes líneas:

dtparam=spi=on

dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25

dtoverlay=spi-bcm2835-overlay


Con estas opciones, configuramos al inicio la librería mcp251x, asignando el nombre “can0”a la

interfaz CAN, establecemos la frecuencia que emplea la placa para la comunicación, 16 MHz, la cual

debe coincidir con el reloj que se esté empleando en la placa del módulo CAN. Por último se configura

el pin GPIO25 de la placa Raspberry como pin de recepción de las interrupciones de tramas CAN.

Tras ésto, reiniciamos de nuevo la placa:

sudo reboot

Por último, ya podemos activar la interfaz de red que será utilizada para la comunicación CAN,

mediante la siguiente instrucción (la interfaz solo se mantiene activa hasta el siguiente reinicio, para

volver a activarla, ejecutar de nuevo esta instrucción):

sudo /sbin/ip link set can0 up type can bitrate 500000

Con este comando, activamos la interfaz “can0”a una velocidad de 0.5 MB/s. Tras ésto, la interfaz

debería ser visible y esta funcionando correctamente, para comprobarlo, ejecutamos el comando:

ifconfig

La interfaz debería aparecer como en la siguiente figura:

FIGURA 3.12: Interfaz can0 activa

3.2.1.3 Pruebas de envío y recepción

Envío desde Raspberry, recepción desde Arduino

Para hacer las primeras pruebas y comprobar el correcto funcionamiento de la interfaz que acabamos de

configurar, hemos utilizado unas librerías específicas para CAN desarrolladas en C y compatibles con

Linux, que contienen funciones básicas para la utilización y el testeo del protocolo CAN, tales como en-

viar tramas, generar tráfico CAN aleatorio, o recibir, mostrar y filtrar tramas CAN. La librería utilizada


es can-utils[11], que implementa la librería SocketCAN nativa de Linux.

Una vez descargada, compilamos el fichero cansend.c mediante el comando:

gcc -o cansend cansend.c

Lo ejecutamos con el siguiente comando:

./cansend can0 7DF#0201050000000000

Si la interfaz está correctamente configurada, se habrá enviado al bus CAN, a través de la interfaz

can0 una trama con ID 7DF y como campo de datos, 0201050000000000, correspondientes al máximo

de 8 Bytes de campo de datos permitido por el formato de las tramas CAN.

Para verificar el funcionamiento de esta última prueba, primero se conectó la placa Raspberry con

el módulo CAN, al bus CAN del circuito Arduino, que ya teníamos comprobado que funcionaba co-

rrectamente. Para ello, conectamos los pines CAN_H y CAN_L de el módulo PiCAN2 CAN-Bus Board

de Raspberry, a los pines CAN_H y CAN_L del microcontrolador MCP2551 del circuito de Arduino,

con la correspondiente resistencia de 120 Ω. Tras esto, se comprobó el funcionamiento de la interfaz,

tanto enviando tramas desde las Raspberry para ser recibidas por Arduino, como enviando tramas desde

Arduino para ser recibidas por la Raspberry.

Para el envío de tramas, se ha utilizado el comando cansend especificado mas arriba, y para la parte

de Arduino, se ha empleado el programa de recepción de tramas especificado en el apartado 3.1.4.

FIGURA 3.13: Envío de tramas CAN desde Raspberry a Arduino


Envío desde Arduino, recepción desde Raspberry

Para la recepción de tramas, se ha empleado otro programa de la librería can-utils, el programa candump,

cuyo funcionamiento es similar, aunque de forma mas simplificada, a Wireshark. Recibe las tramas CAN

del bus y las muestra en tiempo real. Para compilar este programa ejecutamos:

gcc -o candump candump.c

Y finalmente, para ejecutarlo:

./candump can0

Para la parte de Arduino, se ha empleado el programa de envío de tramas CAN especificado en el

apartado 3.1.4, que imprime constantemente todas las tramas CAN recibidas, actuando de forma similar

al programa candump utilizado antes.

FIGURA 3.14: Envío de tramas CAN desde Arduino a Raspberry

Envío y recepción entre Raspberrys

El último paso para dar como terminada y probada la configuración del módulo CAN y del bus, es

probar la comunicación final entre dos Raspberry y sus respectivos módulos PiCAN2 CAN-Bus Board.

Para ello, se conectan los pines CAN_H y CAN_L de los respectivos módulos PiCAN2 CAN-Bus Board


de las Raspberry, con la correspondiente resistencia de 120 Ω necesaria para el bus.

Para el testeo, se emplean los mismos programas utilizados antes, cansend y candump, empleando

una Raspberry como emisora de tramas CAN y otra como receptora de tramas.

FIGURA 3.15: Envío de tramas entre dos placas Raspberry

Con esta última prueba, podemos determinar que la interfaz CAN y el módulo instalado funcionan

correctamente y son totalmente operativos.

Como última comprobación, se probó el tamaño del buffer designado en la interfaz que acabamos

de crear. Esto se puede ver en el campo txqueuelen al ejecutar el comando ifconfig. El buffer máximo

de mensajes configurado en la Raspberry por defecto es de 10, eso lo podemos probar sin conectar la

Raspberry al bus CAN, y enviando mas de 10 mensajes, al undécimo mensaje, da el error: “write: No

buffer space available ”y ejecutando el comando ifconfig podemos ver que el valor del campo txqueuelen

es 10 (véase figura 3.12). El tamaño del buffer de recepción de tramas CAN puede modificarse con el

comando:

ip link set can0 txqueuelen <size>

Esto también sirve para probar cuando el bus está en modo error-activo (véase figura 2.5) o entra

en modo error-pasivo cuando se producen varios intentos fallidos de transmisión de tramas, incluso

en modo Bus Off. Estos valores y otros parámetros del protocolo interesantes se pueden ver con los

comandos:

ip -details -statistics link show can0

cat /sys/bus/spi/drivers/mcp251x/spi0.0/net/can0/statistics/*


3.2.2 Librerías CAN desarrolladas

Con el objetivo de simplificar la tarea de desarrollo de proyectos empleando el protocolo CAN, se han

desarrollado unas librerías específicas para la configuración, recepción y envío de tramas a través de un

bus CAN, así como del formateo y parametrización necesario de los datos y opciones a enviar, que en

numerosos casos, conllevan mas dificultad de la originalmente prevista debido a las restricciones de los

lenguajes.

Las librerías se han desarrollado en el lenguaje de programación C, ya que es el lenguaje soportado

por el sistema operativo Linux para la creación de sockets específicos CAN. Además, se ha desarrollado

otra librería en el lenguaje ADA, que actúa como capa de transición entre los dos lenguajes, empleando

por debajo las funciones de la librería en C.

Esta librería de adaptación de lenguajes ha sido desarrollada debido a que, al ser uno de los puntos

fuertes del protocolo CAN su utilización para sistemas y proyectos de tiempo real, hacerla compatible

con el lenguaje de programación ADA era algo básico para aprovechar todos sus beneficios, ya que

ADA es uno de los lenguajes de programación mas recomendables y utilizados para este tipo sistemas y

requisitos.

3.2.2.1 Librería en C canLib.c

A pesar de denominar a este desarrollo en C como librería, lo que realmente se obtiene de su compilación

es un fichero .h o .o, para posteriormente ser utilizado por otros programas, a pesar de no haber sido

compilado con las condiciones específicas para convertirlo en una librería.

Como base para la construcción de la librería en C, se ha empleado la librería nativa de Linux para

el tratamiento de sockets específicos CAN, SocketCAN, que provee de las funciones y parámetros ne-

cesarios para la creación y conexión de sockets CAN. La intención al desarrollar esta librería ha sido

hacerla lo suficientemente genérica para que pueda ser utilizada por muchos tipos diversos de aplicacio-

nes, y a la vez sencilla para que la curva de aprendizaje y coste de implementación sea el mínimo posible.

En cuanto al funcionamiento de la librería, el principio básico es que al recibirse una trama, ésta se

almacena en un array de once posiciones, al que la librería tiene acceso global. La trama CAN recibida

se almacena en este array, con un formato específico para que su utilización sea mas sencilla e intuitiva,

ya que el tratamiento y conversión de los datos en crudo recibidos por las tramas es mas complejo de lo


que a priori puede parecer.

El formato que se le ha dado al array, en representación del frame CAN recibido es:

CAN FRAME CUSTOM FORMAT (can_data array)

=======================================================

| Read result | Message ID | Data size | Data (0 - 7) |

=======================================================

Read result -> Returns the number of bytes read, if the value is -1 or 0,

means that there is not more data to read from the socket.

Message ID -> The ID of the can node who sent the message

Data Size -> The number of bytes of the data field

Data -> Contains the data read from the socket, stored as one byte

per array position, in decimal format (from 0 to 255). The

number of data positions must match with the field "Data Size".

Tal y como está explicado, el primer valor del array representa el resultado devuelto por la operación

de lectura, en caso de lectura satisfactoria, devuelve el número de bytes leídos, en caso de error, el valor

devuelto es -1. El segundo campo del array, se compone de un valor decimal, que corresponde con el

número de identificador del nodo CAN que envió el mensaje. El tercer valor, similar al primer valor, se

corresponde con el campo DLC de la trama CAN e indica, en decimal, el número de Bytes que contiene

la misma, y por lo tanto, el número de campos que contiene posteriormente el array de datos. El último

campo varía desde 0 a 7 posiciones, correspondiendo cada una de ellas a cada byte leído del campo de

datos de la trama CAN, en formato decimal, y ocupando tantas posiciones como el valor Data size del

array indique.

Sobre esa base, se han desarrollado las siguientes funciones:

• canlib_init: Esta función se encarga de crear el socket CAN, asociado a una interfaz CAN decla-

rada al inicio del programa. Inicializa el socket para funcionar con el formato de tramas estándar

y también puede ser configurado para que filtre a partir del número de identificador de las tramas


CAN para recibir un único tipo de tramas (desactivado por defecto).

Como particularidad, inicializa el socket para que sea no bloqueante, es decir, que no se quede

bloqueado al realizar una función de lectura sobre el bus si no hay datos que leer. Esta funcionali-

dad se ha incluido para que se adapte al ejemplo práctico desarrollado, en la librería se ha dejado

indicado las líneas que deberían ser modificadas para cambiar este comportamiento.

Esta función no toma ningún parámetro como entrada y como salida, devuelve 1 si la inicializa-

ción y asociación de socket CAN ha sido satisfactoria, o -1 en caso contrario.

• sendCan: Esta función toma como parámetro de entrada una cadena de caracteres o String, y

devuelve como parámetro de salia un número entero, con valor 1 si el envío de la trama CAN

ha sido satisfactorio, o -1 en caso contrario. Como entrada, admite una cadena de caracteres, de

longitud par para ser codificada posteriormente en formato Byte, y con caracteres comprendidos

dentro del rango hexadecimal para permitir la conversión, es decir, valores desde 0 a F. La cadena

puede contener como máximo 16 caracteres, correspondientes a los 8 Bytes disponibles en las

tramas CAN estándar. Ejemplos:

"112233AABBCC4455" -> CAN frame completo

"1122AA" -> CAN frame parcial

"112" -> ERROR, no es par

"1122WW" -> ERROR, posee caracteres no hexadecimales

Los datos recibidos los convierte en Bytes compatibles con la trama CAN a enviar, y les añade el

identificador de trama ID declarado al inicio del programa, en formato hexadecimal. Si la cadena

de entrada obtenida como parámetro de entrada proviene de otro lenguaje distinto a C, se ha de

tener en cuenta de que debe terminar con el carácter Null para ser correctamente interpretado por

le lenguaje C.

• receiveCan: Esta función no toma ningún parámetro de entrada, y devuelve como salida un valor

entero, resultado de la operación de lectura y que se corresponde con la cantidad de Bytes leídos,

o el valor -1 en caso de que se haya producido un error en la lectura, o de que se haya leído sobre


el socket y este no contenga datos de haber recibido ninguna trama, al no ser bloqueante.

Si como resultado de la operación de lectura, se han leído datos, estos son almacenados en el

array can_data respetando el formato de tramas definido anteriormente. Una nueva llamada a esta

función, sobreescribirá los datos almacenados en el array por los nuevos datos recibidos.

La posibilidad de hacer estas llamadas de lectura del socket no bloqueantes (o asíncronas), reside

en que las tramas CAN recibidas y no leídas al no haber un socket de lectura en espera de nuevas

tramas, no se pierden, si no que se almacenan en el buffer CAN de recepción de tramas, que a

pesar de ser limitado (y configurable), posee el suficiente margen para una lectura periódica en

buses no demasiado saturados por tramas CAN. Este es un factor importante a tener en cuenta a

la hora de desarrollar un sistema empleando esta librería o este tipo de sockets, y se ha de estudiar

de antemano la velocidad necesaria de lectura de tramas del bus con respecto a la carga máxima

de tramas esperada para evitar que el buffer de recepción se llene, ya que en este caso, las nuevas

tramas recibidas serán automáticamente descartadas.

• pointerCanFrame: Esta pequeña función es la que actúa como puente entre el lenguaje de pro-

gramación C y el lenguaje de programación ADA. No toma ningún valor como parámetro de

entrada, pero como valor de salida, devuelve un puntero a la dirección de memoria del array de

datos can_data, en donde se almacenan las tramas recibidas. Se ha tenido que diseñar de esta

forma, debido a la imposibilidad de intercambiar entre ambos lenguajes cadenas de caracteres de

forma óptima, o arrays de números enteros.

De este modo, la librería de ADA crea un array de enteros propio, con el mismo tamaño que el

array declarado en C, y apunta éste a la misma dirección de memoria del array can_data, por lo

que al efectuar lecturas sobre el mismo, se leerá la misma información que contiene el array de

tramas CAN recibidas desde la librería en C (véase 3.2.2.2).

3.2.2.2 Librería en ADA can.adb

Para compilar programas en ADA en el sistema operativo Raspbian de la Raspberry pi, necesitamos el

compilador de gnat, que no viene instalado por defecto. Para instalarlo ejecutamos:


sudo apt-get install gnat-4.9s

Esta librería de ADA requiere la librería de C canLib.c para su funcionamiento (véase 3.2.2.1). A su

vez, la librería canLib.c también requiere la librería lib.c basada en SocketCAN para su funcionamiento.

Por ello, primero hay que compilar las librerías de C necesarias mediante el siguiente comando:

gcc -c canLib.c

gcc -c lib.c

La salida de este comando genera un fichero con extensión “.o ”que posteriormente podrá ser enla-

zado por nuestro programa en ADA y compilado haciendo uso de el. Tras ésto procedemos a compilar

la librería de ADA. Al ser una librería y carecer de punto de entrada al programa, habrá que escribir

primero un pequeño programa en ADA, que importe esa librería y haga uso de sus funciones. A este

pequeño programa lo llamaremos test.adb. Para compilarlo, deberemos ejecutar el siguiente comando:

gnatmake test.adb -largs canLib.o lib.o

Este comando compila tanto el programa test.adb, como todas las librerías de ADA que éste importa,

incluyendo nuestra librería can.adb. Además, hay que incluirle como parámetro los ficheros “.o ”gene-

rados anteriormente de las librerías de C para que las enlace correctamente en las funciones importadas

en ADA. Una vez ejecutados estos comandos, se generará como salida un archivo ejecutable, de nombre

test, que podrá ser ejecutado sobre nuestra máquina.

Para utilizar desde ADA las funciones aportadas por la librería C, hay que importarlas como funcio-

nes propias de ADA, respetando los nombres de las librerías de C, de este modo:

function Read_Can return Integer;

pragma Import (C, Read_Can, "receiveCan");

La librería desarrollada en ADA actúa como puente de las funciones ofrecidas por la librería de C a

otros programas desarrollados sobre ADA, simplificando la tarea de conversión entre lenguajes. La parte

mas laboriosa de esta tarea de conversión entre lenguajes reside en el intercambio de tipos complejos

de datos entre ambos, especialmente al ser el lenguaje ADA un lenguaje mas restrictivo con los tipos de

datos.

Como se ha comentado en el apartado 3.2.2.1, el funcionamiento básico sobre el que se basa esta

librería ADA, es a través del uso compartido de un array de enteros, desde la librería en C, cada entero


representado el valor de 1 byte. Ésta posee una función que devuelve un puntero a la dirección de me-

moria del array de datos can_data, en donde se almacenan las tramas recibidas. De este modo, la librería

de ADA crea un array de enteros propio, con el mismo tamaño que el array declarado en C, y apunta

éste a la misma dirección de memoria del array can_data, por lo que al efectuar lecturas sobre el mismo,

se leerá la misma información que contiene el array de tramas CAN recibidas desde la librería en C.

En la librería ADA, se recoge la dirección del puntero proporcionada por la librería en C, y se apli-

ca sobre un puntero a array denominado Buffer_Address, del tipo System.Address nativo de ADA. Por

último, se crea un array denominado Buffer, del tipo específico de los enteros del lenguaje C, usando

la librería Interfaces.C nativa de ADA, y como índice para inicializarlo, se emplea el puntero Buf-

fer_Address.

Todo este proceso queda recogido en estas líneas de código:

function PointerCanFrame return System.Address;

pragma Import (C, PointerCanFrame, "pointerCanFrame");

Buffer_Address : constant System.Address := PointerCanFrame;

Buffer : array (1 .. can_frame_size) of Interfaces.C.int;

for Buffer’Address use Buffer_Address;

Finalmente, para utilizar el array obtenido en el lenguaje de programación ADA, es necesario una

conversión de datos del tipo Interfaces.C.int al tipo Integer nativo de ADA. Este proceso lo realiza la

función Parse_can_frame (ver mas adelante).

Las funciones que proporciona la librería de ADA can.adb son las siguientes:

• Init_Can_C: Esta función enlaza directamente con la función de C canlib_init, teniendo el mis-

mo comportamiento que el descrito en su apartado (3.2.2.1). No toma ningún valor de entrada, y

devuelve 1 si la inicialización de la librería ha sido satisfactoria, o -1 en caso contrario.

• Write_Can: Esta función enlaza directamente con la función de C sendCan, teniendo el mismo

comportamiento que el descrito en su apartado (3.2.2.1). Toma como valor de entrada un String,


que debe respetar el formato establecido y descrito, y como salida, devuelve 1 si el envío de la

trama ha sido satisfactoria, o -1 en caso contrario.

Para esta función, hay que tener en cuenta que el String enviado como parámetro de entrada,

debe terminar con el carácter Null, para ello, una vez tengamos construido el String de datos que

queremos enviar, le añadiremos el carácter de la siguiente forma:

Data : String := "11223344" & Character (nul);

• Read_Can: Esta función enlaza directamente con la función de C receiveCan, teniendo el mismo

comportamiento que el descrito en su apartado (3.2.2.1). No toma ningún parámetro como valor

de entrada y, si la recepción ha sido satisfactoria, devuelve el número de número de Bytes que

contiene la trama leída, en caso contrario devuelve -1.

Esta función de lectura no devuelve ningún valor, la trama leída por la función es accesible a través

del array can_frame, al cual se vuelcan los datos leídos y se actualizará de manera automática con

los nuevos datos leídos. Cabe puntualizar que una nueva lectura de datos, sobreescribirá los datos

ya existentes en el array.

• PointerCanFrame: Esta función es la actúa como puente entre los lenguajes C y ADA, transmi-

tiendo el puntero del array de datos de uno, al otro, para que pueda ser usado y copiado en un

array compatible del lenguaje ADA, como se ha explicado anteriormente. Esta función tiene que

ser llamada directamente al declarar un objeto tipo puntero System.Address, no debe ser llamada

como una función estándar de ADA.

• Parse_can_frame: Esta función es la encargada de recorrer el array de recepción de tramas Buffer,

de tipo Interfaces.C.unsigned para convertirlo en el tipo Integer nativo de ADA, y así poder usarlo

con comodidad. El resultado lo almacena en el array can_frame, que es el que debe usarse desde

el lenguaje ADA para el acceso y tratamiento de los datos recibidos del frame. Esta función no

toma ningún parámetro de entrada o de salida.

• IntegerToHexString: Esta función ha sido diseñada para facilitar el tratamiento de datos a la hora

de construir el String de envío de tramas a través de la función Write_Can. Esta función convierte

un número entero en formato decimal, a un String en formato hexadecimal, con la longitud indica-

da en uno de sus parámetros de entrada. Como parámetro de entrada, recoge el número entero que


queremos convertir, y la longitud de salida deseada del String que devuelve, y como parámetro de

salida, ofrece el String construido.

El máximo número entero que podemos enviarle a la función para su conversión, depende del

parámetro de longitud enviado a la misma. Esto se debe a las propias restricciones a la hora de

convertir al formato hexadecimal. La función que contempla eso, siendo StringSize el valor de

longitud de String de salida, y Number, el número a convertir en hexadecimal, tenemos que:

Max number = 16StringSize − 1

También hay que tener en cuenta, que el máximo valor de tamaño del String resultante que acepta

la función, es 7, ya que el número entero que sería necesario para rellenar un String de lon-

gitud 8 en hexadecimal, excedería el tamaño máximo permitido por el tipo Integer en ADA,

4.294.967.296, que contando con el número 0, es 4.294.967.295.

La función convierte el número recibido en formato hexadecimal con la función Put, la cual

devuelve un String con formato #16#NumberInHex. Tras esto, se realiza un Split (partición del

String) empleando como separador el carácter #. De este resultado, se almacena el segundo cam-

po, el valor hexadecimal del número, en un tipo Unbounded_String de ADA, que se comporta

como un String con longitud indeterminada, para así poder saber el tamaño del String obtenido

como resultado y poder adaptarse a los diferentes tamaños de resultados posibles. Por último,

se rellena el Unbounded_String obtenido con ceros hasta coincidir con el tamaño StringSize del

String, obtenido como parámetro de entrada, y se devuelve el resultado en formato String clásico.

• example: Este procedimiento de la librería carece de función práctica, se ha incluido como ejem-

plo del funcionamiento de la misma, y de cada una de las funciones que contiene. Primero, ini-

cializa la librería CAN mediante la función Init_Can_C, crea un String de longitud 4, con el valor

211 en hexadecimal mediante el uso de la función IntegerToHexString, tras esto, prueba la función

Write_Can enviando una trama con contenido de datos 11223344, es decir, de 4 Bytes.

Por último, entra en un bucle infinito de lectura, para probar el funcionamiento de la función

Read_Can. Si la lectura de una trama es exitosa, la copia al array can_array definitivo con el


formato especificado, mediante la función Parse_can_frame, e imprime los valores recibidos por

pantalla. En caso de una lectura errónea, o con el buffer de recepción de tramas vacío, espera

cinco segundos y repite la operación. Esto es debido a que el socket es no bloqueante, para que

no sature la CPU con infinitas lecturas innecesarias. Además, sirve para probar que las tramas

recibidas durante esos cinco segundos en los que está el programa en espera, no se pierde ninguna

trama, si no que son leídas cuando este despierta de nuevo.

3.3 Ejemplo de aplicación CAN - Control de tráfico

Para este ejemplo de aplicación real del protocolo CAN, nos hemos basado en un proyecto anterior ya

desarrollado como trabajo de fin de grado: Solución centralizada para la optimización automática del

flujo de tráfico en una Smart City1.

Este proyecto consistía en un sistema distribuido de tiempo real, pero que empleaba sockets TCP/IP

sobre Ethernet para las comunicaciones. Por ello, ya que el protocolo TCP/IP no ofrece garantías para

sistemas de tiempo real, el proyecto original se ha modificado, adaptado y simplificado para implantar

el protocolo CAN en sus comunicaciones.

3.3.1 Objetivos del proyecto original

El objetivo principal del proyecto es el de desarrollar un sistema que aporte una solución de bajo coste

al problema del tráfico en las ciudades y que sea aplicable en entornos reales, para que éstas puedan

implantarlo en sus programas de Smart City actuales o futuros.

Para ello, el sistema es capaz de reducir el tiempo de espera de los vehículos en su circulación por las

vías en las que está implantado, teniendo conocimiento de las conexiones entre los diferentes nodos, de

la situación del tráfico en en tiempo real, y regulando el funcionamiento de los cruces en consecuencia

para conseguir una circulación lo mas fluida posible y con el menor tiempo de espera global por parte

de los coches en los cruces.

Gracias a la optimización de la circulación del tráfico y del tiempo de espera de los vehículos, las

principales ventajas que se consiguen son las siguientes:


• Reducción del tiempo de circulación de los vehículos por el casco urbano.

• Reducción del consumo de combustible, debido al menor tiempo en funcionamiento de los vehícu-

los.

• Reducción de la contaminación provocada por los gases desprendidos por los vehículos como

consecuencia combinada de los puntos anteriores.

• Atención mas rápida en caso de emergencias.

• Aportar una solución alternativa a la construcción de nuevas carreteras para mejorar la circulación.

3.3.2 Descripción del sistema

Para llevar a cabo este objetivo, la arquitectura diseñada se basa en nodos. Cada nodo será el responsable

de controlar un único cruce de vías y constará de los siguientes elementos (véase 3.16):

• Cuatro semáforos, agrupados en dos pares que funcionarán de forma simultánea, que serán los

responsables de la regulación del tráfico en el cruce mediante el encendido y apagado de los

mismos.

• Ocho sensores de paso. Cada cruce dispone de cuatro vías de doble sentido, que confluyen en el

centro del mismo, cada vía dispondrá de un sensor de paso para controlar el tráfico en esa vía.

• Un elemento de control, comunicación y recolección de datos por nodo. Para ello, se empleará el

Ordenador de Placa Única Raspberry Pi modelo B+, debido a su bajo coste, capacidad de cálculo,

y a los pines de E/S que posee para controlar los otros componentes HW.

Cada nodo es el encargado de recoger la información perteneciente al cruce al que está asignado y

comunicárselo al resto de nodos a través del bus CAN. A su vez se encarga de recibir la información

proveniente del resto de nodos del sistema y modificar los actuadores del cruce en consecuencia. Las

comunicaciones se llevarán a cabo mediante el protocolo CAN, los nodos comunican tanto la situación

del tráfico actual que sale por cada una de sus interfaces. El número de nodos que admite el sistema es

variable y dinámico, esto permite que el sistema pueda crecer según las necesidades del entorno, y así

adaptarse tanto a grandes como a pequeños proyectos, además de aportar tolerancia a fallos en caso de


desconexión de alguno de los nodos.

Cada vez de que se produce un cambio de ciclo de semáforos, en función de los datos recogidos

por los sensores, y los datos de tráfico recibidos por el resto de nodos, se calculan los nuevos tiempos

de apertura y cierre de los semáforos, aplicables al siguiente ciclo, para tratar de mejorar la fluidez del

tráfico de manera dinámica.

Para probar el funcionamiento del sistema y debido a la imposibilidad de probarlo en un entorno

real, por los permisos requeridos y el coste que conlleva, el tráfico del sistema se ha simulado, así como

el comportamiento de los sensores, semáforos y demás elementos de los nodos.

A continuación se incluye un esquema del planteamiento de los cruces para una mejor compren-

sión del mismo.


FIGURA 3.16: Esquema interno de un nodo

Los semáforos se han agrupado por pares, debido a que el control de los semáforos enfrentados es

idéntico (cuando uno está en rojo, el otro también, y viceversa) y pueden ser controlados como si fueran

un único semáforo.

En cuanto a la circulación en el interior del cruce, no se imponen restricciones de giro a los vehículos

de ningún tipo, cada vehículo que salga de una vía al ponerse el semáforo en verde, puede tanto seguir

de frente como girar a derecha o izquierda.

Los sensores de las vías de salida se han situado al comienzo de la vía, y su función es llevar la

cuenta de los vehículos que salen por esa interfaz en dirección a otros cruces, o al exterior del sistema,

en caso de no estar esa interfaz conectada a otro cruce del sistema. Los sensores de las vías de entrada


al cruce se sitúan varios metros antes de la llegada al semáforo, para así poder llevar la cuenta de los

vehículos que llegan al cruce y que quedan esperando en él, y poder seguir contándolos en caso de que

se acumulen varios en un semáforo en rojo.

Uno de los problemas que produce este tipo de topología y el uso de únicamente 8 sensores, es que

es posible obtener el número de vehículos que entran al cruce y que esperan en el, pero no es posible

saber, una vez que el semáforo se pone con luz verde, que número de coches sale del mismo. Por ello,

ese valor se aproxima mediante cálculos matemáticos (véase Solución centralizada para la optimización

automática del flujo de tráfico en una Smart City). La simulación del tráfico se basa en la simulación de

los valores de los sensores con el paso del tráfico, tanto de entrada como de salida.

El proyecto se ha diseñado para trabajar inicialmente con cuatro nodos conectados entre sí, por lo que

a la hora de compilar el programa principal del proyecto, hay que realizar una serie de modificaciones

sobre él, para configurar la topología del proyecto y poder identificar a cada nodo. Hay que realizar las

siguientes configuraciones:

En el programa canLib.c, añadir el identificador del nodo para el que lo vamos a compilar, pudiendo

ir este del número 1 al 4 en formato hexadecimal. Ejemplo para el identificador de primer nodo:

#define CAN_ID 0x001

La librería desarrollada también da la posibilidad de cambiar la interfaz CAN sobre la que queremos

transmitir y recibir, pero no es necesario modificarla. Por último, también tenemos que configurar el

identificador del nodo en el programa ADA main.ads, como en el paso anterior, de la siguiente forma

para el nodo uno:

ID: constant Integer := 1;

Estos identificadores de nodo se emplean a la hora en enviar tramas CAN con identificadores propios,

para conocer el remitente del mensaje y poder identificarlo dentro de la topología ((véase figura 3.17)

diseñada, y así poder conocer como afecta el tráfico saliente de cada una de las interfaces de ese nodo,

con las posibles conexiones que pueda tener con las interfaces del resto de nodos receptores del mensaje.

La topología y conexiones que se han diseñado para esta prueba entre los cuatro nodos, queda refle-

jada en este esquemático:


FIGURA 3.17: Conexiones entre los cuatro nodos

Internamente, para representar estas conexiones dentro del programa ADA de cada uno de los nodos,

se ha construido una matriz que las representa, en función de la interfaz del nodo propio, y el identifica-

dor del nodo con el que está conectado por esa interfaz. Cada fila de la matriz representa las conexiones

de un nodo, por lo que en la matriz están representadas las conexiones de los cuatro nodos posibles de

esta topología.

Las filas de la matriz van del rango 1 al 4, representando así para cada una, los valores de conexiones

para cada uno de los nodos. Los valores de las columnas, van del rango 0 al 3, y representan cada una de


las vías de entrada de vehículos de las que disponen. El valor de cada posición de la matriz, corresponde

al nodo con el que se tiene conexión en esa vía, empleando el 0 como número de identificador inválido,

indicando que no hay conexión.

La representación según este modelo de la topología diseñada en lenguaje ADA es el siguiente:

type interface_conections is array (0..3) of Integer;

type matrix is array (1..4) of interface_conections;

global_conection : constant matrix := ((3, 2, 2, 0),

(4, 1, 0, 1),

(0, 1, 4, 0),

(0, 2, 0, 3));

conections : constant interface_conections := global_conection(ID);

Donde interface_conections es un array de 0 a 3 que representa las vías de entrada de vehículos de

los nodos, y global_conection es un array de 1 a 4 compuesto por objetos de tipo interface_conections.

ID corresponde con el identificador propio de cada nodo, y mediante él, cada nodo dispone de su rela-

ción de conexiones con otros nodos almacenado en el array conections.

Por ejemplo, el nodo con ID = 2, tendría como array de conexiones: (4, 1, 0, 1), representando así

que está conectado con el nodo 4 por la vía 0, con el nodo 1 por las vías 1 y 3, y que no tiene conexión

por la vía 2.

Para la lectura de valores de los sensores, y escritura de valores para los semáforos, el proyecto

emplea la librería bcm2835, en una versión modificada para hacerla compatible con la simulación del

tráfico. La librería original posee funciones para la lectura y escritura sobre los pines de la Raspberry, las

modificaciones que se han realizado, mantienen la misma interfaz que la librería original para hacerla

compatible, pero las lecturas de los valores de los pines se realizan sobre un fichero predeterminado,

en vez de sobre los pines de la Raspberry. El fichero utilizado contiene una simulación del tráfico en

función de las activaciones o las desactivaciones de los pines de los sensores de paso del nodo.


Para la versión CAN de este proyecto, se han utilizado las librerías CAN desarrolladas en el apartado

3.2.2.2, las cuales se apoyan sobre las librerías CAN de C (ver 3.2.2.1). Para compilar este proyecto, se

han de seguir los siguientes comandos:

gcc -c lib.c

gcc -c canLib.c

gcc -c bcm2835_simulated.c

gnatmake init_pi.adb -largs canLib.o lib.o bcm2835_simulated.o

Entrando en detalle en la programación del sistema, y como se ha comentado anteriormente, se ha

seguido una programación con características de tiempo real, basada en tareas de ADA, para garantizar

un correcto y preciso funcionamiento del mismo. En cuanto al control de los semáforos, se ha establecido

un tiempo mínimo de apertura (tiempo en verde) de los semáforos de 10 segundos, y un tiempo máxi-

mo de 60 segundos. El intercambio de información entre las diferentes tareas del programa se realiza

mediante el uso de objetos protegidos, para garantizar la consistencia de los datos debido a su exclusión

mutua, basada en prioridades. Los objetos protegidos siguen el protocolo de techo de prioridad inmedia-

to, por lo que se les asigna la mayor prioridad de todas las tareas que acceden a ellos.

El cuerpo principal del programa está recogido en el fichero main_pi.adb, que contiene todas la

tareas periódicas y procedimientos usados. Dispone de los siguientes elementos:

• ChangeSemaph: Se encarga del cambio de ciclo de los semáforos, esta tarea se ejecuta con un

periodo dependiente del tiempo de los mismos, ejecutándose únicamente en cada cambio de semá-

foros. Posteriormente, y únicamente en el modo de simulación, también se encarga de dar salida

al tráfico que estaba esperando, en función del tiempo de apertura del semáforo. Por último, es

el encargado de calcular los nuevos tiempos de apertura y cierre de semáforos, en función de los

datos actuales de tráfico recogidos a través de los sensores, y de los datos de tráfico provenientes

de los otros nodos con los que está conectado, a través del procedimiento Algorithm. Tras obte-

ner estos tiempos, establece con estos valores su siguiente período de ejecución, y espera hasta

entonces.

• Read_Sensors: Tarea periódica que se encarga de la lectura de los valores de los ocho sensores de

paso del cruce, los cuatro de entrada de vehículos en las vías, y los cuatro de salida. Los sensores


detectan los vehículos, y los valores recibidos se añaden al objeto protegido Object_Traffic, de-

pendiendo de si el vehículo detectado circula por una vía con el semáforo en verde, y tiene el paso

libre, o en rojo, y tiene que añadirse a la cola de vehículos esperando. La lectura se lleva a cabo

cada 100 milisegundos. El valor de los sensores es simulado mediante el uso de la librería en C

bcm2835_simulated.c, los cuales están almacenados en un fichero externo denominado escenario.

• Send_vehicles: Tarea periódica, con un periodo de 200 milisegundos, encargada del envío de los

datos leídos por la función Read_Sensors a través del bus CAN, empleando la librería específica

desarrollada para ADA can.adb (véase 3.2.2.2). Envía los datos de coches salientes por las vías de

la 4 a la 7, codificando los números enteros que representan el número de vehículos, empleando las

funciones que provee la librería. Por último, reinicia los valores enviados del objeto Object_Traffic

a cero de nuevo.

• Read_Data_Can: Tarea periódica, con un periodo de 2 segundos, encargada de la recepción de

los datos recibidos a través del bus CAN. Esta función hace uso de la matriz de configuración

de la topología explicada anteriormente, para asignar o no los valores de tráfico recibido a una

u otra interfaz. Primero, recoge el valor del identificador de la trama recibida, y mira en el array

conections si se tiene alguna conexión con el nodo que ha enviado la trama. En caso afirmativo, se

añade el tráfico correspondiente de la vía de salida del nodo que envió la trama, a la vía de entrada

propia con la que tenemos conexión, en caso contrario, la descarta. El tráfico se añade únicamente

si la vía de entrada por la que recibimos el tráfico tiene el semáforo en rojo, en caso contrario, se

considera que ese tráfico atraviesa el cruce sin acumularse.

• Algorithm: A diferencia del diseño inicial del proyecto, el funcionamiento del algoritmo de cálcu-

lo de los tiempos de semáforo se ha modificado y simplificado. En el proyecto original, se ejecu-

taba sobre un servidor independiente, con unos cálculos mas extensos, pero, para restarle comple-

jidad al diseño y enfocarlo a la demostración del uso del CAN bus en un proyecto, se ha decidido

simplificar e integrar dentro de los nodos, ya que se considera que no es una parte de peso del

tema a tratar en el proyecto actual.

Esta función esporádica, es llamada por la tarea periódica ChangeSemaph. Calcula el total de

tráfico que hay acumulado en los dos pares de semáforos del nodo, y, tomando como referencia

un máximo total de apertura y cierre de las dos parejas de semáforos de 60 segundos, devuelve

como salida unos tiempos de semáforo proporcionales al tráfico en cada par, los cuales suman en


total los 60 segundos de máximo entre los dos. Si algún tiempo de semáforo queda por debajo de

los 10 segundos, lo establece automáticamente a 10 segundos, el mínimo establecido por diseño.

• Object_Traffic: Objeto protegido encargado de almacenar los datos del tráfico del cruce, tanto de

la situación actual, como de vehículos que han salido del cruce. También guarda el estado de los

sensores.

• Sempahore: Este objeto se encarga de guardar los tiempos de apertura de los semáforos, el estado

actual de los mismos y el ciclo en el que se encuentra el sistema.

Para el envío de las tramas CAN, se ha seguido un formato de mensajes sencillo, empleando úni-

camente 4 Bytes del campo de datos de la trama, uno para almacenar los vehículos de cada una de

las cuatro vías de salida de las que dispone cada nodo, siendo el primer Byte de datos correspondien-

te al tráfico saliente de la vía 4, el segundo Byte corresponde a la vía 5 y así sucesivamente hasta la vía 7.

El máximo de coches que salen que se puede enviar en cada trama es de 255, por las propias res-

tricciones del tamaño byte, pero tras varias pruebas se ha comprobado que es un máximo razonable de

número de coches acumulados en cada vía de salida del nodo.

Como se ha comentado anteriormente, las tramas CAN se envían a través del bus y son recibidas por

todos los nodos conectados a él, y ya es labor de los propios nodos el discernir si los mensajes recibidos

les atañen o no, en función de los identificadores de las tramas.

3.3.3 Planificación temporal

Al ser un sistema de tiempo real, hay diversos factores a tener en cuenta para poder estudiar y garantizar

su correcto funcionamiento.

El primero es la prioridad de las tareas. Indica qué tarea dispondrá de la CPU en caso de que dos

tareas quieran ejecutarse de manera simultánea, siendo la de mayor prioridad la que se ejecute primero,

e incluso expulsando de la CPU a tareas con menor prioridad que ya estaban en ejecución. Las tareas

de interrupción son las de mayor prioridad, ya que se consideran de importancia mayor, y tienen que

ser tratadas en el momento en que se producen. En este proyecto no hay ninguna tarea de interrupción.

El siguiente elemento con mayor prioridad son los objetos protegidos. Esto se consigue debido a que al


acceder una tarea al objeto protegido, hereda la prioridad del mismo siguiendo el protocolo de techo de

prioridad.

Por último, para la prioridad de las tareas cíclicas se ha empleado una planificación monótona en

frecuencias (RMS). La prioridad se asigna de manera inversamente proporcional al periodo del mismo,

para evitar que tareas con un periodo menor y que deben ejecutarse mas frecuentemente se vean expul-

sadas por tareas con mas margen temporal de ejecución.

Otro factor crucial para la ejecución del sistema, y que influye de manera directa en el resultado del

mismo son los tiempos del las tareas. Hay diversos parámetros temporales a tener en cuenta a la hora

de diseñar, planificar y evaluar este tipo de sistemas.

• Periodo: Indica cada cuanto tiempo debe ejecutarse la tarea. Suele estar expresado en milisegun-

dos y este parámetro debe respetarse rigurosamente y poder garantizarse.

• Deadline: Tiempo del que dispone la tarea para que, una vez iniciada su ejecución, la finalice

completamente. Como en el caso anterior, también suele estar expresada en milisegundos y debe

respetarse.

• Tiempo de ejecución: Tiempo que tarda en ejecutarse una tarea en el sistema real. Estos tiempos

han de tomarse con el sistema en ejecución. Debido a las variaciones que puede sufrir este valor,

se suelen tomar varias muestras y posteriormente elegir la de mayor valor. Esto se conoce como

Worst Case Execution Time (WCET), el mayor tiempo de ejecución que puede tomar una tarea

en el peor de los casos.

Los valores que se han asignado a las tareas cíclicas de este sistema, y los tiempos de ejecución que

se han obtenido en las pruebas realizadas son:


CUADRO 3.1: Parámetros asignados a las tareas

Tarea Prioridad Periodo (ms) Deadline (ms) Tiempo de ejecución (ms)

Read_Sensor 8 100 100 2.3

Read_Data_Can 7 200 100 5

Send_Vehicles 5 2000 500 3

ChangeSemaph 2 10000 100 2

Objeto Semaphore 8

Objeto Object_traffic 8

Asignar los valores temporales a las tareas, ha tenido cierta dificultad debido a que algunas de ellas

no tienen un periodo fijo estipulado, como la tarea ChangeSemaph. Para subsanar esto, se les ha asig-

nado el periodo mas bajo en el peor de los casos, que en este proyecto es de 10 segundos, el mínimo

tiempo de apertura y cierre de semáforos.

En este caso no es necesario realizar un estudio de planificabilidad distribuido, ya que las tareas de

lectura y escritura en el bus CAN no son bloqueantes y tiene su período fijo establecido, por lo que se

comportan como una tarea periódica normal. Pero en caso de configurar los sockets CAN en la librería

como bloqueantes, sí que sería necesario realizar este estudio de planificabilidad distribuido, ya que se

pueden producir dependencias entre los períodos de tareas en nodos remotos que afecten a la planifica-

bilidad de nuestro propio sistema.

Según estudios [12] , los tiempos medios de transmisión de un bit CAN en el bus, según la velocidad

del mismo (500 Kbps en nuestro caso), es de 2 µs. Al tener las tramas CAN estándar una longitud má-

xima de 108 bits, el tiempo medio de envío de una trama CAN es de 0,216 ms, sin contar con tiempos

de acceso al medio, tratamiento y envío de tramas ni colisiones.


Finalmente, se ha hecho un estudio de la planificabilidad del sistema desarrollado, para garantizar

el correcto funcionamiento del mismo, y el cumplimiento de los periodos y plazos temporales especifi-

cados. Con este estudio, se puede garantizar que la ejecución del sistema es plausible, y a pesar de las

colisiones entre tareas, los parámetros se mantienen dentro de las restricciones.

Para comprobar si un sistema es planificable, se han de calcular los tiempos de respuesta de todas

las tareas periódicas del sistema. El sistema será planificable si los tiempos de respuesta calculados de

todas las tareas son menores que sus Deadlines (o plazos) correspondientes. La fórmula para calcular

los tiempos de respuesta de las tareas, sin contemplar interrupciones, es:

Ri = Ci +Bi +∑

j∈hp(i)dRi

Tje Cj

Siendo:

Ri Tiempo de respuesta de la tarea i

Ci Tiempo de cómputo de la tarea i

Bi Tiempo de bloqueo de la tarea i

Tj Período de la tarea j∑j∈hp(i)

El sumatorio de todas las tareas de mayor prioridad que la tarea i

Las prioridades de los objetos protegidos del sistema se asignan mediante el criterio de techo de prio-

ridad, es decir, los objetos protegidos poseen la mayor de las prioridades de entre todas las tareas que

acceden a él, ya que cuando una tarea hace uso del mismo, hereda su prioridad para evitar ser expulsada

y así impedir la inversión de prioridad. Mediante este proceso, se puede calcular de forma determinista

los tiempos de bloqueo de las tareas, provocados por accesos a recursos compartidos (Bi).

Para calcular el tiempo de bloqueo, hay que considerar los tiempos de acceso a recursos de las tareas

de menor prioridad que la tarea a estudiar, que comparten los mismos recursos que ella. El mayor tiempo

de acceso será el tiempo de bloqueo de la tarea i. La tarea de menor prioridad no sufre bloqueos por

acceso a recursos compartidos.

Accesos de las tareas a recursos compartidos:


Read_Sensor Accede a Semaphore y Object_Traffic

Read_Data_Can Accede a Object_Traffic

Send_Vehicles Accede a Object_Traffic

ChangeSemaph Accede a Semaphore y Object_Traffic

Los tiempos de acceso de las tareas del sistema, es este ejemplo, son menores a 1 ms, pero se han

considerado como 1ms para facilitar los cálculos y considerar casos de ejecución mas desfavorables. Fi-

nalmente, los atributos temporales (en ms) y accesos a recursos compartidos queda de la siguiente forma:

FIGURA 3.18: Atributos temporales y dependencias de las tareas

Por último, procedemos a calcular los tiempos de respuesta de las tareas mediante la fórmula anterior.

Tarea Read_Sensor (RS):

W 0RS = 2,3 Tiempo inicial = Ci

W 1RS = 2,3 + 1 = 3,3 Tiempo inicial mas tiempo de bloqueo por recursos compartidos

W 2RS = 2,3 + 1 = 3,3 En la siguiente ejecución, no incrementa


El tiempo de respuesta de la tarea Read_Sensor es de 3,3ms < 100ms (Di de Read_Sensor) . Es plani-

ficable.

Tarea Read_Data_Can (RDC):

W 0RDC = 5 Tiempo inicial = Ci

W 1RDC = 5 + 1 + d 5

100e2,3 = 8,3 Tiempo inicial mas tiempo de bloqueo mas bloqueo por RS

W 1RDC = 5 + 1 + d 5

100e2,3 = 8,3 En la siguiente ejecución, no incrementa

El tiempo de respuesta de la tarea Read_Data_Can es de 8,3ms < 100ms (Di de Read_Data_Can) . Es

planificable.

Tarea Send_Vehicles (SV):

W 0SV = 3 Tiempo inicial = Ci

W 1SV = 3 + 1 + d 3

100e2,3 + d 3

200e5 = 11,3 Tiempo inicial + bloqueo por recursos + bloqueo por tareas

W 1SV = 3 + 1 + d 3

100e2,3 + d 3

200e5 = 11,3 En la siguiente ejecución, no incrementa

El tiempo de respuesta de la tarea Send_Vehicles es de 11,3ms < 500ms (Di de Send_Vehicles) . Es

planificable.

Tarea ChangeSemaph (CS):

W 0CS = 2 Tiempo inicial = Ci

W 1CS = 2 + 0 + d 2

100e2,3 + d 2

200e5 + d 2

2000e3 = 12,3 Inicial + Recursos + Tareas

W 1CS = 2 + 0 + d 2

100e2,3 + d 2

200e5 + d 2

2000e3 = 12,3 En la siguiente ejecución, no incrementa


El tiempo de respuesta de la tarea ChangeSemaph es de 12,3ms < 100ms (Di de ChangeSemaph) . Es

planificable.

Todas las tareas del sistema son planificables, por lo que el sistema desarrollado se considera pla-

nificable. Por último, y por seguridad, se ha usado la herramienta RTA, un software que proporciona

información sobre los tiempos de las tareas, posibles desvíos en las mismas, prioridades recomendadas,

y por último, si la tarea es planificable o no.

FIGURA 3.19: Estudio de planificabilidad con la herramienta RTA

Capítulo 4

Resultados

4.1 Resultados del ejemplo de aplicación de control de tráfico

La aplicación ha sido compilada y ejecutada físicamente en dos placas Raspberry pi para comprobar su

funcionamiento y la comunicación mediante el protocolo implementado, obteniendo resultados satisfac-

torios.

El sistema se ejecuta de manera correcta y sin errores, respetando los plazos temporales establecidos

y sin fallos en las comunicaciones. Por último, se ha comprobado que todos los requisitos planteados

han quedado cubiertos. Los dos nodos han sido capaces de mantener el control del tráfico sin errores

durante la ejecución del mismo, intercambiando tramas CAN sin que se perdiera ningún paquete en el

bus.

Finalmente, se ha conseguido migrar un proyecto ya existente que no implementaba el protocolo

CAN bus como protocolo de comunicaciones, sin necesidad de un rediseño completo de la arquitectura

del proyecto o comenzarlo desde cero, empleando las librerías, conocimientos y recursos desarrollados

en esta guía.

Para modificar el protocolo de comunicaciones manteniendo el funcionamiento del sistema origi-

nal, dentro de las posibilidades, ha sido necesario modificar el formato de envío de los mensajes y el

tratamiento de los mismos, debido a la diferencia entre el formato y longitud de tramas del protocolo

original TCP/IP con respecto al protocolo CAN. También ha sido necesario suprimir y modificar el ser-

vidor central de datos y control del tráfico que poseía el proyecto inicialmente, e integrar esa lógica en

el interior de los nodos, debido al cambio de paradigma de comunicaciones que supone el empleo de

este protocolo, basado en comunicaciones broadcast, con respecto al anterior, basado originalmente en

56

Capítulo 4. Resultados 57

comunicaciones punto a punto.

4.2 Objetivos logrados

Se ha desarrollado finalmente una guía completa, que detalla el funcionamiento técnico del protocolo

CAN, necesario para entender su posterior implementación y comportamiento, y, como se pretendía al

inicio del proyecto, se han desarrollado ejemplos prácticos del bus CAN en los dos ámbitos principales

que se pretendían, Arduino y Raspberry, para dar soporte al desarrollo de nuevos proyectos sobre estas

dos plataformas tan utilizadas.

En Arduino se ha conseguido implementar un circuito CAN de bajo coste, y se han elaborado los

diseños esquemáticos necesarios para repetir el circuito, ampliarlo o incluso revelarlo sobre una placa

definitiva. Tras las pruebas del circuito, y para su uso en un proyecto definitivo, ya no serían necesarios

los LEDs de pruebas del circuito a la hora de implementarlo. Por último, se ha probado el circuito y su

funcionamiento mediante dos ejemplos de prueba de envío y recepción de tramas de manera satisfacto-

ria, tal y como se vió en el apartado 3.1.4.

En la placa Raspberry, se ha desarrollado el CAN bus sobre una placa comercial de propósito espe-

cífico, activando la interfaz CAN y comprobando el funcionamiento de las comunicaciones, tal y como

se pretendía. Uno de los objetivos propuestos al inicio del proyecto, era el de simplificar al máximo la

tarea de implementación del protocolo, por lo que las librerías de inicialización, transmisión y recepción,

contienen todas las herramientas necesarias para ello, así como para el tratamiento de la información a

la hora de empaquetar y desempaquetar los datos en las tramas.

Por último, y para probar de forma práctica la utilidad y el funcionamiento de todo lo desarrollado

durante la guía, se ha implementado el protocolo en un proyecto ya existente, a modo de demostra-

ción. Se ha conseguido migrar el protocolo de comunicación al protocolo CAN empleando las librerías

desarrolladas, con un esfuerzo mucho menor al que habría sido necesario en caso de implementar el

protocolo desde cero, o incluso de diseñar el proyecto de cero enfocado a CAN.


4.3 Problemas encontrados

• Uno de los problemas iniciales encontrados en el proyecto en el momento de la implementación

del protocolo CAN sobre la Raspberry, fue la imposibilidad de leer tramas CAN mediante inte-

rrupciones. El protocolo y la placa CAN utilizadas, están pensadas para que, cuando se reciba una

trama CAN, la placa PiCAN2 CAN-Bus Board emite una señal de interrupción a la placa Rasp-

berry, y ésta, al recibirla, leer del buffer de recepción para evitar lecturas innecesarias del buffer si

no se han recibido tramas.

El problema reside en que la librería utilizada por el proyecto, la bcm2835, no da soporte pa-

ra interrupciones reales en la lectura de los pines de la Raspberry, la lectura de los mismos y el

funcionamiento de las interrupciones las simula mediante polling, o lectura constante del pin en

busca de cambios en su estado.

Es por esto que en el ejemplo del proyecto de control de tráfico, se ha llevado a cabo la lectura del

CAN bus mediante una tarea periódica, para así poder tener el control de los plazos de ejecución

de las tareas, y poder realizar la planificabilidad del sistema, en vez de tener una tarea de periodo

y prioridad desconocidos leyendo los pines de la Raspberry, a cambio de no poder realizar las

lecturas por interrupciones y tener que usar el buffer de almacenamiento de tramas de la placa

PiCAN2 CAN-Bus Board.

• Otro de los problemas encontrados durante el diseño y la programación del proyecto, es la di-

ficultad en el tratamiento de los tipos de datos String por parte de ADA, y las dificultades de

compatibilidad a la hora de compartir información entre distintos lenguajes de programación.

• El reducido tamaño de las tramas CAN puede suponer un problema a la hora de enviar mensajes

largos, pudiendo ocasionar la saturación o realentización del bus y una generación de tráfico inne-

cesario, debido a las cabeceras y comprobaciones que lleva cada trama, para una pequeña cantidad

de datos enviados. En el proyecto desarrollado se han diseñado paquetes de mensajes simples para

que fuera posible ubicarlos en una sola trama.

• Dada las velocidades del bus CAN utilizadas, y debido a las características físicas del mismo, la

longitud máxima posible del bus es de 50 metros. Esta restricción aplicada al proyecto diseñado


sobre Raspberry, de conexión de varios cruces en una ciudad, hace inviable su uso sin la utiliza-

ción de algún tipo de repetidor de la señal para poder ampliar la longitud del bus.

A pesar de ser conscientes de esta restricción, y ya que el principal objetivo de la guía era la

demostración de la implantación y el funcionamiento del CAN bus en un proyecto ya existente,

se ha mantenido así, haciendo aquí notable ese defecto.

Capítulo 5

Conclusión y trabajos futuros

5.1 Conclusiones

Con este proyecto, finalmente se ha logrado alcanzar el objetivo inicial planteado de manera exitosa. Se

ha desarrollado una guía completa que abarca todos los aspectos necesarios de este protocolo, para ser

usada en futuros proyectos como documentación de apoyo, además, se han aportado ejemplos prácticos

y diseños de utilidad para dar un soporte técnico a la misma.

Hoy en día, el CAN bus es una de las tecnologías de comunicación mas empleadas e imprescindibles

a la hora de implementar sistemas de tiempo real distribuido, por todos los beneficios que aporta, y de

obligada necesidad a la hora de implementar un sistema de tiempo real estricto.

Su simplicidad y facilidad de uso han dado lugar a que, a pesar del paso de los años desde su desa-

rrollo en 1986, aún siga siendo el protocolo de comunicaciones más utilizado en los ámbitos para los

que fue diseñado, debido a su facilidad de implementación y buenos resultados. A pesar de sus carencias

y ámbitos de mejora del protocolo, debido a su antigüedad, cubre la mayoría de las necesidades de los

sistemas de tiempo real actuales.

El tiempo empleado para la realización del proyecto queda reflejado en la siguiente tabla:

60

Capítulo 5. Conclusión y trabajos futuros 61

CUADRO 5.1: Tiempo empleado en el proyecto

Tarea Tiempo empleado

Planteamiento del proyecto y documentación 20 horas

Estudio del protocolo CAN 110 horas

Elección de componentes, estudio de datasheets y diseño del circuito 30 horas

Desarrollo en Arduino 40 horas

Funcionamiento de placa CAN en Raspberry y pruebas 85 horas

Desarrollo de librerías CAN Raspberry 120 horas

Ejemplo de control del tráfico 150 horas

Memoria 55 horas

Total 610 horas

El coste aproximado del desarrollo de esta guía, incluyendo todo el material utilizado es [13]:


CUADRO 5.2: Coste aproximado

Concepto Coste (C) / Cantidad

Raspberry Pi modelo B+ 35 * 2

Arduino Uno 20 * 2

Placa PiCAN2 CAN-Bus Board 40 * 2

Microcontroladores 4 * 1

Componentes electrónicos 5

Coste de materiales 199 C

Coste de mano de obra de ingeniero 14 C\h

Coste según las horas trabajadas 610 h * 14 C\h = 8.540 C

Coste total 8.739C

5.2 Impactos sociales y ambientales

El uso de la tecnología CAN ha permitido aumentar la seguridad en todos los sectores en los que se em-

plea, tanto en la industria automovilística, la aeronáutica y similares, debido a las garantías que ofrece, la

fiabilidad en sus comunicaciones, y debido a otro factor muy importante en estos ámbitos, su resistencia

a las interferencias electromagnéticas.

Como mejora en cuanto al impacto ambiental, el último ejemplo de CAN bus desarrollado, tiene co-

mo objetivo reducir la circulación de tráfico por el interior de las ciudades, con la consiguiente reducción

de contaminación, debido a los gases emitidos por los vehículos, ayudando así a mejorar la calidad del

aire en las ciudades, ya que la contaminación producida por el tráfico es una de las mayores influencias


negativas en la calidad del mismo. También se reduciría la contaminación acústica.

5.3 Trabajos futuros y mejoras

• Una de las mejoras posibles, en cuanto al protocolo CAN se refiere, es el aumento del tamaño

de tramas, que, a pesar de existir un formato extendido del campo de datos de las tramas, para

algunos proyectos es insuficiente, y, como se ha comentado anteriormente, genera gran cantidad

de tráfico innecesario y saturación en el BUS.

• Mejorar el tratamiento de las interrupciones en la placa Raspberry, para poder leer tramas CAN

únicamente cuando se reciban, y liberar así a la CPU de carga de cómputo innecesaria, además de

no tener que depender del buffer de recepción de tramas.

• Estudiar el uso de posibles repetidores o amplificadores de la señal en el bus CAN, para poder

ampliar el rango de alcance del mismo, y así poder ser aplicado en proyectos mas diversos, en

donde se requieren comunicaciones a distancias mayores que las soportadas por el bus.

• Ampliar las funcionalidades de las librerías desarrolladas para dar soporte a diferentes caracterís-

ticas del protocolo CAN que no han sido contempladas, como el formato extendido de tramas o el

envío de tramas remotas o de sobrecarga.

Glosario

A

Alta integridad

Sistemas cuyo fallo puede tener graves consecuencias, como pérdidas materiales, económicas o

humanas.

Arduino

Arduino es una plataforma de prototipos electrónica de código abierto (open-source) basada en

hardware y software flexibles y fáciles de usar.

B

Baudios

Número de unidades de señal por segundo. Un baudio puede contener varios bits. Aunque a veces

se confunden los baudios con los bits por segundo, son conceptos distintos.

C

Ciclo de semáforos

Período que abarca el encendido y posterior apagado (o viceversa) de cada par de semáforos de

un cruce, hasta el inicio de su siguiente período de encendido y apagado.

D

D-sub

Es un tipo o grupo de conectores que se utilizan, generalmente, para conectar computadoras con

distintos periféricos..

Datasheet

Documento que resume el funcionamiento y otras características de un componente o subsistema

con el suficiente detalle para ser utilizado por un ingeniero de diseño y diseñar el componente en

un sistema.

65

Glosario 66

E

Escalabilidad

Es la propiedad de un sistema, una red o un proceso, que indica su habilidad para reaccionar y

adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida,

o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.

Ethernet

Estándar de redes de área local para computadores con acceso al medio por detección de la onda

portadora y con detección de colisiones.

F

Frame

Bloque fijo de datos transmitidos como una sola entidad. También llamado paquete.

H

Hard Real Time

Sistemas de tiempo real en los que los plazos de respuesta deben respetarse siempre estrictamente

y una sola respuesta tardía a un suceso externo puede tener consecuencias fatales.

M

Microcontrolador

Circuito integrado programable, capaz de ejecutar las órdenes grabadas en su memoria, compuesto

de varios bloques funcionales, los cuales cumplen una tarea específica.

Microprocesador

Procesador de muy pequeñas dimensiones en el que todos los elementos están agrupados en un

solo circuito integrado.

Microprocesador

Procesador de muy pequeñas dimensiones en el que todos los elementos están agrupados en un

solo circuito integrado.

Glosario 67

Middleware

Software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, o

paquetes de programas, redes, hardware y/o sistemas operativos.

Modelo OSI

Modelo de referencia para los protocolos de la red de arquitectura en capas.

O

Ordenador de placa única

Es una computadora completa en un sólo circuito. El diseño se centra en un sólo microprocesador

con la RAM, E/S y todas las demás características de un computador funcional en una sola tarjeta

que suele ser de tamaño reducido, y que tiene todo lo que necesita en la placa base.

P

Polling

Operación de consulta constante, generalmente hacia un dispositivo de hardware, para crear una

actividad sincrónica sin el uso de interrupciones, aunque también puede suceder lo mismo para

recursos de software.

R

Raspberry Pi

Computador de placa única de bajo coste desarrollado por la Fundación Raspberry Pi, con el

objetivo de estimular la enseñanza de ciencias de la computación en las escuelas.

S

Sistema de tiempo real

Es un sistema informático que interacciona con su entorno físico y responde a los estímulos del

entorno dentro de un plazo de tiempo determinado. No basta con que las acciones del sistema sean

correctas, sino que, además, tienen que ejecutarse dentro de un intervalo de tiempo determinado.

Socket

Los sockets de Internet constituyen el mecanismo para la entrega de paquetes de datos provenien-

tes de la tarjeta de red a los procesos o hilos apropiados. Un socket queda definido por un par de

Glosario 68

direcciones IP local y remota, un protocolo de transporte y un par de números de puerto local y

remoto.

Soft Real Time

Sistemas de tiempo real en los que se pueden tolerar retrasos ocasionales en la respuesta a un

suceso.

SPI

También llamado Serial Peripheral Interface es un estándar de comunicaciones, usado principal-

mente para la transferencia de información entre circuitos integrados en equipos electrónicos.

Bibliografía

[1] Adrián Martínez Requena y Javier García Martín. «Solución centralizada para la optimización

automática del flujo de tráfico en una Smart City». En: (2016).

[2] Abdenour LABED y Aomar SERIR Zakaria SAHRAOUI. «FIP over Ethernet/IP for Real Ti-

me Distributed Systems Implementation». En: (2010). URL: http://www.iaeng.org/

publication/WCE2010/WCE2010_pp515-520.pdf.

[3] International Organization for Standardization. «Road vehicles – Controller area network (CAN)».

En: (2015). URL: https://www.iso.org/standard/63648.html.

[4] Universitat Politècnica de València. «Qué es CAN y cómo funciona el módulo del microcontrola-

dor dsPIC30F4013». En: (2004). URL: http://server-die.alc.upv.es/asignaturas/

PAEEES/2005-06/A03-A04%20-%20Bus%20CAN.pdf.

[5] Atmel. «Atmel ATmega48A datasheet». En: (2015). URL: http://www.atmel.com/

images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-

88PA-168A-168PA-328-328P_datasheet_Complete.pdf.

[6] Microchip Technology Inc. «MCP2551 High-Speed CAN Transceiver». En: (2010). URL: http:

//ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf.

[7] Microchip Technology Inc. «MCP2515 Stand-Alone CAN Controller With SPI Interface». En:

(2010). URL: http://ww1.microchip.com/downloads/en/DeviceDoc/21801e.

pdf.

[8] Seed Technology Inc. «CAN BUS Shield». En: (2013). URL: https://github.com/

Seeed-Studio/CAN_BUS_Shield.

[9] Universidad de Cantabria. MaRTE OS. URL: http://marte.unican.es/.

[10] David García Villaescusa. «Portado de MaRTE OS a la arquitectura ARM». En: (2014). URL:

http://repositorio.unican.es/xmlui/bitstream/handle/10902/5537/

David%20Garcia%20Villaescusa.pdf?sequence=1&isAllowed=y.

[11] Oliver Hartkopp. Linux-CAN / SocketCAN user space applications. URL: https://github.

com/linux-can/can-utils.

69

http://www.iaeng.org/publication/WCE2010/WCE2010_pp515-520.pdf

http://www.iaeng.org/publication/WCE2010/WCE2010_pp515-520.pdf

https://www.iso.org/standard/63648.html

http://server-die.alc.upv.es/asignaturas/PAEEES/2005-06/A03-A04%20-%20Bus%20CAN.pdf

http://server-die.alc.upv.es/asignaturas/PAEEES/2005-06/A03-A04%20-%20Bus%20CAN.pdf

http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf





http://ww1.microchip.com/downloads/en/DeviceDoc/21801e.pdf

http://ww1.microchip.com/downloads/en/DeviceDoc/21801e.pdf

https://github.com/Seeed-Studio/CAN_BUS_Shield

https://github.com/Seeed-Studio/CAN_BUS_Shield

http://marte.unican.es/

http://repositorio.unican.es/xmlui/bitstream/handle/10902/5537/David%20Garcia%20Villaescusa.pdf?sequence=1&isAllowed=y

http://repositorio.unican.es/xmlui/bitstream/handle/10902/5537/David%20Garcia%20Villaescusa.pdf?sequence=1&isAllowed=y

https://github.com/linux-can/can-utils

https://github.com/linux-can/can-utils

BIBLIOGRAFÍA 70

[12] Jesús Sandoval Gio Carlos Lujan Ramírez Ramón Ariel Vela Xool. «Análisis del tiempo de trans-

misión del CAN dependiendo de la longitud del bus». En: (). URL: http://www.diee.

net/wp-content/uploads/2014/11/13.5-AN%C3%81LISIS-DEL-TIEMPO-

DE- TRANSMISI%C3%93N- DEL- CAN- DEPENDIENDO- DE- LA- LONGITUD- DEL-

BUS..pdf.

[13] Boletín oficial del estado. Tablas salariales para 2013. 2013. URL: http://www.boe.es/

boe/dias/2013/02/27/pdfs/BOE-A-2013-2203.pdf.

http://www.diee.net/wp-content/uploads/2014/11/13.5-AN%C3%81LISIS-DEL-TIEMPO-DE-TRANSMISI%C3%93N-DEL-CAN-DEPENDIENDO-DE-LA-LONGITUD-DEL-BUS..pdf




http://www.boe.es/boe/dias/2013/02/27/pdfs/BOE-A-2013-2203.pdf

http://www.boe.es/boe/dias/2013/02/27/pdfs/BOE-A-2013-2203.pdf

Apéndice A

Librería can.h de Linux

/*

* linux/can.h

*

* Definitions for CAN network layer (socket addr / CAN frame / CAN filter)

*

* Authors: Oliver Hartkopp <[email protected]>

* Urs Thuermann <[email protected]>

* Copyright (c) 2002-2007 Volkswagen Group Electronic Research

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without

* modification, are permitted provided that the following conditions

* are met:

* 1. Redistributions of source code must retain the above copyright

* notice, this list of conditions and the following disclaimer.

* 2. Redistributions in binary form must reproduce the above copyright

* notice, this list of conditions and the following disclaimer in the

* documentation and/or other materials provided with the distribution.

* 3. Neither the name of Volkswagen nor the names of its contributors

* may be used to endorse or promote products derived from this software

* without specific prior written permission.

*

* Alternatively, provided that this notice is retained in full, this

* software may be distributed under the terms of the GNU General

* Public License ("GPL") version 2, in which case the provisions of the

* GPL apply INSTEAD OF those given above.

*

* The provided data structures and external interfaces from this code

71

Apéndice A. Librería can.h de Linux 72

* are not restricted to be used by modules with a GPL compatible license.

*

* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT

* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR

* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT

* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT

* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY

* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE

* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH

* DAMAGE.

*/

#ifndef _UAPI_CAN_H

#define _UAPI_CAN_H

#include <linux/types.h>

#include <linux/socket.h>

/* controller area network (CAN) kernel definitions */

/* special address description flags for the CAN_ID */

#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */

#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */

#define CAN_ERR_FLAG 0x20000000U /* error message frame */

/* valid bits in CAN ID for frame formats */

#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */

#define CAN_EFF_MASK 0x1FFFFFFFU /* extended frame format (EFF) */

#define CAN_ERR_MASK 0x1FFFFFFFU /* omit EFF, RTR, ERR flags */

/*

* Controller Area Network Identifier structure

*


* bit 0-28 : CAN identifier (11/29 bit)

* bit 29 : error message frame flag (0 = data frame, 1 = error message)

* bit 30 : remote transmission request flag (1 = rtr frame)

* bit 31 : frame format flag (0 = standard 11 bit, 1 = extended 29 bit)

*/

typedef __u32 canid_t;

#define CAN_SFF_ID_BITS 11

#define CAN_EFF_ID_BITS 29

/*

* Controller Area Network Error Message Frame Mask structure

*

* bit 0-28 : error class mask (see include/linux/can/error.h)

* bit 29-31 : set to zero

*/

typedef __u32 can_err_mask_t;

/* CAN payload length and DLC definitions according to ISO 11898-1 */

#define CAN_MAX_DLC 8

#define CAN_MAX_DLEN 8

/* CAN FD payload length and DLC definitions according to ISO 11898-7 */

#define CANFD_MAX_DLC 15

#define CANFD_MAX_DLEN 64

/**

* struct can_frame - basic CAN frame structure

* @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t

definition

* @can_dlc: frame payload length in byte (0 .. 8) aka data length code

* N.B. the DLC field from ISO 11898-1 Chapter 8.4.2.3 has a 1:1

* mapping of the ’data length code’ to the real payload length

* @__pad: padding

* @__res0: reserved / padding


* @data: CAN frame payload (up to 8 byte)


*/

struct can_frame

canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */

__u8 can_dlc; /* frame payload length in byte (0 .. CAN_MAX_DLEN) */

__u8 __pad; /* padding */

__u8 __res0; /* reserved / padding */


__u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));

;

/*

* defined bits for canfd_frame.flags

*

* The use of struct canfd_frame implies the Extended Data Length (EDL)

bit to

* be set in the CAN frame bitstream on the wire. The EDL bit switch turns

* the CAN controllers bitstream processor into the CAN FD mode which

creates

* two new options within the CAN FD frame specification:

*

* Bit Rate Switch - to indicate a second bitrate is/was used for the

payload

* Error State Indicator - represents the error state of the transmitting

node

*

* As the CANFD_ESI bit is internally generated by the transmitting CAN

* controller only the CANFD_BRS bit is relevant for real CAN controllers

when

* building a CAN FD frame for transmission. Setting the CANFD_ESI bit can

make

* sense for virtual CAN interfaces to test applications with echoed

frames.

*/

#define CANFD_BRS 0x01 /* bit rate switch (second bitrate for payload

data) */

#define CANFD_ESI 0x02 /* error state indicator of the transmitting node */


/**

* struct canfd_frame - CAN flexible data rate frame structure

* @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t

definition

* @len: frame payload length in byte (0 .. CANFD_MAX_DLEN)

* @flags: additional flags for CAN FD



* @data: CAN FD frame payload (up to CANFD_MAX_DLEN byte)

*/

struct canfd_frame

canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */

__u8 len; /* frame payload length in byte */

__u8 flags; /* additional flags for CAN FD */



__u8 data[CANFD_MAX_DLEN] __attribute__((aligned(8)));

;

#define CAN_MTU (sizeof(struct can_frame))

#define CANFD_MTU (sizeof(struct canfd_frame))

/* particular protocols of the protocol family PF_CAN */

#define CAN_RAW 1 /* RAW sockets */

#define CAN_BCM 2 /* Broadcast Manager */

#define CAN_TP16 3 /* VAG Transport Protocol v1.6 */

#define CAN_TP20 4 /* VAG Transport Protocol v2.0 */

#define CAN_MCNET 5 /* Bosch MCNet */

#define CAN_ISOTP 6 /* ISO 15765-2 Transport Protocol */

#define CAN_NPROTO 7

#define SOL_CAN_BASE 100

/**

* struct sockaddr_can - the sockaddr structure for CAN sockets

* @can_family: address family number AF_CAN.

* @can_ifindex: CAN network interface index.


* @can_addr: protocol specific address information

*/

struct sockaddr_can

__kernel_sa_family_t can_family;

int can_ifindex;

union

/* transport protocol class address information (e.g. ISOTP) */

struct canid_t rx_id, tx_id; tp;

/* reserved for future CAN protocols address information */

can_addr;

;

/**

* struct can_filter - CAN ID based filter in can_register().

* @can_id: relevant bits of CAN ID which are not masked out.

* @can_mask: CAN mask (see description)

*

* Description:

* A filter matches, when

*

* <received_can_id> & mask == can_id & mask

*

* The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can

* filter for error message frames (CAN_ERR_FLAG bit set in mask).

*/

struct can_filter

canid_t can_id;

canid_t can_mask;

;

#define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */

#define CAN_RAW_FILTER_MAX 512 /* maximum number of can_filter set via

setsockopt() */

#endif /* !_UAPI_CAN_H */

Apéndice B

Librería Interfaces.C de ADA

-----------------------------------------------------------------------------

-- --

-- GNAT COMPILER COMPONENTS --

-- --

-- I N T E R F A C E S . C --

-- --

-- S p e c --

-- --

-- $Revision: 1.13 $ --

-- --

-- This specification is adapted from the Ada Reference Manual for use

with --

-- GNAT. In accordance with the copyright of that document, you can freely

--

-- copy and modify this specification, provided that if you redistribute a

--

-- modified version, any changes that you have made are clearly indicated.

--

-- --

------------------------------------------------------------------------------

with Unchecked_Conversion;

package Interfaces.C is

pragma Pure (C);

-- Declaration’s based on C’s <limits.h>

77

Apéndice B. Librería Interfaces.C de ADA 78

CHAR_BIT : constant := 8;

SCHAR_MIN : constant := -128;

SCHAR_MAX : constant := 127;

UCHAR_MAX : constant := 255;

-- Signed and Unsigned Integers. Note that in GNAT, we have ensured that

-- the standard predefined Ada types correspond to the standard C types

type int is new Integer;

type short is new Short_Integer;

type long is new Long_Integer;

type signed_char is range SCHAR_MIN .. SCHAR_MAX;

for signed_char’Size use CHAR_BIT;

type unsigned is mod 2 ** Integer’Size;

type unsigned_short is mod 2 ** Short_Integer’Size;

type unsigned_long is mod 2 ** Long_Integer’Size;

type unsigned_char is mod (UCHAR_MAX + 1);

for unsigned_char’Size use CHAR_BIT;

subtype plain_char is unsigned_char; -- ??? should be parametrized

-- Are parametrizations below valid ???

type ptrdiff_t is

range -(2 ** (Standard’Address_Size - 1)) ..

+(2 ** (Standard’Address_Size - 1) - 1);

type size_t is mod 2 ** Standard’Address_Size;

-- Floating-Point

type C_float is new Float;

type double is new Standard.Long_Float;

type long_double is new Standard.Long_Long_Float;


----------------------------

-- Characters and Strings --

----------------------------

type char is new Character;

nul : constant char := char’First;

function To_C (Item : Character) return char;

function To_Ada (Item : char) return Character;

type char_array is array (size_t range <>) of aliased char;

for char_array’Component_Size use CHAR_BIT;

function Is_Nul_Terminated (Item : in char_array) return Boolean;

function To_C

(Item : in String;

Append_Nul : in Boolean := True)

return char_array;

function To_Ada

(Item : in char_array;

Trim_Nul : in Boolean := True)

return String;

procedure To_C

(Item : in String;

Target : out char_array;

Count : out size_t;

Append_Nul : in Boolean := True);

procedure To_Ada

(Item : in char_array;

Target : out String;

Count : out Natural;


Trim_Nul : in Boolean := True);

------------------------------------

-- Wide Character and Wide String --

------------------------------------

type wchar_t is new Wide_Character;

wide_nul : constant wchar_t := wchar_t’First;

function To_C (Item : in Wide_Character) return wchar_t;

function To_Ada (Item : in wchar_t) return Wide_Character;

type wchar_array is array (size_t range <>) of aliased wchar_t;

function Is_Nul_Terminated (Item : in wchar_array) return Boolean;

function To_C

(Item : in Wide_String;

Append_Nul : in Boolean := True)

return wchar_array;

function To_Ada

(Item : in wchar_array;

Trim_Nul : in Boolean := True)

return Wide_String;

procedure To_C

(Item : in Wide_String;

Target : out wchar_array;

Count : out size_t;

Append_Nul : in Boolean := True);

procedure To_Ada

(Item : in wchar_array;

Target : out Wide_String;

Count : out Natural;

Trim_Nul : in Boolean := True);


Terminator_Error : exception;

private

-- The following instantiations of unchecked conversion are used to

-- provide functions for the renamings which appear below. We can’t

-- use direct instantiations of unchecked conversions for functions

-- like To_Ada, since we would have the wrong formal parameter names.

function Character_To_char is new

Unchecked_Conversion (Character, char);

function char_To_Character is new

Unchecked_Conversion (char, Character);

function wchar_t_To_Wide_Character is new

Unchecked_Conversion (wchar_t, Wide_Character);

function Wide_Character_To_wchar_t is new

Unchecked_Conversion (Wide_Character, wchar_t);

-- The following declarations don’t work, because of a bug in renaming

-- intrinsic functions. For now we have made separate bodies pending

-- resolution of this bug ???.

-- function To_C (Item : Character) return char

-- renames Character_To_char;

-- function To_Ada (Item : char) return Character

-- renames char_To_Character;

-- function To_C (Item : in Wide_Character) return wchar_t

-- renames Wide_Character_To_wchar_t;

-- function To_Ada (Item : in wchar_t) return Wide_Character

-- renames wchar_t_To_Wide_Character;


end Interfaces.C;

Introducción a CAN bus: Descripción, ejemplos y aplicaciones de...

Documents

Transcript of Introducción a CAN bus: Descripción, ejemplos y aplicaciones de...