TFM Adrian Martinez Requena

U NIVERSIDAD P OLITCNICA DE M ADRID
E SCUELA T CNICA S UPERIOR DE I NGENIERA DE

S ISTEMAS I NFORMTICOS
P ROYECTO FIN DE MSTER
Introduccin a CAN bus: Descripcin, ejemplos y

aplicaciones de tiempo real
Autor: Tutor:
Adrin Martnez Requena Javier Garca Martn
Curso acadmico:
2016 - 2017
Departamento de Sistemas Informticos
4 de julio de 2017
I
Los hombres geniales empiezan grandes obras, los hombres trabajadores las terminan.
Leonardo da Vinci
II
III
Abstract
CAN 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 the
reliability 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 techniques
for the implementation, deployment and utilization of this protocol.
With this goal in mind, specific designs, examples and functional applications will be developed and
proposed to make the use of the protocol more simple in other developements, and to ease the load of
investigation wich entails to start with CAN protocol without a previous base, trying to foment its uses
in projets where originaly wasnt planned due to a lack of time or resources.
Key words: CAN bus, Real Time, High integrity, Raspberry, Arduino.
IV
V
Resumen
La tecnologa CAN es un protocolo de comunicaciones ampliamente usado en entornos y sistemas
con requisitos de tiempo real. Debido a sus garantas, es frecuentemente utilizado en el sector de la au-
tomocin o la aeronutica, en donde la fiabilidad en las comunicaciones es de vital importancia para el
funcionamiento de los sistemas.
Con la elaboracin de este trabajo, se pretende aportar una base sobre la que apoyarse a la hora de
desarrollar e implementar proyectos con la tecnologa CAN bus, desarrollando una gua que muestra
diversas soluciones y tcnicas para la implementacin, despliegue y utilizacin de este protocolo.
Con este objetivo en mente, se van a plantear y desarrollar libreras, ejemplos y aplicaciones funcio-
nales concretas para facilitar la utilizacin del protocolo en otros desarrollos, y as aligerar la carga de
investigacin e implementacin que supone comenzar a utilizar el protocolo CAN sin una base previa.
Se trata de fomentar as su utilizacin en proyectos en los que inicialmente no se haba planteado su uso
por falta tiempo o recursos.
Palabras clave: CAN bus, Tiempo real, Alta integridad, Raspberry, Arduino.
VI
VII
Reconocimientos
A mi familia, por animarme a seguir adelante y a mejorar cada da.
A mi tutor, Javier Garca, por su apoyo y su orientacin.
VIII
IX
ndice general
Abstract IV
Resumen VI
Reconocimientos VIII
1 Introduccin 1
1.1 Objetivos del proyecto y motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Otros buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Protocolo CAN 4
2.1 Ventajas del protocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Descripcin del protocolo CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Capa fsica del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Control de acceso al medio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Formato de las tramas CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.1 Tramas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2 Tramas de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Estados de los nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Desarrollo del proyecto 12

3.1 Desarrollo de bajo nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Dispositivos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Circuito diseado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4 Programacin de Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.5 Ejecucin y resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Desarrollo con el mdulo PiCAN2 CAN-Bus Board . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Instalacin y configuracin del mdulo PiCAN2 CAN-Bus Board . . . . . . . . 25
3.2.1.1 Mdulo PiCAN2 CAN-Bus Board . . . . . . . . . . . . . . . . . . . 25
3.2.1.2 Instalacin y configuracin . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1.3 Pruebas de envo y recepcin . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Libreras CAN desarrolladas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2.1 Librera en C canLib.c . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2.2 Librera en ADA can.adb . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Ejemplo de aplicacin CAN - Control de trfico . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Objetivos del proyecto original . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2 Descripcin del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.3 Planificacin temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
X
4 Resultados 56
4.1 Resultados del ejemplo de aplicacin de control de trfico . . . . . . . . . . . . . . . . . 56
4.2 Objetivos logrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Conclusin y trabajos futuros 60

5.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Impactos sociales y ambientales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Trabajos futuros y mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Glosario 65
Bibliografa 69
A Librera can.h de Linux 71
B Librera Interfaces.C de ADA 77
XI
ndice de figuras
1.1 Ejemplo de reduccin de las comunicaciones necesarias . . . . . . . . . . . . . . . . . . 1
2.1 Velocidad de transmisin del CAN bus con respecto a la distancia . . . . . . . . . . . . 5

2.2 Niveles de tensin del CAN bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Formato de las tramas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Formato de las tramas de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Estado de error de los nodos CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Esquemtico de la placa arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Esquemtico del transceptor MCP2551 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Esquemtico del microcontrolador MCP2515 . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Esquemtico del circuito CAN diseado . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Tabla de relacin entre frecuencias y capacidad de los condensadores . . . . . . . . . . . 17
3.6 Conexiones finales entre las placas Arduino . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Trazas del puerto serie de Arduino. Recepcin CAN (encima) y envo de CAN (debajo) . 22
3.8 Diagrama de la Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.9 Esquema de pines de la Raspberry Pi modelo B . . . . . . . . . . . . . . . . . . . . . . 24
3.10 PiCAN2 CAN-Bus Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.11 Esquemtico del fabricante de la placa PiCAN2 CAN-Bus Board . . . . . . . . . . . . . 26
3.12 Interfaz can0 activa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.13 Envo de tramas CAN desde Raspberry a Arduino . . . . . . . . . . . . . . . . . . . . . 29
3.14 Envo de tramas CAN desde Arduino a Raspberry . . . . . . . . . . . . . . . . . . . . . 30
3.15 Envo de tramas entre dos placas Raspberry . . . . . . . . . . . . . . . . . . . . . . . . 31
3.16 Esquema interno de un nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.17 Conexiones entre los cuatro nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.18 Atributos temporales y dependencias de las tareas . . . . . . . . . . . . . . . . . . . . . 53
3.19 Estudio de planificabilidad con la herramienta RTA . . . . . . . . . . . . . . . . . . . . 55
XII
ndice de cuadros
3.1 Parmetros asignados a las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1 Tiempo empleado en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2 Coste aproximado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
XIII
Lista de Abreviaturas
CAN Controller Area Network

MVB Multifunction Vehicle Bus
FIP Factory Implementation Protocol
ISO International Organization for Standardization
ACK ACKnowledgement
EOF End Of File
E/S Entrada / Salida
HW HardWare
ARM Acorn RISC Machine
CPU Central Processing Unit
LED Light-Emitting Diode
TB TeraByte
GB GigaByte
MB MegaByte
B Byte
OSI Open System Interconnection
TDMA Time Division Multiple Access
PWM Pulse Width Modulation
IDE Integrated Development Environment
PDIP Plastic Dual In-line Package
SPI Serial Peripheral Interface
IP Internet Protocol
SW SoftWare
TCP Transmision Control Protocol
UI User Interface
USB Universal Serial Bus
XIV
Lista de Smbolos
T Tiempo s
C Capacidad elctrica F
F Frecuencia Hz
V Voltaje V
R Resistencia
I Intensidad A
M Hz Megahercios
pF Picofaradios
M B/s Megabytes por segundo
KB/s Kilobytes por segundo
h Horas
s Segundos
ms Milisegundos
s Microsegundos
B Bytes
Mb Megabytes
B Bytes
m Metros
Km Kilmetros
XV
Captulo 1
Introduccin
La tecnologa CAN es un protocolo de comunicaciones ampliamente usado en entornos y sistemas con

requisitos de tiempo real, desarrollado por la compaa Robert Bosch GmbH en 1986, surgido por la
necesidad de conectar cada vez ms y ms dispositivos electrnicos en el interior de los coches. Debido
a sus garantas, es frecuentemente utilizado en el sector de la automocin o la aeronutica, en donde la
fiabilidad en las comunicaciones es de vital importancia para el funcionamiento de los sistemas.
La implantacin 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 conexin puto a punto con cada uno de ellos.
F IGURA 1.1: Ejemplo de reduccin de las comunicaciones necesarias
1
Captulo 1. Introduccin 2
1.1 Objetivos del proyecto y motivacin
Con este trabajo, se pretende elaborar una documentacin concisa que sirva para desarrollar proyectos
con la tecnologa CAN bus. Esta documentacin tendr inicialmente forma de gua, describiendo diver-
sas soluciones tcnicas para la implementacin, despliegue y utilizacin de este protocolo.
Con este objetivo en mente, se van a desarrollar libreras, ejemplos y aplicaciones funcionales con-
cretas para facilitar la implementacin de este protocolo en otros proyectos, aportando as herramientas,
documentacin 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 haba planteado su utilizacin.
Los ejemplos desarrollados utilizarn el bus en distintas configuraciones y tendrn distinto grado de
dificultad. Finalmente se presentar un ejemplo de aplicacin de tiempo real, orientada al control del
trfico, que utilizar el bus con restricciones estrictas en el tiempo de respuesta y se desarrollarn los
anlisis 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 investigacin con
respecto a otros protocolos de comunicacin 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, tambin existen otros protocolos diseados para tal fin.
MVB: Siglas de Multifunction Vehicle Bus, es un protocolo principalmente empleado en la in-

dustria ferroviaria para comunicar diversos sistemas crticos dentro del tren. Posee deteccin de
colisiones y garantas temporales y de entrega.
Captulo 1. Introduccin 3
FIP: Siglas de Factory Implementation Protocol, es un protocolo de comunicaciones en tiempo

real poco extendido, que funciona sobre Ethernet, proporcionando garantas de tiempo y de entrega
[2].
A pesar de existir otras tecnologas alternativas al CAN bus, estn mucho menos extendidas que ste
y se localizan principalmente en diversos mbitos industriales especficos. 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.
Captulo 2
Protocolo CAN
2.1 Ventajas del protocolo CAN
Uno de los puntos fuertes de esta tecnologa, y lo que la ha hecho perdurar en el tiempo a pesar de la
aparicin de otros protocolos de comunicacin con mayor velocidad o capaces de transmitir a mayor
distancia, son las garantas de comunicacin que ofrece, las cuales son muy importantes a la hora de
desarrollar sistemas con caractersticas de tiempo real o de alta integridad.
Posee herramientas para la deteccin de errores en la transmisin, as como la capacidad de re-

transmisin automtica de las tramas errneas.
Capacidad de discernir entre errores puntuales en la transmisin, 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.
Priorizacin de mensajes y garanta en los tiempos de latencia en la entrega de los mismos. sta es
una de las caractersticas por las que este protocolo de comunicaciones es ampliamente utilizado
en el mbito de los sistemas de tiempo real.
Garantas en la consistencia de los datos.
Flexibilidad en la configuracin de la red, tanto en nmero de nodos, como en la disposicin de los

mismos, pudiendo aadirse o quitarse nodos de forma dinmica sin afectar al protocolo. Pueden
conectarse hasta 110 nodos a una red CAN.
4
Captulo 2. Protocolo CAN 5
2.2 Descripcin del protocolo CAN
El protocolo CAN est especificado en el estndar ISO 11898[3], el cual contiene diversas normas espe-
cficas 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.
F IGURA 2.1: Velocidad de transmisin del CAN bus con respecto a la distancia
Un mdulo CAN se compone de dos elementos bsicos:
Controlador: Gestiona el montaje de las tramas CAN, comprobacin de errores en la transmisin,

o en otros nodos, as como de la deteccin de colisiones,
Transmisor / Receptor: Tambin llamado transceptor. Este mdulo es el encargado de la codi-

ficacin y decodificacin de los mensajes en el bus, sincronizacin, control de los niveles de la
seal o del control de acceso al medio.
El controlador CAN, as como el transceptor, son mdulos independientes de los nodos, lo que per-
mite que stos no tengan que destinar recursos en la gestin de las comunicaciones, acceso al medio o
colisiones entre otros. A pesar de que algunos microcontroladores poseen mdulos CAN en un nico
encapsulado, internamente son circuitos independientes en la mayora de los casos.
Cualquier dispositivo conectado al bus puede mandar mensajes, y todos los nodos conectados al
mismo lo recibirn. 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 fsica del protocolo
Posee una topologa 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 seales 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 tensin,
o en modo dominante, con una diferencia de tensin entre los cables de al menos 1,5V. Este modo de
comunicacin tiene como objetivo proporcionar una mayor proteccin frente a interferencias electro-
magnticas.
Esta proteccin 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 electromagntica,
a pesar de la variacin seal en los cables, la diferencia de voltaje entre ellos se mantiene constante.
F IGURA 2.2: Niveles de tensin del CAN bus
https://es.wikipedia.org/wiki/Bus_CAN
2.4 Control de acceso al medio
El protocolo CAN tiene otra caracterstica 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 caracters-
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 Mltiple con de-
teccin de portadora, deteccin de colisin ms Resolucin de colisin)
En el bus, los bits dominantes equivalen al nivel lgico "0", y los bits recesivos al valor lgico "1".
Al inicio de las tramas enviadas por los nodos, se encuentra un campo dedicado especficamente al ar-
bitraje, que coincide con el identificador propio del nodo. Antes de transmitir, los nodos deben vigilar
el bus durante un perodo en el que no puede haber actividad en l, tras sto, y cuando dos nodos tratan
de transmitir de forma simultnea, los bits dominantes prevalecen sobre los bits recesivos, por lo que
el nodo que trata de transmitir la trama con bits dominantes (numero de identificacin menor) es capaz
de detectar la colisin con los bits recesivos (numero de identificacin mayor). Para que la deteccin de
colisiones sea eficaz, los nodos deben tener una correcta sincronizacin, manteniendo las frecuencias de
reloj de los controladores CAN dentro de los valores tolerados[4].
El nodo que detecta la colisin, deja de transmitir inmediatamente y espera hasta finalizar la comu-
nicacin 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 propsito especfico
dentro del funcionamiento del protocolo. Las mas importantes son:
Tramas de datos: Tramas utilizadas para el paso de informacin entre nodos, que puede ser
enviada y recibida por uno o varios de ellos.
Tramas de error: Tramas utilizadas cuando algn 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 peticin remota: Tramas utilizadas para solicitar el envo de informacin a otro nodo.
Se enva una trama con el identificador del nodo del que se requiere el envo de informacin, ste
lo recibe y devuelve la informacin 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 informacin. Poseen al inicio un identificador,
que puede ser con el formato estndar de 11 bits o con el formato extendido, de 29 bits.
F IGURA 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 sincronizacin con el resto de
nodos. Posteriormente se encuentra el campo del identificador, que a parte de servir como identificador
del nodo, tambin 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 ms bajo (mayor nmero de bits dominantes
en las primeras posiciones) tiene ms prioridad que una trama con identificador ms alto. En el formato
estndar est compuesta por 11 bits, terminado con un bit adicional empleado para diferenciar entre
tramas de datos (valor 0), o tramas de peticin remota (valor 1).
En el campo de control, los dos bits iniciales estn reservados para un uso futuro, y posteriormente
se encuentran cuatro bits, que definen el tamao del campo de datos de la trama que se encuentra a
continuacin. 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 (Cdigo de redundancia cclica), 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:
F IGURA 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 (vase 2.6), interrumpe inmediatamente la comunicacin, 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 (vase 2.6), rellena el campo del
indicador de error con 6 bits recesivos. Al enviarse bits recesivos, la comunicacin no se ve interrumpida
y no es detectada por ningn otro nodo de la red, nicamente es detectada por el nodo que enva 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 comunicacin.
Todos los nodos detectan errores, en el momento en el que uno de los nodos detecta un error, enva
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 errneo y el emisor lo
retransmite de nuevo. Tras la deteccin de un error, se incrementa el valor de los contadores de errores
de transmisin (TEC) y de errores de recepcin (REC), incluidos en el controlador de comunicaciones
del emisor. Los sucesivos envos 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 comportndose de la siguiente forma:
F IGURA 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.
Captulo 3
Desarrollo del proyecto
El planteamiento del proyecto se ha tratado de orientar para abarcar el mayor nmero 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 intencin del proyecto.
Inicialmente se ha comenzado por un desarrollo a ms bajo nivel, diseando e implementando un

circuito CAN bus sobre una placa de prototipado, capaz de establecer comunicacin 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 libreras en C para su uso.
Finalmente se han empleado estas libreras en un proyecto codificado en el lenguaje de programa-

cin 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 pretenda dar solucin, 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 comunicacin ya implantado por un sistema operativo.
Para ello se ha diseado una implementacin basada en dos chips de la empresa Microchip, acompaada
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
Captulo 3. Desarrollo del proyecto 13
probar el diseo del circuito y que la comunicacin 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 pequea placa que da soporte
electrnico al microcontrolador ATmega328P [5] que lleva incorporado. Dispone adems de 14 pines
digitales de entrada/salida, pudiendo ser empleados 6 de ellos como seales 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. Adems, posee una interfaz USB, que permite la posibilidad de conectarla directamente al
ordenador y programarlo a travs de un entorno de desarollo (IDE) especfico 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.
F IGURA 3.1: Esquemtico de la placa arduino
https://aprendiendoarduino.wordpress.com
3.1.2 Dispositivos utilizados
El peso de la parte electrnica 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 fsica del protocolo CAN,
la gestin de la codificacin de los bits en el medio y el control de los niveles de tensin. Puede
operar con velocidades de hasta 1 M B/s y soporta la conexin de hasta 112 nodos de forma
simultnea a la red.
F IGURA 3.2: Esquemtico del transceptor MCP2551
http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf
Se ha empleado el modelo con encapsulamiento PDIP, ya que la implementacin fsica 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 mdulo MCP2515, y
dos patillas CAN_H (can high) y CAN_L (can low) encargadas de la conexin con el bus CAN,
adems de las patas de alimentacin VSS y VDD.
MCP2515[7]: Este microcontrolador se encarga de la implementacin de la especificacin del

protocolo CAN, capaz de transmitir tanto tramas estndar como tramas extendidas. La comunica-
cin de conexin que ofrece es mediante protocolo serie (Serial Peripheral Interface o SPI).
F IGURA 3.3: Esquemtico 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 implementacin f-

sica del circuito de prueba se ha llevado a cabo sobre una placa de prototipado. Adems de las
entradas mas comunes en los microcontroladores, como pueden ser la entrada de alimentacin
o de tierra (entradas VSS y VDD), requiere adems de la entrada de una seal de reloj externa
(entradas OSC1 y OSC2).
Tambin posee tres entradas especficas para la comunicacin con el exterior mediante SPI (pines
CS, SO, SI y SCK), dos para la comunicacin con el transceptor CAN (pines TXCAN y RXCAN),
una para el RESET del microcontrolador y una salida especfica de interrupciones, que se activa
para notificar la recepcin de una trama CAN (pin INT).
3.1.3 Circuito diseado
Tras la eleccin de los microcontroladores a utilizar, se ha diseado el circuito electrnico necesario

para su funcionamiento, alimentado a 5V y siguiendo las especificaciones del datasheet del fabricante.
Se han comprado los componentes y se ha diseado y probado de la siguiente forma.
F IGURA 3.4: Esquemtico del circuito CAN diseado

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 comunicacin
entre stos. Se les ha aadido tambin 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 conexin.
Se ha desarrollado un circuito de reloj segn la tabla de especificaciones del datasheet, empleando

un reloj de 16 MHz, acompaado de dos condensadores de 22 pF conectados en paralelo.
F IGURA 3.5: Tabla de relacin 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. Tambin se ha aadido 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 sealar de manera visual las interrupciones producidas por la
recepcin de nuevas tramas CAN.
Se ha aadido una resistencia de 120 , necesaria como terminacin 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 operacin del componente. Conectndola de esta
manera, el modo de operacin seleccionado es HIGH-SPEED o alta velocidad.
F IGURA 3.6: Conexiones finales entre las placas Arduino
3.1.4 Programacin de Arduino
Se han desarrollado dos programas de ejemplo de uso y de comprobacin 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 librera CAN_BUS_Shield-master[8], bajo licencia MIT, que aporta las funciones
bsicas para operar con la interfaz y el protocolo CAN, y la librera SPI nativa de Arduino, para la co-
municacin con el microcontrolador. La librera CAN_BUS_Shield-master, al no ser una librera nativa
de Arduino, tiene que ser importada expresamente desde el men del entorno de desarrollo de Arduino.
El cdigo de la placa Arduino que enva 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 funcin Setup() configura el puerto serie a 115200 baudios y enva una traza para comprobar que
funciona correctamente, despus inicializa el protocolo CAN con una frecuencia de 500 KB/s. Final-
mente, enva en bucle una trama CAN predeterminada cada 100 ms.
El cdigo 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 envo de tramas, la funcin Setup() configura el puerto serie a 115200
baudios y enva una traza para comprobar que funciona correctamente, despus inicializa el protocolo
CAN con una frecuencia de 500 KB/s. Como aadido 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 recepcin
de una trama CAN. Cuando esa recepcin 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 Ejecucin y resultados
Se ha probado fsicamente el circuito diseado con todos sus componentes, y se han conectado los dos
mdulos 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 recepcin y envo de tramas CAN con las libreras
necesarias.
Se han reiniciado las placas para arrancar las aplicaciones cargadas y, empleando una herramienta
especfica 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.
F IGURA 3.7: Trazas del puerto serie de Arduino. Recepcin CAN (encima) y envo de
CAN (debajo)
Tras sto, se ha podido comprobar que el circuito funciona correctamente y que todos los LEDS se
comportan segn lo esperado. Tambin, a travs del puerto serie, se ha comprobado que la inicializacin
el protocolo CAN es correcta y que se ha establecido la comunicacin entre las dos placas Arduino,
tanto de recepcin como de envo de tramas, dando as la prueba como satisfactoria.
3.2 Desarrollo con el mdulo PiCAN2 CAN-Bus Board
Como siguiente fase del proyecto, nos hemos centrado en la implementacin del bus CAN en el compu-
tador de placa nica Raspberry Pi. Es una placa del tamao de una tarjeta de crdito con el system-on-a-
chip Broadcom BCM2835, un procesador de ARM ARM1176JZF-S a 700 MHz, el procesador grfico
VideoCore IV y una memoria RAM de 512 MB. Funciona con una alimentacin de 5V, proporcionada
a travs de un conector micro USB. Estas caractersticas nos proporcionan la potencia y funcionalidades
necesarias para implementar el protocolo CAN bus en ella. (vase figura 3.8).
F IGURA 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 desarrollndose y mejorndose con el
tiempo, aadiendo 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 ejecucin de
los ejemplos sobre CAN, adems de ofrecer compatibilidad con el mdulo externo CAN elegido para la
implementacin del protocolo.
La Raspberry Pi modelo B+ posee un total de 40 pines digitales para dar soporte a la conexin de
diversos elementos, tal como se muestra en la figura 3.9.
F IGURA 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 utilizacin 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 Instalacin y configuracin del mdulo PiCAN2 CAN-Bus Board
3.2.1.1 Mdulo PiCAN2 CAN-Bus Board
Para la parte Hardware de control y transmisin del protocolo CAN bus, en este desarrollo sobre Rasp-
berry, se ha decidido emplear una placa ya fabricada especfica para este propsito, 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 fsica como la parte de control y aplicacin de protocolo CAN, tal y
como se comportaba el circuito desarrollado para Arduino, siendo stos totalmente compatibles entre si.
F IGURA 3.10: PiCAN2 CAN-Bus Board
http://skpang.co.uk/catalog/pican2-canbus-board-for-raspberry-pi-23-p-1475.html
Este mdulo soporta velocidades de hasta 1 MB/s, siendo capaz de enviar tramas en formato estn-
dar o en formato extendido. Tambin posee en la placa un resistencia de 120 para poder ser utilizada
como terminacin del bus CAN, para la cual es necesario insertar y soldar dos pines en el conector JP3
(vase figura 3.11) y unirlos para hacer vlida la conexin. El pin de interrupcin para la recepcin 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 conexin directa de los cables CAN_H y CAN_L atornillndolos a los terminales. La conexin
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 mdulo PiCAN2 CAN-Bus Board.
F IGURA 3.11: Esquemtico 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 esquemtico del fabricante de la placa, las bases sobre la que est cons-
truida esta placa y la placa diseada 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 comunicacin serie con la placa Raspberry y el pin GPIO25 para las interrupciones.
3.2.1.2 Instalacin y configuracin
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 instalacin y puesta en funcionamiento, para que la placa Raspberry pueda detectar el mdulo CAN
como una interfaz propia de comunicaciones.
Lo primero que necesitamos, es que el kernel tenga compilado la librera 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 comunicacin
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 travs de:
Advanced Options > SPI > Enable > Ok
Con esta opcin activada, el kernel cargar al inicio el mdulo 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-
cin CAN. Editamos el fichero /boot/config.txt.
sudo nano /boot/config.txt
Y aadimos al final del mismo las siguientes lneas:
dtparam=spi=on
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25
dtoverlay=spi-bcm2835-overlay
Con estas opciones, configuramos al inicio la librera mcp251x, asignando el nombre can0a la
interfaz CAN, establecemos la frecuencia que emplea la placa para la comunicacin, 16 MHz, la cual
debe coincidir con el reloj que se est empleando en la placa del mdulo CAN. Por ltimo se configura
el pin GPIO25 de la placa Raspberry como pin de recepcin 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 comunicacin CAN,
mediante la siguiente instruccin (la interfaz solo se mantiene activa hasta el siguiente reinicio, para
volver a activarla, ejecutar de nuevo esta instruccin):
sudo /sbin/ip link set can0 up type can bitrate 500000
Con este comando, activamos la interfaz can0a una velocidad de 0.5 MB/s. Tras sto, la interfaz
debera ser visible y esta funcionando correctamente, para comprobarlo, ejecutamos el comando:
ifconfig
La interfaz debera aparecer como en la siguiente figura:
F IGURA 3.12: Interfaz can0 activa
3.2.1.3 Pruebas de envo y recepcin
Envo desde Raspberry, recepcin desde Arduino

Para hacer las primeras pruebas y comprobar el correcto funcionamiento de la interfaz que acabamos de
configurar, hemos utilizado unas libreras especficas para CAN desarrolladas en C y compatibles con
Linux, que contienen funciones bsicas para la utilizacin y el testeo del protocolo CAN, tales como en-
viar tramas, generar trfico CAN aleatorio, o recibir, mostrar y filtrar tramas CAN. La librera utilizada
es can-utils[11], que implementa la librera 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 travs de la interfaz
can0 una trama con ID 7DF y como campo de datos, 0201050000000000, correspondientes al mximo
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 mdulo CAN, al bus CAN del circuito Arduino, que ya tenamos comprobado que funcionaba co-
rrectamente. Para ello, conectamos los pines CAN_H y CAN_L de el mdulo 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 envo de tramas, se ha utilizado el comando cansend especificado mas arriba, y para la parte
de Arduino, se ha empleado el programa de recepcin de tramas especificado en el apartado 3.1.4.
F IGURA 3.13: Envo de tramas CAN desde Raspberry a Arduino

Envo desde Arduino, recepcin desde Raspberry

Para la recepcin de tramas, se ha empleado otro programa de la librera 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 envo 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.
F IGURA 3.14: Envo de tramas CAN desde Arduino a Raspberry
Envo y recepcin entre Raspberrys
El ltimo paso para dar como terminada y probada la configuracin del mdulo CAN y del bus, es
probar la comunicacin final entre dos Raspberry y sus respectivos mdulos PiCAN2 CAN-Bus Board.
Para ello, se conectan los pines CAN_H y CAN_L de los respectivos mdulos 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.
F IGURA 3.15: Envo de tramas entre dos placas Raspberry
Con esta ltima prueba, podemos determinar que la interfaz CAN y el mdulo instalado funcionan
correctamente y son totalmente operativos.
Como ltima comprobacin, se prob el tamao 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 mximo
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 undcimo mensaje, da el error: write: No
buffer space available y ejecutando el comando ifconfig podemos ver que el valor del campo txqueuelen
es 10 (vase figura 3.12). El tamao del buffer de recepcin de tramas CAN puede modificarse con el
comando:
ip link set can0 txqueuelen <size>
Esto tambin sirve para probar cuando el bus est en modo error-activo (vase figura 2.5) o entra
en modo error-pasivo cuando se producen varios intentos fallidos de transmisin de tramas, incluso
en modo Bus Off. Estos valores y otros parmetros 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 Libreras CAN desarrolladas
Con el objetivo de simplificar la tarea de desarrollo de proyectos empleando el protocolo CAN, se han
desarrollado unas libreras especficas para la configuracin, recepcin y envo de tramas a travs de un
bus CAN, as como del formateo y parametrizacin 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 libreras se han desarrollado en el lenguaje de programacin C, ya que es el lenguaje soportado

por el sistema operativo Linux para la creacin de sockets especficos CAN. Adems, se ha desarrollado
otra librera en el lenguaje ADA, que acta como capa de transicin entre los dos lenguajes, empleando
por debajo las funciones de la librera en C.
Esta librera de adaptacin de lenguajes ha sido desarrollada debido a que, al ser uno de los puntos
fuertes del protocolo CAN su utilizacin para sistemas y proyectos de tiempo real, hacerla compatible
con el lenguaje de programacin ADA era algo bsico para aprovechar todos sus beneficios, ya que
ADA es uno de los lenguajes de programacin mas recomendables y utilizados para este tipo sistemas y
requisitos.
3.2.2.1 Librera en C canLib.c
A pesar de denominar a este desarrollo en C como librera, lo que realmente se obtiene de su compilacin
es un fichero .h o .o, para posteriormente ser utilizado por otros programas, a pesar de no haber sido
compilado con las condiciones especficas para convertirlo en una librera.
Como base para la construccin de la librera en C, se ha empleado la librera nativa de Linux para
el tratamiento de sockets especficos CAN, SocketCAN, que provee de las funciones y parmetros ne-
cesarios para la creacin y conexin de sockets CAN. La intencin al desarrollar esta librera ha sido
hacerla lo suficientemente genrica 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 implementacin sea el mnimo posible.
En cuanto al funcionamiento de la librera, el principio bsico es que al recibirse una trama, sta se
almacena en un array de once posiciones, al que la librera tiene acceso global. La trama CAN recibida
se almacena en este array, con un formato especfico para que su utilizacin sea mas sencilla e intuitiva,
ya que el tratamiento y conversin 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 representacin 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 operacin
de lectura, en caso de lectura satisfactoria, devuelve el nmero de bytes ledos, en caso de error, el valor
devuelto es -1. El segundo campo del array, se compone de un valor decimal, que corresponde con el
nmero 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 nmero de Bytes que contiene
la misma, y por lo tanto, el nmero de campos que contiene posteriormente el array de datos. El ltimo
campo vara desde 0 a 7 posiciones, correspondiendo cada una de ellas a cada byte ledo 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 funcin 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 estndar
y tambin puede ser configurado para que filtre a partir del nmero 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 funcin de lectura sobre el bus si no hay datos que leer. Esta funcionali-
dad se ha incluido para que se adapte al ejemplo prctico desarrollado, en la librera se ha dejado
indicado las lneas que deberan ser modificadas para cambiar este comportamiento.
Esta funcin no toma ningn parmetro como entrada y como salida, devuelve 1 si la inicializa-
cin y asociacin de socket CAN ha sido satisfactoria, o -1 en caso contrario.
sendCan: Esta funcin toma como parmetro de entrada una cadena de caracteres o String, y
devuelve como parmetro de salia un nmero entero, con valor 1 si el envo 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 conversin, es decir, valores desde 0 a F. La cadena
puede contener como mximo 16 caracteres, correspondientes a los 8 Bytes disponibles en las
tramas CAN estndar. 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 aade el
identificador de trama ID declarado al inicio del programa, en formato hexadecimal. Si la cadena
de entrada obtenida como parmetro de entrada proviene de otro lenguaje distinto a C, se ha de
tener en cuenta de que debe terminar con el carcter Null para ser correctamente interpretado por
le lenguaje C.
receiveCan: Esta funcin no toma ningn parmetro de entrada, y devuelve como salida un valor
entero, resultado de la operacin de lectura y que se corresponde con la cantidad de Bytes ledos,
o el valor -1 en caso de que se haya producido un error en la lectura, o de que se haya ledo sobre
el socket y este no contenga datos de haber recibido ninguna trama, al no ser bloqueante.
Si como resultado de la operacin de lectura, se han ledo datos, estos son almacenados en el
array can_data respetando el formato de tramas definido anteriormente. Una nueva llamada a esta
funcin, 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 asncronas), reside
en que las tramas CAN recibidas y no ledas 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 recepcin de tramas, que a
pesar de ser limitado (y configurable), posee el suficiente margen para una lectura peridica 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 librera 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 mxima
de tramas esperada para evitar que el buffer de recepcin se llene, ya que en este caso, las nuevas
tramas recibidas sern automticamente descartadas.
pointerCanFrame: Esta pequea funcin es la que acta como puente entre el lenguaje de pro-
gramacin C y el lenguaje de programacin ADA. No toma ningn valor como parmetro de
entrada, pero como valor de salida, devuelve un puntero a la direccin de memoria del array de
datos can_data, en donde se almacenan las tramas recibidas. Se ha tenido que disear de esta
forma, debido a la imposibilidad de intercambiar entre ambos lenguajes cadenas de caracteres de
forma ptima, o arrays de nmeros enteros.
De este modo, la librera de ADA crea un array de enteros propio, con el mismo tamao que el
array declarado en C, y apunta ste a la misma direccin de memoria del array can_data, por lo
que al efectuar lecturas sobre el mismo, se leer la misma informacin que contiene el array de
tramas CAN recibidas desde la librera en C (vase 3.2.2.2).
3.2.2.2 Librera 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 librera de ADA requiere la librera de C canLib.c para su funcionamiento (vase 3.2.2.1). A su
vez, la librera canLib.c tambin requiere la librera lib.c basada en SocketCAN para su funcionamiento.
Por ello, primero hay que compilar las libreras de C necesarias mediante el siguiente comando:
gcc -c canLib.c
gcc -c lib.c
La salida de este comando genera un fichero con extensin .o que posteriormente podr ser enla-
zado por nuestro programa en ADA y compilado haciendo uso de el. Tras sto procedemos a compilar
la librera de ADA. Al ser una librera y carecer de punto de entrada al programa, habr que escribir
primero un pequeo programa en ADA, que importe esa librera y haga uso de sus funciones. A este
pequeo 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 libreras de ADA que ste importa,
incluyendo nuestra librera can.adb. Adems, hay que incluirle como parmetro los ficheros .o gene-
rados anteriormente de las libreras 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 mquina.
Para utilizar desde ADA las funciones aportadas por la librera C, hay que importarlas como funcio-
nes propias de ADA, respetando los nombres de las libreras de C, de este modo:
function Read_Can return Integer;

pragma Import (C, Read_Can, "receiveCan");
La librera desarrollada en ADA acta como puente de las funciones ofrecidas por la librera de C a
otros programas desarrollados sobre ADA, simplificando la tarea de conversin entre lenguajes. La parte
mas laboriosa de esta tarea de conversin 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 bsico sobre el que se basa esta
librera ADA, es a travs del uso compartido de un array de enteros, desde la librera en C, cada entero
representado el valor de 1 byte. sta posee una funcin que devuelve un puntero a la direccin de me-
moria del array de datos can_data, en donde se almacenan las tramas recibidas. De este modo, la librera
de ADA crea un array de enteros propio, con el mismo tamao que el array declarado en C, y apunta
ste a la misma direccin de memoria del array can_data, por lo que al efectuar lecturas sobre el mismo,
se leer la misma informacin que contiene el array de tramas CAN recibidas desde la librera en C.
En la librera ADA, se recoge la direccin del puntero proporcionada por la librera 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 especfico de los enteros del lenguaje C, usando
la librera Interfaces.C nativa de ADA, y como ndice para inicializarlo, se emplea el puntero Buf-
fer_Address.
Todo este proceso queda recogido en estas lneas de cdigo:
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 BufferAddress use Buffer_Address;
Finalmente, para utilizar el array obtenido en el lenguaje de programacin ADA, es necesario una
conversin de datos del tipo Interfaces.C.int al tipo Integer nativo de ADA. Este proceso lo realiza la
funcin Parse_can_frame (ver mas adelante).
Las funciones que proporciona la librera de ADA can.adb son las siguientes:
Init_Can_C: Esta funcin enlaza directamente con la funcin de C canlib_init, teniendo el mis-
mo comportamiento que el descrito en su apartado (3.2.2.1). No toma ningn valor de entrada, y
devuelve 1 si la inicializacin de la librera ha sido satisfactoria, o -1 en caso contrario.
Write_Can: Esta funcin enlaza directamente con la funcin 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 envo de la
trama ha sido satisfactoria, o -1 en caso contrario.
Para esta funcin, hay que tener en cuenta que el String enviado como parmetro de entrada,
debe terminar con el carcter Null, para ello, una vez tengamos construido el String de datos que
queremos enviar, le aadiremos el carcter de la siguiente forma:
Data : String := "11223344" & Character (nul);
Read_Can: Esta funcin enlaza directamente con la funcin de C receiveCan, teniendo el mismo
comportamiento que el descrito en su apartado (3.2.2.1). No toma ningn parmetro como valor
de entrada y, si la recepcin ha sido satisfactoria, devuelve el nmero de nmero de Bytes que
contiene la trama leda, en caso contrario devuelve -1.
Esta funcin de lectura no devuelve ningn valor, la trama leda por la funcin es accesible a travs
del array can_frame, al cual se vuelcan los datos ledos y se actualizar de manera automtica con
los nuevos datos ledos. Cabe puntualizar que una nueva lectura de datos, sobreescribir los datos
ya existentes en el array.
PointerCanFrame: Esta funcin es la acta 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 funcin tiene que
ser llamada directamente al declarar un objeto tipo puntero System.Address, no debe ser llamada
como una funcin estndar de ADA.
Parse_can_frame: Esta funcin es la encargada de recorrer el array de recepcin 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 funcin no
toma ningn parmetro de entrada o de salida.
IntegerToHexString: Esta funcin ha sido diseada para facilitar el tratamiento de datos a la hora
de construir el String de envo de tramas a travs de la funcin Write_Can. Esta funcin convierte
un nmero entero en formato decimal, a un String en formato hexadecimal, con la longitud indica-
da en uno de sus parmetros de entrada. Como parmetro de entrada, recoge el nmero entero que
queremos convertir, y la longitud de salida deseada del String que devuelve, y como parmetro de
salida, ofrece el String construido.
El mximo nmero entero que podemos enviarle a la funcin para su conversin, depende del
parmetro de longitud enviado a la misma. Esto se debe a las propias restricciones a la hora de
convertir al formato hexadecimal. La funcin que contempla eso, siendo StringSize el valor de
longitud de String de salida, y Number, el nmero a convertir en hexadecimal, tenemos que:
M ax number = 16StringSize 1
Tambin hay que tener en cuenta, que el mximo valor de tamao del String resultante que acepta
la funcin, es 7, ya que el nmero entero que sera necesario para rellenar un String de lon-
gitud 8 en hexadecimal, excedera el tamao mximo permitido por el tipo Integer en ADA,
4.294.967.296, que contando con el nmero 0, es 4.294.967.295.
La funcin convierte el nmero recibido en formato hexadecimal con la funcin Put, la cual
devuelve un String con formato #16#NumberInHex. Tras esto, se realiza un Split (particin del
String) empleando como separador el carcter #. De este resultado, se almacena el segundo cam-
po, el valor hexadecimal del nmero, en un tipo Unbounded_String de ADA, que se comporta
como un String con longitud indeterminada, para as poder saber el tamao del String obtenido
como resultado y poder adaptarse a los diferentes tamaos de resultados posibles. Por ltimo,
se rellena el Unbounded_String obtenido con ceros hasta coincidir con el tamao StringSize del
String, obtenido como parmetro de entrada, y se devuelve el resultado en formato String clsico.
example: Este procedimiento de la librera carece de funcin prctica, se ha incluido como ejem-
plo del funcionamiento de la misma, y de cada una de las funciones que contiene. Primero, ini-
cializa la librera CAN mediante la funcin Init_Can_C, crea un String de longitud 4, con el valor
211 en hexadecimal mediante el uso de la funcin IntegerToHexString, tras esto, prueba la funcin
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 funcin
Read_Can. Si la lectura de una trama es exitosa, la copia al array can_array definitivo con el
formato especificado, mediante la funcin Parse_can_frame, e imprime los valores recibidos por
pantalla. En caso de una lectura errnea, o con el buffer de recepcin de tramas vaco, espera
cinco segundos y repite la operacin. Esto es debido a que el socket es no bloqueante, para que
no sature la CPU con infinitas lecturas innecesarias. Adems, 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 ledas cuando este despierta de nuevo.
3.3 Ejemplo de aplicacin CAN - Control de trfico
Para este ejemplo de aplicacin real del protocolo CAN, nos hemos basado en un proyecto anterior ya
desarrollado como trabajo de fin de grado: Solucin centralizada para la optimizacin automtica del
flujo de trfico en una Smart City1 .
Este proyecto consista 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 garantas 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 solucin de bajo coste
al problema del trfico 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 vehculos en su circulacin por las
vas en las que est implantado, teniendo conocimiento de las conexiones entre los diferentes nodos, de
la situacin del trfico en en tiempo real, y regulando el funcionamiento de los cruces en consecuencia
para conseguir una circulacin lo mas fluida posible y con el menor tiempo de espera global por parte
de los coches en los cruces.
Gracias a la optimizacin de la circulacin del trfico y del tiempo de espera de los vehculos, las
principales ventajas que se consiguen son las siguientes:
Reduccin del tiempo de circulacin de los vehculos por el casco urbano.
Reduccin del consumo de combustible, debido al menor tiempo en funcionamiento de los vehcu-
los.
Reduccin de la contaminacin provocada por los gases desprendidos por los vehculos como
consecuencia combinada de los puntos anteriores.
Atencin mas rpida en caso de emergencias.
Aportar una solucin alternativa a la construccin de nuevas carreteras para mejorar la circulacin.
3.3.2 Descripcin del sistema
Para llevar a cabo este objetivo, la arquitectura diseada se basa en nodos. Cada nodo ser el responsable
de controlar un nico cruce de vas y constar de los siguientes elementos (vase 3.16):
Cuatro semforos, agrupados en dos pares que funcionarn de forma simultnea, que sern los
responsables de la regulacin del trfico en el cruce mediante el encendido y apagado de los
mismos.
Ocho sensores de paso. Cada cruce dispone de cuatro vas de doble sentido, que confluyen en el
centro del mismo, cada va dispondr de un sensor de paso para controlar el trfico en esa va.
Un elemento de control, comunicacin y recoleccin de datos por nodo. Para ello, se emplear el
Ordenador de Placa nica Raspberry Pi modelo B+, debido a su bajo coste, capacidad de clculo,
y a los pines de E/S que posee para controlar los otros componentes HW.
Cada nodo es el encargado de recoger la informacin perteneciente al cruce al que est asignado y
comunicrselo al resto de nodos a travs del bus CAN. A su vez se encarga de recibir la informacin
proveniente del resto de nodos del sistema y modificar los actuadores del cruce en consecuencia. Las
comunicaciones se llevarn a cabo mediante el protocolo CAN, los nodos comunican tanto la situacin
del trfico actual que sale por cada una de sus interfaces. El nmero de nodos que admite el sistema es
variable y dinmico, esto permite que el sistema pueda crecer segn las necesidades del entorno, y as
adaptarse tanto a grandes como a pequeos proyectos, adems de aportar tolerancia a fallos en caso de
desconexin de alguno de los nodos.
Cada vez de que se produce un cambio de ciclo de semforos, en funcin de los datos recogidos
por los sensores, y los datos de trfico recibidos por el resto de nodos, se calculan los nuevos tiempos
de apertura y cierre de los semforos, aplicables al siguiente ciclo, para tratar de mejorar la fluidez del
trfico de manera dinmica.
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 trfico del sistema se ha simulado, as como
el comportamiento de los sensores, semforos y dems elementos de los nodos.
A continuacin se incluye un esquema del planteamiento de los cruces para una mejor compren-
sin del mismo.
F IGURA 3.16: Esquema interno de un nodo
Los semforos se han agrupado por pares, debido a que el control de los semforos enfrentados es
idntico (cuando uno est en rojo, el otro tambin, y viceversa) y pueden ser controlados como si fueran
un nico semforo.
En cuanto a la circulacin en el interior del cruce, no se imponen restricciones de giro a los vehculos
de ningn tipo, cada vehculo que salga de una va al ponerse el semforo en verde, puede tanto seguir
de frente como girar a derecha o izquierda.
Los sensores de las vas de salida se han situado al comienzo de la va, y su funcin es llevar la
cuenta de los vehculos que salen por esa interfaz en direccin 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 vas de entrada
al cruce se sitan varios metros antes de la llegada al semforo, para as poder llevar la cuenta de los
vehculos que llegan al cruce y que quedan esperando en l, y poder seguir contndolos en caso de que
se acumulen varios en un semforo en rojo.
Uno de los problemas que produce este tipo de topologa y el uso de nicamente 8 sensores, es que
es posible obtener el nmero de vehculos que entran al cruce y que esperan en el, pero no es posible
saber, una vez que el semforo se pone con luz verde, que nmero de coches sale del mismo. Por ello,
ese valor se aproxima mediante clculos matemticos (vase Solucin centralizada para la optimizacin
automtica del flujo de trfico en una Smart City). La simulacin del trfico se basa en la simulacin de
los valores de los sensores con el paso del trfico, tanto de entrada como de salida.
El proyecto se ha diseado 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 topologa del proyecto y poder identificar a cada nodo. Hay que realizar las
siguientes configuraciones:
En el programa canLib.c, aadir el identificador del nodo para el que lo vamos a compilar, pudiendo
ir este del nmero 1 al 4 en formato hexadecimal. Ejemplo para el identificador de primer nodo:
#define CAN_ID 0x001
La librera desarrollada tambin da la posibilidad de cambiar la interfaz CAN sobre la que queremos
transmitir y recibir, pero no es necesario modificarla. Por ltimo, tambin 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 topologa ((vase figura 3.17)
diseada, y as poder conocer como afecta el trfico 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 topologa y conexiones que se han diseado para esta prueba entre los cuatro nodos, queda refle-
jada en este esquemtico:
F IGURA 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 funcin 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 estn representadas las conexiones de los cuatro nodos posibles de
esta topologa.
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 vas de entrada de vehculos de las que disponen. El valor de cada posicin de la matriz, corresponde
al nodo con el que se tiene conexin en esa va, empleando el 0 como nmero de identificador invlido,
indicando que no hay conexin.
La representacin segn este modelo de la topologa diseada 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 vas de entrada de vehculos 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-
cin de conexiones con otros nodos almacenado en el array conections.
Por ejemplo, el nodo con ID = 2, tendra como array de conexiones: (4, 1, 0, 1), representando as
que est conectado con el nodo 4 por la va 0, con el nodo 1 por las vas 1 y 3, y que no tiene conexin
por la va 2.
Para la lectura de valores de los sensores, y escritura de valores para los semforos, el proyecto
emplea la librera bcm2835, en una versin modificada para hacerla compatible con la simulacin del
trfico. La librera 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 librera 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 simulacin del trfico en
funcin de las activaciones o las desactivaciones de los pines de los sensores de paso del nodo.
Para la versin CAN de este proyecto, se han utilizado las libreras CAN desarrolladas en el apartado
3.2.2.2, las cuales se apoyan sobre las libreras 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 programacin del sistema, y como se ha comentado anteriormente, se ha

seguido una programacin con caractersticas de tiempo real, basada en tareas de ADA, para garantizar
un correcto y preciso funcionamiento del mismo. En cuanto al control de los semforos, se ha establecido
un tiempo mnimo de apertura (tiempo en verde) de los semforos de 10 segundos, y un tiempo mxi-
mo de 60 segundos. El intercambio de informacin entre las diferentes tareas del programa se realiza
mediante el uso de objetos protegidos, para garantizar la consistencia de los datos debido a su exclusin
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 peridicas y procedimientos usados. Dispone de los siguientes elementos:
ChangeSemaph: Se encarga del cambio de ciclo de los semforos, esta tarea se ejecuta con un
periodo dependiente del tiempo de los mismos, ejecutndose nicamente en cada cambio de sem-
foros. Posteriormente, y nicamente en el modo de simulacin, tambin se encarga de dar salida
al trfico que estaba esperando, en funcin del tiempo de apertura del semforo. Por ltimo, es
el encargado de calcular los nuevos tiempos de apertura y cierre de semforos, en funcin de los
datos actuales de trfico recogidos a travs de los sensores, y de los datos de trfico provenientes
de los otros nodos con los que est conectado, a travs del procedimiento Algorithm. Tras obte-
ner estos tiempos, establece con estos valores su siguiente perodo de ejecucin, y espera hasta
entonces.
Read_Sensors: Tarea peridica que se encarga de la lectura de los valores de los ocho sensores de
paso del cruce, los cuatro de entrada de vehculos en las vas, y los cuatro de salida. Los sensores
detectan los vehculos, y los valores recibidos se aaden al objeto protegido Object_Traffic, de-
pendiendo de si el vehculo detectado circula por una va con el semforo en verde, y tiene el paso
libre, o en rojo, y tiene que aadirse a la cola de vehculos esperando. La lectura se lleva a cabo
cada 100 milisegundos. El valor de los sensores es simulado mediante el uso de la librera en C
bcm2835_simulated.c, los cuales estn almacenados en un fichero externo denominado escenario.
Send_vehicles: Tarea peridica, con un periodo de 200 milisegundos, encargada del envo de los
datos ledos por la funcin Read_Sensors a travs del bus CAN, empleando la librera especfica
desarrollada para ADA can.adb (vase 3.2.2.2). Enva los datos de coches salientes por las vas de
la 4 a la 7, codificando los nmeros enteros que representan el nmero de vehculos, empleando las
funciones que provee la librera. Por ltimo, reinicia los valores enviados del objeto Object_Traffic
a cero de nuevo.
Read_Data_Can: Tarea peridica, con un periodo de 2 segundos, encargada de la recepcin de

los datos recibidos a travs del bus CAN. Esta funcin hace uso de la matriz de configuracin
de la topologa explicada anteriormente, para asignar o no los valores de trfico 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 conexin con el nodo que ha enviado la trama. En caso afirmativo, se
aade el trfico correspondiente de la va de salida del nodo que envi la trama, a la va de entrada
propia con la que tenemos conexin, en caso contrario, la descarta. El trfico se aade nicamente
si la va de entrada por la que recibimos el trfico tiene el semforo en rojo, en caso contrario, se
considera que ese trfico atraviesa el cruce sin acumularse.
Algorithm: A diferencia del diseo inicial del proyecto, el funcionamiento del algoritmo de clcu-
lo de los tiempos de semforo se ha modificado y simplificado. En el proyecto original, se ejecu-
taba sobre un servidor independiente, con unos clculos mas extensos, pero, para restarle comple-
jidad al diseo y enfocarlo a la demostracin 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 funcin espordica, es llamada por la tarea peridica ChangeSemaph. Calcula el total de
trfico que hay acumulado en los dos pares de semforos del nodo, y, tomando como referencia
un mximo total de apertura y cierre de las dos parejas de semforos de 60 segundos, devuelve
como salida unos tiempos de semforo proporcionales al trfico en cada par, los cuales suman en
total los 60 segundos de mximo entre los dos. Si algn tiempo de semforo queda por debajo de
los 10 segundos, lo establece automticamente a 10 segundos, el mnimo establecido por diseo.
Object_Traffic: Objeto protegido encargado de almacenar los datos del trfico del cruce, tanto de
la situacin actual, como de vehculos que han salido del cruce. Tambin guarda el estado de los
sensores.
Sempahore: Este objeto se encarga de guardar los tiempos de apertura de los semforos, el estado
actual de los mismos y el ciclo en el que se encuentra el sistema.
Para el envo 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 vehculos de cada una de
las cuatro vas de salida de las que dispone cada nodo, siendo el primer Byte de datos correspondien-
te al trfico saliente de la va 4, el segundo Byte corresponde a la va 5 y as sucesivamente hasta la va 7.
El mximo de coches que salen que se puede enviar en cada trama es de 255, por las propias res-
tricciones del tamao byte, pero tras varias pruebas se ha comprobado que es un mximo razonable de
nmero de coches acumulados en cada va de salida del nodo.
Como se ha comentado anteriormente, las tramas CAN se envan a travs 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 ataen o no, en funcin de los identificadores de las tramas.
3.3.3 Planificacin 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 simultnea, 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 ejecucin. Las tareas
de interrupcin 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 interrupcin.
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 cclicas se ha empleado una planificacin montona 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 ejecucin.
Otro factor crucial para la ejecucin del sistema, y que influye de manera directa en el resultado del
mismo son los tiempos del las tareas. Hay diversos parmetros temporales a tener en cuenta a la hora
de disear, planificar y evaluar este tipo de sistemas.
Periodo: Indica cada cuanto tiempo debe ejecutarse la tarea. Suele estar expresado en milisegun-
dos y este parmetro debe respetarse rigurosamente y poder garantizarse.
Deadline: Tiempo del que dispone la tarea para que, una vez iniciada su ejecucin, la finalice
completamente. Como en el caso anterior, tambin suele estar expresada en milisegundos y debe
respetarse.
Tiempo de ejecucin: Tiempo que tarda en ejecutarse una tarea en el sistema real. Estos tiempos
han de tomarse con el sistema en ejecucin. 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 ejecucin que puede tomar una tarea
en el peor de los casos.
Los valores que se han asignado a las tareas cclicas de este sistema, y los tiempos de ejecucin que
se han obtenido en las pruebas realizadas son:
C UADRO 3.1: Parmetros asignados a las tareas
Tarea Prioridad Periodo (ms) Deadline (ms) Tiempo de ejecucin (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 mnimo
tiempo de apertura y cierre de semforos.
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 perodo fijo establecido, por lo que se
comportan como una tarea peridica normal. Pero en caso de configurar los sockets CAN en la librera
como bloqueantes, s que sera necesario realizar este estudio de planificabilidad distribuido, ya que se
pueden producir dependencias entre los perodos de tareas en nodos remotos que afecten a la planifica-
bilidad de nuestro propio sistema.
Segn estudios [12] , los tiempos medios de transmisin de un bit CAN en el bus, segn la velocidad
del mismo (500 Kbps en nuestro caso), es de 2 s. Al tener las tramas CAN estndar una longitud m-
xima de 108 bits, el tiempo medio de envo de una trama CAN es de 0,216 ms, sin contar con tiempos
de acceso al medio, tratamiento y envo 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 ejecucin del sistema es plausible, y a pesar de las
colisiones entre tareas, los parmetros 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 peridicas 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 frmula para calcular
los tiempos de respuesta de las tareas, sin contemplar interrupciones, es:
P Ri
Ri = Ci + Bi + d e Cj
jhp(i) Tj
Siendo:
Ri Tiempo de respuesta de la tarea i

Ci Tiempo de cmputo de la tarea i
Bi Tiempo de bloqueo de la tarea i
Tj Perodo de la tarea j
P
El sumatorio de todas las tareas de mayor prioridad que la tarea i
jhp(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 inversin 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 clculos y considerar casos de ejecucin mas desfavorables. Fi-
nalmente, los atributos temporales (en ms) y accesos a recursos compartidos queda de la siguiente forma:
F IGURA 3.18: Atributos temporales y dependencias de las tareas
Por ltimo, procedemos a calcular los tiempos de respuesta de las tareas mediante la frmula anterior.
Tarea Read_Sensor (RS):
0
WRS = 2,3 Tiempo inicial = Ci
1
WRS = 2,3 + 1 = 3,3 Tiempo inicial mas tiempo de bloqueo por recursos compartidos
2
WRS = 2,3 + 1 = 3,3 En la siguiente ejecucin, 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):
0
WRDC =5 Tiempo inicial = Ci
1 5
WRDC =5+1+d e2,3 = 8,3 Tiempo inicial mas tiempo de bloqueo mas bloqueo por RS
100
1 5
WRDC =5+1+d e2,3 = 8,3 En la siguiente ejecucin, no incrementa
100
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):
0
WSV =3 Tiempo inicial = Ci
1 3 3
WSV =3+1+d e2,3 + d e5 = 11,3 Tiempo inicial + bloqueo por recursos + bloqueo por tareas
100 200
1 3 3
WSV =3+1+d e2,3 + d e5 = 11,3 En la siguiente ejecucin, no incrementa
100 200
El tiempo de respuesta de la tarea Send_Vehicles es de 11,3ms < 500ms (Di de Send_Vehicles) . Es

planificable.
Tarea ChangeSemaph (CS):
0
WCS =2 Tiempo inicial = Ci
1 2 2 2
WCS =2+0+d e2,3 + d e5 + d e3 = 12,3 Inicial + Recursos + Tareas
100 200 2000
1 2 2 2
WCS =2+0+d e2,3 + d e5 + d e3 = 12,3 En la siguiente ejecucin, no incrementa
100 200 2000
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
informacin sobre los tiempos de las tareas, posibles desvos en las mismas, prioridades recomendadas,
y por ltimo, si la tarea es planificable o no.
F IGURA 3.19: Estudio de planificabilidad con la herramienta RTA

Captulo 4
Resultados
4.1 Resultados del ejemplo de aplicacin de control de trfico
La aplicacin ha sido compilada y ejecutada fsicamente en dos placas Raspberry pi para comprobar su
funcionamiento y la comunicacin 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 trfico sin errores
durante la ejecucin del mismo, intercambiando tramas CAN sin que se perdiera ningn 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 rediseo completo de la arquitectura
del proyecto o comenzarlo desde cero, empleando las libreras, conocimientos y recursos desarrollados
en esta gua.
Para modificar el protocolo de comunicaciones manteniendo el funcionamiento del sistema origi-

nal, dentro de las posibilidades, ha sido necesario modificar el formato de envo 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. Tambin ha sido necesario suprimir y modificar el ser-
vidor central de datos y control del trfico que posea el proyecto inicialmente, e integrar esa lgica 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
Captulo 4. Resultados 57
comunicaciones punto a punto.
4.2 Objetivos logrados
Se ha desarrollado finalmente una gua completa, que detalla el funcionamiento tcnico del protocolo
CAN, necesario para entender su posterior implementacin y comportamiento, y, como se pretenda al
inicio del proyecto, se han desarrollado ejemplos prcticos del bus CAN en los dos mbitos principales
que se pretendan, 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
diseos esquemticos 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 seran 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 envo y recepcin 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 propsito espe-
cfico, activando la interfaz CAN y comprobando el funcionamiento de las comunicaciones, tal y como
se pretenda. Uno de los objetivos propuestos al inicio del proyecto, era el de simplificar al mximo la
tarea de implementacin del protocolo, por lo que las libreras de inicializacin, transmisin y recepcin,
contienen todas las herramientas necesarias para ello, as como para el tratamiento de la informacin a
la hora de empaquetar y desempaquetar los datos en las tramas.
Por ltimo, y para probar de forma prctica la utilidad y el funcionamiento de todo lo desarrollado
durante la gua, se ha implementado el protocolo en un proyecto ya existente, a modo de demostra-
cin. Se ha conseguido migrar el protocolo de comunicacin al protocolo CAN empleando las libreras
desarrolladas, con un esfuerzo mucho menor al que habra sido necesario en caso de implementar el
protocolo desde cero, o incluso de disear 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 implementacin

del protocolo CAN sobre la Raspberry, fue la imposibilidad de leer tramas CAN mediante inte-
rrupciones. El protocolo y la placa CAN utilizadas, estn pensadas para que, cuando se reciba una
trama CAN, la placa PiCAN2 CAN-Bus Board emite una seal de interrupcin a la placa Rasp-
berry, y sta, al recibirla, leer del buffer de recepcin para evitar lecturas innecesarias del buffer si
no se han recibido tramas.
El problema reside en que la librera 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 trfico, se ha llevado a cabo la lectura del
CAN bus mediante una tarea peridica, para as poder tener el control de los plazos de ejecucin
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 diseo y la programacin 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 informacin entre distintos lenguajes de programacin.
El reducido tamao de las tramas CAN puede suponer un problema a la hora de enviar mensajes
largos, pudiendo ocasionar la saturacin o realentizacin del bus y una generacin de trfico inne-
cesario, debido a las cabeceras y comprobaciones que lleva cada trama, para una pequea cantidad
de datos enviados. En el proyecto desarrollado se han diseado paquetes de mensajes simples para
que fuera posible ubicarlos en una sola trama.
Dada las velocidades del bus CAN utilizadas, y debido a las caractersticas fsicas del mismo, la
longitud mxima posible del bus es de 50 metros. Esta restriccin aplicada al proyecto diseado
sobre Raspberry, de conexin de varios cruces en una ciudad, hace inviable su uso sin la utiliza-
cin de algn tipo de repetidor de la seal para poder ampliar la longitud del bus.
A pesar de ser conscientes de esta restriccin, y ya que el principal objetivo de la gua era la
demostracin de la implantacin y el funcionamiento del CAN bus en un proyecto ya existente,
se ha mantenido as, haciendo aqu notable ese defecto.
Captulo 5
Conclusin 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 gua completa que abarca todos los aspectos necesarios de este protocolo, para ser
usada en futuros proyectos como documentacin de apoyo, adems, se han aportado ejemplos prcticos
y diseos de utilidad para dar un soporte tcnico a la misma.
Hoy en da, el CAN bus es una de las tecnologas de comunicacin 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 aos desde su desa-
rrollo en 1986, an siga siendo el protocolo de comunicaciones ms utilizado en los mbitos para los
que fue diseado, debido a su facilidad de implementacin y buenos resultados. A pesar de sus carencias
y mbitos de mejora del protocolo, debido a su antigedad, cubre la mayora de las necesidades de los
sistemas de tiempo real actuales.
El tiempo empleado para la realizacin del proyecto queda reflejado en la siguiente tabla:
60
Captulo 5. Conclusin y trabajos futuros 61
C UADRO 5.1: Tiempo empleado en el proyecto
Tarea Tiempo empleado
Planteamiento del proyecto y documentacin 20 horas
Estudio del protocolo CAN 110 horas
Eleccin de componentes, estudio de datasheets y diseo del circuito 30 horas
Desarrollo en Arduino 40 horas
Funcionamiento de placa CAN en Raspberry y pruebas 85 horas
Desarrollo de libreras CAN Raspberry 120 horas
Ejemplo de control del trfico 150 horas
Memoria 55 horas
Total 610 horas
El coste aproximado del desarrollo de esta gua, incluyendo todo el material utilizado es [13]:
C UADRO 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 electrnicos 5
Coste de materiales 199 C
Coste de mano de obra de ingeniero 14 C\h
Coste segn 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 tecnologa CAN ha permitido aumentar la seguridad en todos los sectores en los que se em-
plea, tanto en la industria automovilstica, la aeronutica y similares, debido a las garantas que ofrece, la
fiabilidad en sus comunicaciones, y debido a otro factor muy importante en estos mbitos, su resistencia
a las interferencias electromagnticas.
Como mejora en cuanto al impacto ambiental, el ltimo ejemplo de CAN bus desarrollado, tiene co-
mo objetivo reducir la circulacin de trfico por el interior de las ciudades, con la consiguiente reduccin
de contaminacin, debido a los gases emitidos por los vehculos, ayudando as a mejorar la calidad del
aire en las ciudades, ya que la contaminacin producida por el trfico es una de las mayores influencias
negativas en la calidad del mismo. Tambin se reducira la contaminacin acstica.
5.3 Trabajos futuros y mejoras
Una de las mejoras posibles, en cuanto al protocolo CAN se refiere, es el aumento del tamao
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 trfico innecesario y saturacin 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 cmputo innecesaria, adems de
no tener que depender del buffer de recepcin de tramas.
Estudiar el uso de posibles repetidores o amplificadores de la seal 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 libreras desarrolladas para dar soporte a diferentes caracters-
ticas del protocolo CAN que no han sido contempladas, como el formato extendido de tramas o el
envo de tramas remotas o de sobrecarga.
Glosario
Alta integridad
Sistemas cuyo fallo puede tener graves consecuencias, como prdidas materiales, econmicas o
humanas.
Arduino
Arduino es una plataforma de prototipos electrnica de cdigo abierto (open-source) basada en

hardware y software flexibles y fciles de usar.
Baudios
Nmero de unidades de seal por segundo. Un baudio puede contener varios bits. Aunque a veces
se confunden los baudios con los bits por segundo, son conceptos distintos.
Ciclo de semforos
Perodo que abarca el encendido y posterior apagado (o viceversa) de cada par de semforos de
un cruce, hasta el inicio de su siguiente perodo de encendido y apagado.
D-sub
Es un tipo o grupo de conectores que se utilizan, generalmente, para conectar computadoras con
distintos perifricos..
Datasheet
Documento que resume el funcionamiento y otras caractersticas de un componente o subsistema

con el suficiente detalle para ser utilizado por un ingeniero de diseo y disear el componente en
un sistema.
65
Glosario 66
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 ms grande sin perder calidad en los servicios ofrecidos.
Ethernet
Estndar de redes de rea local para computadores con acceso al medio por deteccin de la onda
portadora y con deteccin de colisiones.
Frame
Bloque fijo de datos transmitidos como una sola entidad. Tambin llamado paquete.
Hard Real Time
Sistemas de tiempo real en los que los plazos de respuesta deben respetarse siempre estrictamente
y una sola respuesta tarda a un suceso externo puede tener consecuencias fatales.
Microcontrolador
Circuito integrado programable, capaz de ejecutar las rdenes grabadas en su memoria, compuesto
de varios bloques funcionales, los cuales cumplen una tarea especfica.
Microprocesador
Procesador de muy pequeas dimensiones en el que todos los elementos estn agrupados en un
solo circuito integrado.
Microprocesador
Procesador de muy pequeas dimensiones en el que todos los elementos estn agrupados en un
solo circuito integrado.
Glosario 67
Middleware
Software que asiste a una aplicacin 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.
Ordenador de placa nica
Es una computadora completa en un slo circuito. El diseo se centra en un slo microprocesador

con la RAM, E/S y todas las dems caractersticas de un computador funcional en una sola tarjeta
que suele ser de tamao reducido, y que tiene todo lo que necesita en la placa base.
Polling
Operacin de consulta constante, generalmente hacia un dispositivo de hardware, para crear una
actividad sincrnica sin el uso de interrupciones, aunque tambin puede suceder lo mismo para
recursos de software.
Raspberry Pi
Computador de placa nica de bajo coste desarrollado por la Fundacin Raspberry Pi, con el
objetivo de estimular la enseanza de ciencias de la computacin en las escuelas.
Sistema de tiempo real
Es un sistema informtico que interacciona con su entorno fsico y responde a los estmulos del
entorno dentro de un plazo de tiempo determinado. No basta con que las acciones del sistema sean
correctas, sino que, adems, 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 nmeros 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
Tambin llamado Serial Peripheral Interface es un estndar de comunicaciones, usado principal-

mente para la transferencia de informacin entre circuitos integrados en equipos electrnicos.
Bibliografa
[1] Adrin Martnez Requena y Javier Garca Martn. Solucin centralizada para la optimizacin
automtica del flujo de trfico 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 Politcnica de Valncia. Qu es CAN y cmo funciona el mdulo 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 Garca 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
BIBLIOGRAFA 70
[12] Jess Sandoval Gio Carlos Lujan Ramrez Ramn Ariel Vela Xool. Anlisis del tiempo de trans-
misin 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] Boletn oficial del estado. Tablas salariales para 2013. 2013. URL : http://www.boe.es/
boe/dias/2013/02/27/pdfs/BOE-A-2013-2203.pdf.
Apndice A
Librera can.h de Linux
/*
* linux/can.h
*
* Definitions for CAN network layer (socket addr / CAN frame / CAN filter)
*
* Authors: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
* Urs Thuermann <urs.thuermann@volkswagen.de>
* 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
Apndice A. Librera 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 */
Apndice B
Librera 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);
-- Declarations based on Cs <limits.h>
77
Apndice B. Librera 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_charSize use CHAR_BIT;
type unsigned is mod 2 ** IntegerSize;

type unsigned_short is mod 2 ** Short_IntegerSize;
type unsigned_long is mod 2 ** Long_IntegerSize;
type unsigned_char is mod (UCHAR_MAX + 1);

for unsigned_charSize use CHAR_BIT;
subtype plain_char is unsigned_char; -- ??? should be parametrized
-- Are parametrizations below valid ???
type ptrdiff_t is
range -(2 ** (StandardAddress_Size - 1)) ..
+(2 ** (StandardAddress_Size - 1) - 1);
type size_t is mod 2 ** StandardAddress_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 := charFirst;
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_arrayComponent_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_tFirst;
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 cant
-- 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 dont 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;

TFM Adrian Martinez Requena

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFM Adrian Martinez Requena

Cargado por

Copyright:

Formatos disponibles

U NIVERSIDAD P OLITCNICA DE M ADRID

E SCUELA T CNICA S UPERIOR DE I NGENIERA DE

P ROYECTO FIN DE MSTER

Introduccin a CAN bus: Descripcin, ejemplos y

Departamento de Sistemas Informticos

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

A mi tutor, Javier Garca, por su apoyo y su orientacin.

3 Desarrollo del proyecto 12

5 Conclusin y trabajos futuros 60

A Librera can.h de Linux 71

B Librera Interfaces.C de ADA 77

1.1 Ejemplo de reduccin de las comunicaciones necesarias . . . . . . . . . . . . . . . . . . 1

2.1 Velocidad de transmisin del CAN bus con respecto a la distancia . . . . . . . . . . . . 5

3.1 Esquemtico de la placa arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Parmetros asignados a las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Tiempo empleado en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

CAN Controller Area Network

La tecnologa CAN es un protocolo de comunicaciones ampliamente usado en entornos y sistemas con

La implantacin de este modelo de comunicaciones supuso un avance en cuanto a la cantidad de

F IGURA 1.1: Ejemplo de reduccin de las comunicaciones necesarias

1.1 Objetivos del proyecto y motivacin

1.2 Otros buses

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

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

2.1 Ventajas del protocolo CAN

Posee herramientas para la deteccin de errores en la transmisin, as como la capacidad de re-

Garantas en la consistencia de los datos.

Flexibilidad en la configuracin de la red, tanto en nmero de nodos, como en la disposicin de los

2.2 Descripcin del protocolo CAN

Un mdulo CAN se compone de dos elementos bsicos:

Controlador: Gestiona el montaje de las tramas CAN, comprobacin de errores en la transmisin,

Transmisor / Receptor: Tambin llamado transceptor. Este mdulo es el encargado de la codi-

2.3 Capa fsica del protocolo

F IGURA 2.2: Niveles de tensin del CAN bus

2.4 Control de acceso al medio

2.5 Formato de las tramas CAN

2.5.1 Tramas de datos

F IGURA 2.3: Formato de las tramas de datos

2.5.2 Tramas de error

F IGURA 2.4: Formato de las tramas de error

2.6 Estados de los nodos

F IGURA 2.5: Estado de error de los nodos CAN

Desarrollo del proyecto

Inicialmente se ha comenzado por un desarrollo a ms bajo nivel, diseando e implementando un

Finalmente se han empleado estas libreras en un proyecto codificado en el lenguaje de programa-

3.1 Desarrollo de bajo nivel

F IGURA 3.1: Esquemtico de la placa arduino

3.1.2 Dispositivos utilizados

F IGURA 3.2: Esquemtico del transceptor MCP2551

MCP2515[7]: Este microcontrolador se encarga de la implementacin de la especificacin del

F IGURA 3.3: Esquemtico del microcontrolador MCP2515

Se ha empleado el modelo con encapsulamiento PDIP de 18 pines, ya que la implementacin f-

3.1.3 Circuito diseado

Tras la eleccin de los microcontroladores a utilizar, se ha diseado el circuito electrnico necesario

F IGURA 3.4: Esquemtico del circuito CAN diseado

Se ha desarrollado un circuito de reloj segn la tabla de especificaciones del datasheet, empleando

F IGURA 3.5: Tabla de relacin entre frecuencias y capacidad de los condensadores

F IGURA 3.6: Conexiones finales entre las placas Arduino

3.1.4 Programacin de Arduino

El cdigo de la placa Arduino que enva las tramas CAN es el siguiente:

// demo: CAN-BUS Shield, send data

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

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