implementación de biblioteca can para sapi

CARRERA DE ESPECIALIZACIÓN ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Implementación de bibliotecaCAN para sAPI

Autor:Ing. Gabriel Gavinowich

Director:Mg. Ing. Eric Pernia (UNQ, FIUBA)

CodirectorEsp. Ing. Franco Bucafusco (FIUBA)

Jurados:Esp. Ing. Sergio De Jesús Meleán (FIUBA)

Esp. Ing. Ernesto Gigliotti (UTN-FRA, FIUBA)Esp Ing Ramiro Alonso(FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires,entre enero de 2018 y abril de 2020.

III

Resumen

La presente memoria describe el desarrollo de una biblioteca de código parausar el protocolo de comunicación CAN (siglas del inglés Controller AreaNetwork) en conjunto con la API (Application Programming Interface) del

Proyecto CIAA. Como parte del trabajo se realizó la implementación delprotocolo de alto nivel CANopen de uso industrial y el desarrollo de un módulo

de hardware CAN para ser utilizado con la plataforma EDU-CIAA-NXP.

En el desarrollo realizado se utilizaron conocimientos sobre patrones de diseño,modularización del software, ejecución en tareas, control de versiones, diseño decircuitos impresos y protocolos de comunicación incorporados de las diferentes

asignaturas de la carrera.

V

Índice general

Resumen III

1. Introducción General 11.1. Controller area network (CAN) . . . . . . . . . . . . . . . . . . . . . 11.2. El protocolo CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Elementos CAN y CANopen de código abierto . . . . . . . . . . . . 21.4. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 52.1. Estándar y arquitectura de un nodo CAN-Bus . . . . . . . . . . . . 52.2. Características del protocolo CAN-bus . . . . . . . . . . . . . . . . . 52.3. Características del protocolo CANopen . . . . . . . . . . . . . . . . 8

2.3.1. Diccionario de objetos . . . . . . . . . . . . . . . . . . . . . . 82.3.2. Network Management . . . . . . . . . . . . . . . . . . . . . . 92.3.3. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.4. Service data objects . . . . . . . . . . . . . . . . . . . . . . . . 112.3.5. Process data objects . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4. Perfiles de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Diseño e Implementación 153.1. Estructura del nodo CAN desarrollado . . . . . . . . . . . . . . . . . 153.2. Hardware desarrollado . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3. Implementación de la biblioteca de código . . . . . . . . . . . . . . 19

3.3.1. Inicialización . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2. Bucle principal . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3. Lectura y escritura de mensajes . . . . . . . . . . . . . . . . . 223.3.4. Suscripción y desuscripción a mensajes . . . . . . . . . . . . 23

3.4. Implementación de CANopen . . . . . . . . . . . . . . . . . . . . . . 233.4.1. Network Management . . . . . . . . . . . . . . . . . . . . . . 233.4.2. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.3. Diccionario de objectos . . . . . . . . . . . . . . . . . . . . . . 253.4.4. Service data objects . . . . . . . . . . . . . . . . . . . . . . . . 263.4.5. Process data objects . . . . . . . . . . . . . . . . . . . . . . . . 27

4. Ensayos y Resultados 334.1. Interfaz física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2. Biblioteca CAN-bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3. Implementación CANopen . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.2. Network Management . . . . . . . . . . . . . . . . . . . . . . 404.3.3. Service data objects . . . . . . . . . . . . . . . . . . . . . . . . 404.3.4. Process data objects . . . . . . . . . . . . . . . . . . . . . . . . 41

VI

4.4. Comparación con estado del arte . . . . . . . . . . . . . . . . . . . . 44

5. Conclusiones 475.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.1. Sobre el proyecto actual . . . . . . . . . . . . . . . . . . . . . 485.2.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Bibliografía 49

VII

Índice de figuras

1.1. Red CAN con tres nodos. . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Transceptor CAN Arduino MKR CAN Shield. . . . . . . . . . . . . 31.3. Transceptor CAN tja1050. . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Placa de desarrollo de transceptor CAN MAX13054. . . . . . . . . . 3

2.1. Equivalencia entre modelo OSI y estándares CAN. . . . . . . . . . . 62.2. Red CAN con resistor de terminación. . . . . . . . . . . . . . . . . . 62.3. Niveles físicos y lógicos en el bus CAN. . . . . . . . . . . . . . . . . 72.4. Trama CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5. Comparación de ids entre CAN-bus y CANopen. . . . . . . . . . . 82.6. Máquina de estados del NM de un nodo esclavo. . . . . . . . . . . . 102.7. Envío de heartbeats de dos esclavos a un maestro. . . . . . . . . . . 102.8. Conexión cliente-servidor durante un intercambio SDO. . . . . . . 112.9. Trama SDO de bajada de un dato al diccionario de objetos. . . . . . 122.10. Trama SDO de subida de un dato al diccionario de objetos. . . . . . 132.11. Mapeo de una entrada del diccionario de objetos. . . . . . . . . . . 132.12. Ejemplo de TPDO resultante de un mapeo. . . . . . . . . . . . . . . 14

3.1. Ecosistema completo de la EDU-CIAA-NXP con el detalle del tra-bajo realizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2. Circuito esquemático del microcontrolador y el transceptor del mó-dulo CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3. Circuito esquemático de la terminación, protección y conector delmódulo CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4. A la izquierda se ve el render 3D del PCB, a la derecha una foto delproducto terminado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. Relación entre los componentes de la biblioteca y componentes ex-ternos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6. Recepción de mensajes en el bucle principal. . . . . . . . . . . . . . 213.7. Patrón productor/consumidor para escritura asincrónica. . . . . . . 223.8. Relación entre los distintos componentes de la implementación del

stack CANopen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.9. Esquema interno simplificado del módulo de network management. 253.10. Esquema interno simplificado del módulo de heartbeat. . . . . . . . 253.11. Diagrama de secuencia de un servidor SDO ante la llegada de un

mensaje. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.12. Diagrama de secuencia de un cliente SDO durante el envío de un

mensaje. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.13. Diagrama de secuencia de la recepción de un RPDO. . . . . . . . . 293.14. Detección de interrupción de una entrada. . . . . . . . . . . . . . . . 30

4.1. Banco utilizado para medir la interfaz física del poncho. . . . . . . 334.2. Trama de heartbeat a enviar durante la prueba de hardware. . . . . 34

VIII

4.3. Niveles de señal sobre el bus CAN. . . . . . . . . . . . . . . . . . . . 344.4. Tiempo de bit en la comunicación CAN. . . . . . . . . . . . . . . . . 354.5. Decodificación de la trama de heartbeat. . . . . . . . . . . . . . . . . 354.6. Banco de pruebas para la biblioteca CAN-bus. . . . . . . . . . . . . 364.7. Diagrama de secuencia para la prueba de la biblioteca CAN-bus. . 374.8. Captura de eventos en prueba CAN-bus. . . . . . . . . . . . . . . . 384.9. Inicialización y monitoreo de heartbeat en funcionamiento normal. 394.10. Detección de error en heartbeat monitoreado. . . . . . . . . . . . . . 394.11. Secuencia del network management a inyectar en el sistema. . . . . 404.12. Pogresión de la máquina de estados del network management. . . 414.13. Pedido de lectura y escritura del heartbeat a través de un SDO. . . 424.14. Configuracion de los RPDO y TPDO en cada placa. . . . . . . . . . 424.15. Captura del intercambio PDO ante una interrupción de entrada di-

gital. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.16. Captura del intercambio PDO ante una interrupción de entrada

analógica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

IX

Índice de Tablas

2.1. Secciones del diccionario de objetos . . . . . . . . . . . . . . . . . . 92.2. Ejemplo del OD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. Parámetros de configuración de un PDO . . . . . . . . . . . . . . . . 122.4. Ejemplo mapeo de un TPDO . . . . . . . . . . . . . . . . . . . . . . 132.5. Los PDO en el OD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1. configuracion de mensajes . . . . . . . . . . . . . . . . . . . . . . . . 374.2. Configuración default de los HB en el OD . . . . . . . . . . . . . . . 394.3. Configuración de los PDO . . . . . . . . . . . . . . . . . . . . . . . . 434.4. Comparación stacks CANopen . . . . . . . . . . . . . . . . . . . . . . 454.5. Comparación stacks CANopen (cont.) . . . . . . . . . . . . . . . . . 464.6. Comparación de módulos CAN . . . . . . . . . . . . . . . . . . . . . 46

1

Capítulo 1

Introducción General

En esta sección se realiza una introducción al protocolo Controller Area Network yal protocolo CANopen como base del trabajo realizado. Se lleva a cabo una com-paración con hardware y software de código abierto que cumplan una funciónsimilar al desarrollo y se explica la motivación y el alcance del trabajo.

1.1. Controller area network (CAN)

El protocolo controller area network o red de controladores de zona (CAN oCAN-bus), fue inicialmente desarrollado por Bosch [1] para la industria auto-motriz y se transformó en un estándar internacional luego de la publicación dela norma ISO 11898. Este protocolo es uno de los más difundidos en la industriamundial debido a su robustez y a la baja cantidad de cableado requerido paragenerar una red. En su concepción original CAN-bus se planteó como un proto-colo para proveer comunicación determinística en sistemas distribuidos con lassiguientes características [2]:

Priorización de mensajes.

Latencia máxima garantizada.

Consistencia de la información en todos los nodos del bus.

Bus multi-maestro.

Detección de errores y retransmisión automática de mensajes.

En la figura 1.1 se presenta como ejemplo una red CAN con tres nodos. Solo doslineas conectan y comunican todos los nodos de la red, CAN-HIGH y CAN-LOW.Cada mensaje enviado tiene un identificador, denominado id único para la red yllega a todos los nodos por igual. Es responsabilidad de cada nodo saber cualesmensajes le interesan y cuales no.

1.2. El protocolo CANopen

CANopen es un protocolo de comunicación de alto nivel montado sobre CAN ydesarrollado por la compañía sin fines de lucro CAN in Automation (CiA) [3],específicamente destinado para el uso de sistemas embebidos en el ámbito indus-trial.

2 Capítulo 1. Introducción General

Aplicación

Controlador CAN

Transceptor CAN

Nodo CAN

Aplicación

Controlador CAN

Transceptor CAN

Nodo CAN

Aplicación

Controlador CAN

Transceptor CAN

Nodo CAN

RTerminación

CAN high

CAN low

RTerminación

FIGURA 1.1: Red CAN con tres nodos.

El protócolo CANopen plantea una serie de relaciones entre nodos que permitenla configuración e intercambio de información entre ellos. Los componentes másimportantes de CANopen son:

Network management: un nodo maestro se encarga de dirigir y monitorear elestado de la red de nodos.

Heartbeat: cada nodo genera una señal periódica indicando que está vivo.

Diccionario de objetos: es una tabla donde está escrita absolutamente toda lainformación del nodo, sus características, sus capacidades, etc.

Service data objects: es un servicio que permite a un nodo consultar y escribirla información del diccionario de objetos de otro nodo. En otras palabras,CANopen permite la configuración remota de sus nodos.

Process data objects: es el servicio utilizado para enviar la información im-portante generada por el nodo, por ejemplo el valor de sus entradas o elresultado de la conversión de un ADC.

1.3. Elementos CAN y CANopen de código abierto

El análisis del estado del arte se divide en tres partes, el hardware existente, labiblioteca CAN-bus y el stack CANopen.

A nivel hardware se encuentran disponibles actualmente varios módulos desa-rrollados para la plataforma Arduino [4], que se pueden usar como transceptoresentre la EDU-CIAA-NXP y el bus CAN físico, como ejemplo se encuentra el Ar-duino MKR CAN Shield [5] de la figura 1.2 y el TJA1050 CAN controller interface[6] en la figura 1.3. Fuera del ecosistema Arduino se encuentran módulos como elMAX13054AESHLD [7] de la empresa Maxim Integrated [8]. Pero nada que estéespécificamente adaptado a los conectores de expansión de la placa.

En el ámbito de la biblioteca CAN-bus no hay ninguna biblioteca desarrolladapara el microcontrolador LPC4337, solamente las funciones de LPCOpen [9] que

1.4. Motivación 3

FIGURA 1.2: Transceptor CAN Arduino MKR CAN Shield.

FIGURA 1.3: Transceptor CAN tja1050.

FIGURA 1.4: Placa de desarrollo de transceptor CAN MAX13054.

implementan las funcionalidades de más bajo nivel del microcontrolador. Por loque se puede decir que la biblioteca desarrollada en el proyecto es novedosa.

Diferente es la situación a nivel stack CANopen, existen distintas soluciones desoftware libre con variado grado de desarrollo. Se diferencian entre sí especial-mente por el entorno de ejecución al que apuntan, equipo embebido, computado-ra industrial, servidor, etc. Algunos ejemplos son MicroCANopen [10], CanFesti-val [11], CANopenNode [12], Lely CANopen [13] y OpenCANopen [14].

1.4. Motivación

La motivación principal del trabajo, fue la convicción de que una plataforma quedesea transformarse en líder o actor principal en el desarrollo tecnológico indus-trial, debe poder comunicarse sobre una red de tipo CAN y debe poder utilizarlos protocolos más difundidos sobre dicha red como lo es CANopen.

El hardware y software desarrollado enriquecen el ecosistema del proyecto CIAA[15], al brindar la posibilidad de conectar una red CAN directamente a una desus placas, la EDU-CIAA-NXP [16] y desarrollar una aplicación CAN utilizandola sAPI [17], la biblioteca por elección de la comunidad de desarrolladores de laCIAA.

4 Capítulo 1. Introducción General

1.5. Alcance

El alcance del presente trabajo incluye:

El desarrollo de firmware para una biblioteca CAN-Bus para la sAPI.

El transmisor-receptor CAN utilizado será de alta velocidad y seguirá elestándar ISO 11898-2:2008.

Un poncho para la EDU-CIAA-NXP que incluya el transceptor CAN.

5

Capítulo 2

Introducción Específica

Este capítulo presenta las bases de los protocolos CAN-bus y CANopen necesa-rios para comprender el trabajo realizado. Se incluyen los estandares existentes yuna descripción de sus principales características.

2.1. Estándar y arquitectura de un nodo CAN-Bus

El protocolo CAN-bus se ha estandarizado a partir de 1993 por la InternationalStandardization Organization (ISO) como ISO 11898 y se ha ido ampliando con elpaso del tiempo a medida que se extendía su utilización en distintos medios. Losestándares que aplican al trabajo desarrollado son:

ISO 11898-1:2015 [18]: especifica la capa de enlace de datos (DLL) y la capade señalización del medio físico y enmarca al protocolo CAN dentro delmodelo de referencia por capas OSI [19].

ISO 11898-2:2016[18]: especifica la capa de acceso físico al medio, define losniveles de tensión y las tasas de transmisión en la red. Es conocido como elestándar de CAN de alta velocidad ya que puede llegar hasta 1 Mb/s .

Las normas ISO mencionadas no hacen referencia al conector del nodo a la capafísica, permitiendo por ejemplo a las automotrices tener cada una su conector pro-pietario en su red. Sin embargo existen diferentes normas por fuera de la ISO quelos estandarizan. La norma que utilizamos en el trabajo depende de la asociaciónsin fines de lucro CAN in Automation (CiA) [3]:

CiA DS-102[20]: recomienda tipos de conectores y distribución de pines pa-ra lograr mayores velocidades en el acceso a la red CAN.

La figura 2.1 resume lo mencionado y muestra la equivalencia entre los estándaresCAN y el modelo OSI y agrega la comparación contra una típica implementaciónde un nodo CAN en un sistema embebido. El conector y el transceptor seránparte del hardware, el controlador estará incluido dentro de las prestaciones delmicrocontrolador y la aplicación será el firmware a desarrollar.

2.2. Características del protocolo CAN-bus

En el capítulo 1 se explicó que una red CAN-bus se compone de una serie de no-dos conectados entre sí por las lineas CAN HIGH (CANH) y CAN LOW (CANL),

6 Capítulo 2. Introducción Específica

Capa de aplicación

Capa de presentación

Capa de transporte

Capa de sesión

Capa de red

Capa deenlace de

datos

LLC

MAC

Capa física

PLS

PMA

PMS

MDI

ISO 11898-1

ISO 11898-2

Cia DS-102

ControladorCAN

TransceptorCAN

Conector CAN

7

6

5

4

3

2

1

Modelo OSI Estándares ImplementaciónCAN

LLC: Control de enlace lógico

MAC: Control de acceso al medio

PLS: Capa de señalización del medio físico

PMA: Acople al medio físico

PMS: Especificación medio del medio físico

MDI: Interfaz dependiente del medio

Aplicación

Vacio

FIGURA 2.1: Equivalencia entre modelo OSI y estándares CAN.

como se ve en la figura 2.2. Por recomendación del estándar se debe colocar unresistor de terminación en el bus para evitar reflexiones. Usualmente su valor esde 120 Ω. La cantidad máxima de nodos dependerá de la velocidad del bus y dela distancia entre ellos, ya que se debe asegurar que los nodos en ambos extremosde la red reciban un bit dentro del mismo tiempo de bit.

Nodo 2Nodo 1 Nodo 3

Resistor determinación

Resistor determinación

CANH

CANL

FIGURA 2.2: Red CAN con resistor de terminación.

El estándar ISO 11898-2:2016 define una transmisión diferencial en el bus, el bitlógico a transmitir será derivado de la diferencia de potencial de la linea CANHy CANL, como se observa en la 2.3. Al nivel lógico 1, se lo llama bit recesivo yal nivel lógico 0, bit dominante. En el bus siempre el bit dominante le gana al bitrecesivo, es decir, si un nodo transmite un 1 lógico y otro un 0 lógico, el resto de

2.2. Características del protocolo CAN-bus 7

los nodos verá solo el 0 y el nodo que transmitió el 1 debe dejar de ocupar el businmediatamente.

1,5 V

2,5 V

3,5 VCANH

CANL

1 lógico

0 lógicoBit

dominante

Bitrecesivo

Bitrecesivo

tensión (V)

tiempo

FIGURA 2.3: Niveles físicos y lógicos en el bus CAN.

La trama CAN estándar se presenta en la figura 2.4. A continuación se listan loscampos más importantes:

SOF: inicio de trama, siempre un bit dominante.

Id: el identificador de la trama.

DLC: cantidad de datos de la trama.

ACK: se transmite un bit recesivo, el acknowledge lo da uno o más receptoresponiendo un bit dominante.

DEL: delimitador, siempre un bit recesivo.

EOF: final de trama, siempre un bit recesivo.

11b

C

4b

DatosId RTRSOF

1b 1b 1b 16b

DLC

3b

EOFDELACK

1b1b1b

CRC

FIGURA 2.4: Trama CAN.

El campo más importante como se ha mencionado en el capítulo 1 es el identifica-dor o id. En el protocolo CAN no se identifican los dispositivos, sino los mensajes,existe una lista definida de mensajes con su correspondiente id y cada nodo escu-cha solo los que le interesan. Cada mensaje debe ser único y la prioridad se da porla lógica bit recesivo/bit dominante. Como el 0 lógico siempre le gana al 1 lógico,el mensaje con id todo ceros será el más prioritario, seguido por el mensaje uno,dos, etc.

La trama CAN solo permite enviar entre cero y ocho bytes de datos por trama yno plantea ningún tipo de segmentación y ensamble de paquetes más grande, esodeberá hacerse a nivel aplicación de ser necesario.


2.3. Características del protocolo CANopen

Las bases del protocolo CANopen están definidas en el estándar DS-301 [21]. Im-plementa parcialmente parte de las capas cuatro a seis del modelo OSI y se apoyaen CAN-bus para las capas inferiores. Incluso es posible mantener nodos que so-lo hablen CAN en una red CANopen, siempre que se asegure que los ids de losmensajes sean únicos [10].

La primera y mayor diferencia entre ambas redes es que los nodos CANopenposeen un id que los identifica. Los mensajes son dirigidos por un emisor hacíaun destinatario, exceptuando algunos mensajes que llegan a todos los nodos. El idde CANopen toma siete bits del id de la trama CAN-bus, lo que da un máximo de127 nodos en la red (el id 0 esta reservado). Los otros cuatro bits son usados paraindicar el tipo de mensaje que se está transmitiendo. A esta unión de CANopen idmás identificador se lo llama cob_id, que termina resultando el id a nivel CAN-buscomo se ven en la figura 2.5.

CAN id

11 bits

Tipo Id del nodo

CAN-bus

CANopen

cob_id

7 bits4 bits

FIGURA 2.5: Comparación de ids entre CAN-bus y CANopen.

La segunda gran diferencia entre CANopen y CAN-bus, es que CANopen es-tablece distintos objetos y sus relaciones dentro del estándar, en lugar de dejartodo en manos de la aplicación como CAN-bus. En las siguientes subsecciones sedetallan los principales objetos y sus características.

2.3.1. Diccionario de objetos

El diccionario de objetos (OD) es una tabla que contiene toda la información delnodo y es único para cada uno. Esta tabla es la que define toda su la funcionalidady configuración. Al escribir los valores de la tabla se puede afectar las tareas queel nodo realiza, en cambio al ser leida remotamente le permite a la red conocerlas capacidades del nodo. Dentro del estándar se definen algunas entradas de latabla como mandatorias, pero la mayoría son opcionales. La funcionalidad finaldel nodo será la que determinará que entradas debe tener presente.

La primera indexación de la tabla se hace por valores de 16 bits llamados índices.Según el rango al que pertenezca el índice se hace una primera separación ensecciones, como se muestra en la tabla 2.1.

Cada entrada correspondiente a un índice está subdividida en uno o más subín-dices y cada subíndice contiene un dato de cierto tipo. En las entradas que exista

2.3. Características del protocolo CANopen 9

TABLA 2.1: Secciones del diccionario de objetos.

Rango de índice Descipción

0x0000 Reservado0x0001 - 0x025F Definiciones de tipos de dato0x0260 - 0x0FFF Reservado0x1000 - 0x1FFF Perfil de comunicación0x2000 - 0x5FFF Específico del fabricante0x6000 - 0x9FFF Perfil del nodo0xA000 - 0xBFFF Interfaces del nodo0xC000 - 0xFFFF Reservado

más de un dato, el subíndice cero siempre indica la cantidad de subíndices váli-dos. Un ejemplo de un extracto del diccionario de objetos puede verse en la tabla2.2.

TABLA 2.2: Ejemplo de entradas del diccionario de objetos.

Indice Subindice Tipo de dato Descripción

0x1000 0 U32 Información del dispositivo0x1017 0 U8 Tiempo de heartbeat0x1018

0 U8 = 4 (cuatro subindices válidos)1 U32 Id del fabricante2 U32 Código de producto3 U32 Número de revisión4 U32 Numero de serie

Para leer o escribir un dato en particular se debe especificar el índice y el subín-dice correspondiente.

2.3.2. Network Management

El network management o administrador de red (NMT) dentro de CANopen, imple-menta un manejo del estado de los nodos con un topología maestro-esclavo. Elmaestro es un nodo particular dentro de la red que le indica a los demás nodos enque estado deben estar, mientras que todos los demás nodos ofician de esclavos.La trama de NMT tiene la particularidad de funcionar como broadcast, es decirque la reciben todos los nodos a la vez y tiene la máxima prioridad ya que sucob_id es 0x0000. Es posible también enviar mensajes de NMT a nodos particula-res si por ejemplo se necesita resetearlos. Los nodos esclavos deben cumplir con lamáquina de estados de la figura 2.6. Todos los cambios excepto la inicializaciónson comandados por el maestro, aunque CANopen permite que el paso inicial apre-operational también sea automático en cada esclavo si el creador de la red lodesea.


Pre-operational

OperationalStopped

Puede ser automático

Initializing

Automático

Reset

Reset módulo comunicación

Reset

FIGURA 2.6: Máquina de estados del NM de un nodo esclavo.

2.3.3. Heartbeat

El heartbeat o latido (HB) es el mecanismo de control que le permite al maestroidentificar si un nodo sale de funcionamiento. Su principio es que cada nodo de-be enviar periódicamente una trama direccionada al maestro y el maestro llevael registro de cuanto tiempo pasó desde que recibió la trama de heartbeat de unnodo. Si el tiempo desde la última recepción supera un umbral, el maestro puedeenviarle un mensaje de reset al nodo problemático. La dinámica se puede obser-var en la figura 2.7.

Hb esclavo 1

Hb esclavo 2

Timeout esclavo 2,resetearlo

tiempo

FIGURA 2.7: Envío de heartbeats de dos esclavos a un maestro.

El tiempo de heartbeat del nodo esclavo, llamado heartbeat productor, y la direc-ción a la que el esclavo le envía el heartbeat, son parámetros que se configuran enel diccionario de objetos del esclavo. La lista de los heartbeats que va a recibir, lla-mados heartbeats consumidos y el tiempo umbral que espera para resetear el nodo,son parámetros del diccionario de objetos del maestro.


2.3.4. Service data objects

Los service data objects u objetos para servir datos (SDO) son los objetos que permi-ten a nodos remotos acceder de forma genérica al diccionario de objetos de unnodo. El modelo en que trabajan tiene la forma cliente-servidor, para una red da-da existe un y solo un cliente con capacidad de encuestar a los nodos restantesque funcionan como servidores.

En la figura 2.8 se observa como cada servidor solo necesita configurar un cob_idpara recibir datos, pero el cliente debe tener un cob_id distinto por cada servidordel que espere respuesta.

cob_id 0x581

cob_id 0x582

cob_id 0x583

cob_id 0x603

Nodo 3Servidor

cob_id 0x601

Nodo 1Servidor

cob_id 0x602

Nodo 2Servidor

Nodo 4Cliente

FIGURA 2.8: Conexión cliente-servidor durante un intercambioSDO.

Las operaciones que se pueden realizar con los SDO son de descarga o de subida.La operación de descarga implica grabar un valor en el diccionario de objetosremoto, mientras que la de subida permite obtener el valor actual. Como se haindicado en la subsección 2.3.1 para referenciar una entrada del diccionario deobjetos se necesita su índice y subíndice, por eso son parte de la trama de descargaque se ve en la figura 2.9. Una particularidad de los SDO es que siempre utilizanlos ocho bytes disponibles de la trama CAN-bus. En los primero cuatro bytescoloca el índice, subíndice y la cantidad de bytes a grabar, de los siguiente cuatroutiliza solo los que necesite, el resto pueden tener cualquier valor. La figura 2.10muestra la trama de subida que tiene las mismas consideraciones.

2.3.5. Process data objects

Aunque los SDO proveen una manera de transferir información de un nodo aotro, no son óptimos para trabajar con información periódica o asincrónica yaque siempre debe haber un nodo encuestando por los datos. Para este trabajoexisten los process data objects u objetos para procesamiento de datos (PDO), una vezconfigurados le permiten a un nodo mandar información cada cierto tiempo ocuando se de alguna condición de disparo.

Existen dos tipos de PDO, los transmit process data objects (TPDO) y los receive pro-cess data objects (RPDO). Los TPDO son los productores y se configuran en losnodos que generan la información, por ejemplo donde están conectados los sen-sores del sistema. Mientras que los RPDO son los consumidores y se configuran


600 + node ID Indice subíndice

0x2F d0 x x x

0x2B d1 d0 x x

0x27 d2 d1 d0 x

0x23 d3 d2 d1 d0

Tx dos bytes

Tx un byte

Tx tres bytes

Tx cuatro bytes

Cliente a servidor

Respuesta servidor a cliente

580 + node ID Indice subíndice0x60 0x00 0x00 0x00 0x00

Respuestaok

2B 2B 2B1B 1B 1B 1B 1B

FIGURA 2.9: Trama SDO de bajada de un dato al diccionario deobjetos.

donde se quiere recibir la información, por ejemplo donde se debe decidir algunaacción de control.

Para cualquier PDO existen dos sets de configuración, los parámetros de confi-guración que indican el cob_id asociado y como es disparado y los parámetros demapeo, que indican que registros del diccionario de objetos deben enviarse.

Los parámetros de configuración típicos de un TPDO y un RPDO pueden verseen la tabla 2.3. Los registros son los mismos en ambos PDO, pero en los RPDOalgunos no tienen validez. El registro más importante es el cob_id, que indica eldestinatario o la fuente del mensaje según sea un TPDO o RPDO. El tipo de trans-misión indica cual es la fuente de disparo que genera el PDO, la más importantees la de cambio de estado, por ejemplo el cambio de estado de una entrada. Lalista completa de las fuentes de disparo y su descripción puede encontrarse enel estándar DS-301. El tiempo de inhibición solo aplica a los TPDO y abre unaventana de tiempo en donde no se puede volver a enviar el PDO, esto evita queel bus se llene de mensajes ante una entrada que está cambiando continuamente.

TABLA 2.3: Parámetros de configuración de un TPDO y RPDO.

Subíndice Nombre Tipo de dato TPDO RPDO

0 Cantidad de entradas U8 Sí Sí1 cob_id U32 Sí Sí2 Tipo de transmisión U8 Sí Sí3 Tiempo de inhibición U16 Sí No4 Reservado U8 No No5 Contador de eventos U16 Sí No

Cada parámetro de configuración de un PDO tiene asociado un parámetro demapeo, que es una lista con las entradas del diccionario de objetos que se debenenviar cuando el PDO es disparado. Cada item se escribe como un entero sin


580 + node ID Indice subíndice

0x4F d0 x x x

0x4B d1 d0 x x

0x47 d2 d1 d0 x

0x43 d3 d2 d1 d0

Tx dos bytes

Tx un byte

Tx tres bytes

Tx cuatro bytes

Cliente a servidor

Respuesta del servidor al cliente

600 + node ID Indice subíndice0x40 0x00 0x00 0x00 0x00

lectura

2B 2B1B 1B 1B 1B 1B 1B

FIGURA 2.10: Trama SDO de subida de un dato al diccionario deobjetos.

signo de cuatro bytes, que engloba la información para identificar la entrada, quecomo ya se ha indicado es el índice y subíndice en el OD y se agrega la cantidadde bits que ocupa como ilustra la figura 2.11.

bits 31 .. 16 bits 15 .. 8 bits 7 .. 0

Indice Subindice Largo (bits)

FIGURA 2.11: Mapeo de una entrada del diccionario de objetos.

En la tabla 2.4 se muestra un ejemplo de mapeo completo, el índice 0x6000 corres-ponde a un puerto de 8 bits de entradas digitales, mientras que el índice 0x6401corresponde a entradas analógicas, el subindice 0x01 es la entrada del canal 1mientras que el subindice 2 corresponde al canal 2. En la figura 2.12 se ve la tra-ma que se genera con este mapeo.

TABLA 2.4: Ejemplo mapeo de un TPDO.

Subíndice Tipo ValorIndice

mapeadoSubíndicemapeado

Tamaño

0 U8 3 =>3 subindices1 U32 60000108 0x6000 0x01 8 bits2 U32 64010110 0x6401 0x01 16 bits3 U32 64010210 0x6401 0x02 16 bits

Finalmente, en la tabla 2.5 se observa que la configuración y los mapeos, tanto delos TPDO, como de los RPDO son también parte del diccionario de objetos, por loque es posible modificarlos remotamente a través de un SDO lo que es conocidocomo mapeo dinámico.


Byte 1 Byte 2 Byte 3 Byte 4 Byte 5

Valor ent.digitales

Conversión ADC CH1 Conversión ADC CH2TPDO

FIGURA 2.12: Ejemplo de TPDO resultante de un mapeo.

TABLA 2.5: Posicionamiento de los PDO en el diccionario de obje-tos.

Rango índice Parámetro

0x1400 - 0x15FF Configuración RPDO0x1600 - 0x17FF Mapeo RPDO0x1800 - 0x19FF Configuración TPDO0x1A00 - 0x1BFF Mapeo TPDO

2.4. Perfiles de dispositivos

El estándar DS-301 define un diccionario de objetos genérico para la existencia deun nodo, pero la verdadera funcionalidad del nodo debe estar representada conuna lista extra de entradas. Para esto la CiA define una serie de perfiles dondele asigna un índice a estas entradas extra. A lo largo del proyecto se trabajó conel DS-401 [22], que es el estándar para dispositivos genéricos de entrada salida.Define indices para leer entradas de 8 bits, de 1 bit, de 32 bits, analógicas, digita-les, etc. También agrega distintas condiciones de disparo como por ejemplo flancoascendente en una entrada digital, máxima variación de un parámetro analógico,etc.

Es importante notar que no es necesario utilizar un perfil definido por la CiAal desarrollar un nodo, cada fabricante puede decidir sus propios diccionariossiempre y cuando todos los nodos de la red lo conozcan y entiendan.

Aquí concluye la introducción de los conceptos necesarios, para comprender eldiseño e implementación que se presentan a continuación en el capítulo 3.

15

Capítulo 3

Diseño e Implementación

En este capítulo se muestra el esquemático y PCB del hardware CAN desarrolladoy se explica la arquitectura y decisiones de diseño en el desarrollo de la bibliotecaCAN-bus y el stack CANopen.

3.1. Estructura del nodo CAN desarrollado

Se muestra en la figura 3.1 el ecosistema completo del que el desarrollo formaparte. La sapi_can, se adosa como un módulo más dentro de la estructura dela sAPI y puede funcionar de forma independiente al resto del desarrollo. Poresta razón a lo largo del trabajo se la referencia siempre como biblioteca CAN-bus. Sus dependencias son la biblioteca LPCopen provista por el fabricante delmicrocontrolador y el resto de la sAPI.

El stack CANopen depende solamente de la biblioteca CAN-bus, mientras que laaplicación del usuario utilizará las interfaces de CANopen pero también el restode la funcionalidad de la sAPI. En la figura 3.1 también se ve claramente comolos bloques color verde claro tienen la estructura del nodo CAN visto de formateórica en el capítulo 2.1.

Como comentario final se aclara que el trabajo es fuertemente dependiente deldiseño físico de la EDU-CIAA-NXP y del microcontrolador LPC4337 que usa,portar lo realizado a otra arquitectura es posible pero no inmediato.

3.2. Hardware desarrollado

Como se detalló en los objetivos y alcances del proyecto en el capítulo 1, el hard-ware fue desarrollado como un poncho para la placa EDU-CIAA-NXP. La prime-ra y más importante decisión fue el transceptor CAN a utilizar. El elegido fue elTJA1051T de la empresa NXP, ya que cuenta con las siguientes ventajas:

Se consigue en el mercado local.

No necesita adaptación de niveles ya que trabaja con alimentación de 3 V y5 V.

Al momento del desarrollo es la última generación de una familia de trans-ceptores muy utilizada en la industria.

Garantiza compatibilidad con el estándar ISO 11898-2:2016.

16 Capítulo 3. Diseño e Implementación

sapi_uart sapi_gpio sapi_can...

LPCopen

CANopen

SAPI

Hardware EDU-CIAA-NXP

PonchoCAN

Nodo CAN

Provisto por NXP

Dependiente del usuario

Desarrollado en este trabajo

Comunidad CIAA

Código de colores

Aplicación

FIGURA 3.1: Ecosistema completo de la EDU-CIAA-NXP con eldetalle del trabajo realizado.

La conexión física con el bus CAN se dará a través de un conector DB9 según elestandar DS102. La placa cuenta también con los resistores de terminación de 120Ω que pueden ser incluidos o no con un jumper de goteo. Finalmente, se agregóuna protección contra descarga electrostática (ESD) en la entrada del bus CANpara salvaguardar al resto de los componentes.

En la figura 3.2 se observa el esquema del microcontrolador y el transceptor,mientras que en la figura 3.3 se muestra el circuito de terminación, la proteccióny el conector. Dado que el microcontrolador cuenta con dos módulos CAN inde-pendientes, el mismo circuito se replicó y conectó a la segunda interfaz, se omitede la memoria por no aportar información nueva.

El diseño del PCB se inició con los siguientes objetivos:

1. Mantener la superficie del poncho lo más pequeña posible.

2. Colocar los conectores DB9 en el borde de la placa para facilitar un futurodiseño de un gabinete.

3. Mantener fácil acceso a los pulsadores y leds para no restarle funcionalidada la EDU-CIAA-NXP.

4. Respetar los agujeros de sujeción de la EDU-CIAA-NXP.

Como se desprende del siguiente análisis, se observa que no todos los objetivospudieron ser cumplidos:

El borde más cercano a los conectores del poncho es el de los pulsadores,cumplir el objetivo dos invalida el tres.

3.2. Hardware desarrollado 17

FIGURA 3.2: Circuito esquemático del microcontrolador y el trans-ceptor del módulo CAN.

Colocar los conectores DB9 en un borde que no sea el de los pulsadoresinvalida el objetivo uno.

El tamaño de los conectores DB9 genera interferencia con los agujeros desujeción invalidando el objetivo cuatro.

Finalmente, se decidió priorizar los objetivos uno y dos para mantener el produc-to final lo más compacto posible y fácil de instalar en un gabinete de ser necesario.

En la figura 3.4 se puede ver el render 3D del PCB y una foto del producto termi-nado.


FIGURA 3.3: Circuito esquemático de la terminación, protección yconector del módulo CAN.

FIGURA 3.4: A la izquierda se ve el render 3D del PCB, a la derechauna foto del producto terminado.

3.3. Implementación de la biblioteca de código 19

3.3. Implementación de la biblioteca de código

Para comprender la arquitectura propuesta, se puede observar en la figura 3.5 lasrelaciones a alto nivel entre los diferentes componentes de la biblioteca y como seconecta con los componentes externos. En los capítulos subsiguientes se analizaen detalle cada función de la application programming interface (API) y la estructurainterna del módulo.

Llama

CAN_Loop

Escribe

CAN_Write_Async

LeeCAN_Read

Inicializa

EscribeCAN_Write

Callback

ConfiguraEscribeCAN_Remove_Id

ConfiguraEscribeCAN_Listen_Id

Módulo CAN Micro-

controlador

Buffer señales: array

campo 1 = idcampo 2 = dlccampo 3 = datoscampo 4 = callback

ConfiguraCAN_Init

Buffer envio: circular

campo 1 = idcampo 2 = dlccampo 3 = datoscampo 4 = callback

Lee

LPCopen

Escribe

IRQ

Escribe

API del móduloLPCopen provisto por NXPFunción externa al móduloRegistros del microcontroladorEstructuras de datos internas

Código de colores

MemoriaProtegida

Thread safe

FIGURA 3.5: Relación entre los componentes de la biblioteca ycomponentes externos.


3.3.1. Inicialización

Para inicializar la biblioteca CAN-bus se debe llamar a la función CAN_Init cuyoprototipo se observa a continuación.

1 bool_ t CAN_Init ( c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e , c c a n _ i n t e r f a c e s _ tinterfaceNumber , u i n t 3 2 _ t baudrate , canObjec t_ t ∗ pDataObject ,u i n t 3 2 _ t numberOfSignals , can_conf igValues_t ∗ pIdArray ) ;

ALGORITMO 3.1: Prototipo de la función de inicialización.

Los argumentos a proveerle son los siguientes:

Estructura de la interfaz vacía a ser llenada por la función, se utilizará comoargumento en todos los comandos posteriores.

Numero de interfaz del micro a utilizar, el LPC1337 tiene dos interfacesdisponibles, CCAN1 y CCAN2.

La velocidad del bus en bps.

La dirección de un buffer de tipo canObject_t para uso interno del módulo.

Una lista de los ids que se desea escuchar.

.

La función CAN_Init se encargará de inicializar todos los registros del microcon-trolador necesarios y dejar toda su estructura interna en el estado adecuado. Estaestructura es devuelta al usuario en una variable de tipo can_interface_t, es suresponsabilidad preservar la integridad de esta variable y utilizarla en las subse-cuentes invocaciones de las funciones del módulo.

La creación del objeto de tipo canObject_t es también responsabilidad del usua-rio, pero se le brinda la macro del algoritmo 3.2 para generarlo de forma estática.Este buffer contendrá los datos internos de todos los mensajes enviados y recibi-dos y aunque su uso esta protegido dentro del módulo, si el usuario modifica sucontenido externamente, dejará a toda la librearía en un estado desconocido.

1 # def ine CAN_Create_Data_Objects (name) \2 canObjec t_ t name[CAN_MAX_NUMBER_RX_SIGNALS]

ALGORITMO 3.2: Macro para inicializar el array de datos.

Finalmente, el último argumento importante es una lista de ids para escucharen el bus y callbacks para llamar cuando el mensaje arribe. La lista se generaautomáticamente a partir de una X-macro [23] que debe llenar el usuario. Unejemplo se puede ver en el algoritmo 3.3.

1 /∗ X−Macro to conf igure the s i g n a l s ∗/2 # def ine CAN1_RECEIVED_SIGNALS\3 /∗ Nombre , id , Cal lback ∗/ \4 CAN1_SIGNAL( RX_ID_100 , 0x100 , CAN_NO_CALLBACK) \5 CAN1_SIGNAL( RX_ID_101 , 0x101 , recieve_message_101 )

ALGORITMO 3.3: X-macro para inicializar los mensajes a escucharen el bus.

3.3. Implementación de la biblioteca de código 21

3.3.2. Bucle principal

El bucle principal tiene dos funciones. Primero, chequea si se ha recibido algúnmensaje en el buffer de tipo canObject_t; en caso positivo, si hay algún callout aso-ciado al mensaje recibido se lo invoca. Su segunda función es enviar cualquiermensaje pendiente en el buffer circular de transmisión.

Los callouts deben estar definidos según el prototipo del algoritmo 3.4.

1 void c a l l b a c k (CCAN_MSG_OBJ_T ∗ dataObject ) ;

ALGORITMO 3.4: Tipo de la función de callback.

La función CAN_Loop, cuyo prototipo puede verse en el algoritmo 3.5, es la fun-ción motora de la biblioteca. Es mandatorio que el usuario del modulo la invoqueperiódicamente y la frecuencia con que lo haga será directamente proporcional ala capacidad de la biblioteca de no perder mensajes. Si dos mensajes con el mismoid son recibidos entre llamados, solo el último mensaje será procesado, como sepuede ver en el diagrama de secuencia de la figura 3.6. Como regla general la tasade invocación debe ser mayor que la frecuencia del mensaje más rápido de la red.

1 void CAN_Loop( c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e ) ;

ALGORITMO 3.5: Prototipo de la función CAN_Loop.

Tarea CAN_Loop

callout

callout

IRQ

Call

Bus can

Id = 0x100

Buffermanager

Guardar mensaje

Obtener msj.

Call

Id = 0x101

Guardar mensaje

Obtener msj.

Id = 0x101

Guardar mensaje¡Se pierde elmensaje anterior!

función de callout asociada al id

función de calloutasociada al id

FIGURA 3.6: Recepción de mensajes en el bucle principal.


El formato y funcionalidad de CAN_Lopp la hace compatible con la invocacióndesde una tarea o thread de un sistema operativo, pero también puede ser llamadadesde un bucle en un programa bare metal.

3.3.3. Lectura y escritura de mensajes

Existen dos funciones para escribir mensajes en la red CAN y una para leer losmensajes recibidos.

Los prototipos de los mensajes de escritura se muestran en el algoritmo 3.6.

1 bool_ t CAN_Write ( c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e , u i n t 3 2 _ t id , u i n t 8 _ t ∗pBuffer , s i z e _ t dlc ) ;

2 void CAN_Write_Async ( c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e , u i n t 3 2 _ t id , u i n t 8 _ t ∗pBuffer , s i z e _ t dlc ) ;

ALGORITMO 3.6: Prototipo de las funciones de escritura.

La función CAN_Write escribe a través de LPCopen, directamente sobre el busCAN. Es una función bloqueante ya que no saldrá de la función hasta no haberenviado todos sus datos. Como maneja variables internas no protegidas, debe serexclusivamente llamada desde el entorno en donde corra el bucle principal.

La función CAN_Write_Async es utilizada para escribir de forma asincrónica albus. Internamente implementa el patrón de diseño productor/consumidor, sien-do esta función el productor, CAN_Loop el consumidor y un buffer circular el me-dio de intercambio de información, como se ve en la figura 3.7.

Poner

CAN_Write_Async

Enviar

CAN_Loop

Sacar

Buffercircular

FIGURA 3.7: Patrón productor/consumidor para escritura asin-crónica.

La lectura se realiza con el prototipo del algoritmo 3.7.

1 bool CAN_Read( u i n t 8 _ t ∗pData , u i n t 3 2 _ t ∗dlc , c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e ,u i n t 3 2 _ t id ) ;

ALGORITMO 3.7: Prototipo de la función de lectura.

La función CAN_Read se usa para trabajar por encuesta, ya que se le debe pasarel id del mensaje que se está buscando. La información retornada corresponde alúltimo mensaje recibido para ese id desde la última lectura realizada, ya que elmensaje se borra solamente cuando es leído. Esto significa que al leer un mensaje

3.4. Implementación de CANopen 23

no se conoce hace cuanto llego y obliga a leer continuamente para estar actuali-zado.

Es importante aclarar que el modo de trabajo por callout desde la función CAN_Loopy el modo de lectura con CAN_Read son mutuamente excluyentes. Si al id se lecarga una función de callout, entonces nunca se lo hace disponible a la funciónCAN_Read.

3.3.4. Suscripción y desuscripción a mensajes

Es necesario indicarle al módulo CAN del microcontrolador qué mensajes del busdebe capturar y enviar a las capas superiores, para esto se cuenta con una funciónde suscripción y una función de desuscripción con los prototipos del algoritmo3.8.

1 void CAN_Listen_Id ( c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e , u i n t 3 2 _ t id ,cal lBackCanFuncPtr_t pCallback ) ;

2 void CAN_Remove_Id ( c a n _ i n t e r f a c e _ t ∗ i n t e r f a c e , u i n t 3 2 _ t id ) ;

ALGORITMO 3.8: Prototipo de las funciones de suscripcion ydesuscripcion.

En el capítulo 2.2 se ha visto que cada mensaje tiene un identificador unívocodentro de la red. Si se quiere escuchar un mensaje en particular, se le debe pasarel id al microcontrolador para que lo agregue en sus filtros internos. El segundoparámetro es un puntero a la función de callback, que puede ser o no nulo segúnel modo de uso que elija el usuario. Esta función será llamada cada vez que unmensaje con este id en particular sea recibido.

Ambas funciones se ejecutan en el mismo entorno desde donde fueron llamadas.Una vez ejecutada la desuscripción de un id, los mensajes pendientes y/o noleídos dentro de la biblioteca son inmediatamente eliminados.

3.4. Implementación de CANopen

En la figura 3.8 se observan los módulos en los que fue desglosada la implementa-ción del stack CANopen, cómo se relacionan entre sí y con el resto del programa.En las siguientes subsecciones se analiza la solución implementada módulo pormódulo.


El módulo de NMT fue implementado con una máquina de estados finita (MEF),siguiendo el esquema presentado en el capítulo 2.3.2. El pasaje del estado initia-lizing a pre-operational se produce de forma automática al terminar de bootear elnodo. El resto de las transferencias son disparadas por los mensajes CAN de tiponetwork, que indican el nuevo estado al que transicionar. Un esquema simplifica-do del funcionamiento interno se observa en la figura 3.9.

Como el módulo NMT es transversal a los demás módulos del stack CANopen,ya que habilita o deshabilita funcionalidades, se proveen tres funciones amigas.


Envía

Aplicación

Envía

Consulta

Habilita

Consulta

PDO

Escribe

Habilita

SDO

Envía

Consulta

HabilitaHeartbeat

Envía

Consulta

Network Management

Configura

Callback Callback

Callback

CallbackCANopen to

CAN

Callback

sapi_can

Lee

Diccionario deObjectos

Envía

CANopen

FIGURA 3.8: Relación entre los distintos componentes de la imple-mentación del stack CANopen.

Cada una le permite al elemento invocante, conocer las capacidades que tienedisponible en ese momento. Para que el NMT trabaje correctamente, la funciónNMT_Process debe ser llamada periódicamente por una tarea, thread o bucle.

La máquina de estados debe ser inicializada antes de poder ser utilizada con unllamado a la función NMT_Init.

3.4.2. Heartbeat

El módulo de heartbeat es comandado por la función HB_Process, la cual debeser llamada periódicamente. Dentro de ella se ejecutan dos procesos, el primeroverifica si se debe enviar el heartbeat producido y el segundo si a alguno de losheartbeats consumidos se le venció su timeout, en cuyo caso se le envía el mensajede reset. El timeout para cada nodo consumido vuelve a arrancar cada vez quellega el mensaje de heartbeat correspondiente por el bus CAN. En la figura 3.10se observa un esquema simplificado del módulo.

Se cuenta con dos funciones disponibles para ser utilizadas en caso de que hayaun cambio en el diccionario de objetos, una para un cambio de tiempo en el HBproducido y la otra para un cambio de tiempo o de origen del HB consumido.

En la inicialización del sistema es necesario invocar a HB_Init, quien es la encar-gada de suscribirse a los ids a escuchar y establecer la lógica interna del módulo.


NMT_Process NMT MEF

CANopen NMTmessage

callout

busCAN

Is_HB_Enabled

Is_SDO_Enabled

Is_PDO_Enabled

Funciones amigasNetwork Management

sistemaoperativo,

bucle othread

FIGURA 3.9: Esquema interno simplificado del módulo de net-work management.

HB_Process

Enviar HBproducido

Reset timer

CANopen HBmessage

callout

Timer HBconsumido

timestamp

Heartbeat

sistemaoperativo,

bucle othread

cob_id delheartbeat

consumido

Cambio en ODde HB

producido

Cambio en ODde HB

consumido

Funciones amigas

FIGURA 3.10: Esquema interno simplificado del módulo de heart-beat.

3.4.3. Diccionario de objectos

El diccionario de objetos puede pensarse simplemente como una gran memoriacon posiciones, acá llamadas registros, y datos asociados a esas posiciones. La pro-blemática reside en que el tipo de dato asociado es diferente para cada posiciónque se accede, teniendo que implementar una función distinta para cada registroen el peor caso. Los objetivos al implementar este módulo fueron:

Reducir el tiempo de acceso a un registro.

Reducir el tiempo de agregado de nuevos registros al OD, si su tipo de datoes igual al de un registro ya utilizado.

Para lograr esto se usaron dos niveles de X-Macros. El primer nivel permite sepa-rar el diccionario en funcionalidades como se ve en el algoritmo 3.9.

1 # def ine OD_RANGES /∗ I n i c i o FIN ∗/ \


2 X(RESERVED, 0x0000 , 0 x0000 ) \3 X(DATA_TYPES, 0x0001 , 0x025F ) \4 X(RESERVED_2 , 0x0260 , 0x0FFF ) \5 X(COMMUNICATION_ENTRIES, 0x1000 , 0x1FFF ) \6 X(MANUFACTURER_SPECIFIC, 0x2000 , 0x5FFF ) \7 X(STANDARDIZED_DEVICE, 0x6000 , 0x9FFF ) \8 X(STANDARDIZED_INTERFACE, 0xA000 , 0xBFFF ) \9 X(RESERVED_3 , 0xC000 , 0xFFFF )

ALGORITMO 3.9: X-Macro para detectar el tipo de funcionalidaddel registro.

El registro a analizar se comparará contra todos los rangos hasta determinar aque tipo pertenece.

El segundo nivel se usará para encontrar el lugar donde esta ubicado el datobuscado y que función se debe utilizar para escribirlo o leerlo. El algoritmo 3.10presenta un extracto de la X-Macro referida al perfil estándar del dispositivo.

1 # def ine STANDARDIZED_DEVICE_PROFILE \2 X(0 x6000 , 1 , NULL, &rd_8bi t_va l , &od_input_dig_sig ) \3 X(0 x6002 , 1 , &wr_8bit_val , &rd_8bi t_va l , &od_polar i ty_dig_input ) \4 X(0 x6006 , 1 , &wr_8bit_val , &rd_8bi t_va l , &od_int_mask_any_change ) \5 X(0 x6401 , 1 , NULL, &rd_16bi t_va l , &od_input_analog_sig ) \6 X(0 x6424 , 1 , &wr_32bit_val , &rd_32bi t_va l , &ana_upper_ l imi t_ int ) \7 X(0 x6425 , 1 , &wr_32bit_val , &rd_32bi t_va l , &ana_ lower_ l imi t_ in t ) \

ALGORITMO 3.10: X-Macro para encontrar el dato a modificar yla función que lo hace.

Por ejemplo, si se quiere acceder al registro 0x6006 que según el estándar DS401corresponde al registro Interrupt Mask Any Change 8-Bit, la variable que contieneel valor en el programa es od_int_mask_any_change y los métodos para escribirlao leerla son wr_8bit_val y rd_8bit_val respectivamente. Como se ve en el ejemplodel algoritmo 3.10, todas las variables de 8bits compartirán los mismos métodos,todas las de 32bits compartirán el suyo, etc.

Con el método presentado, encontrar el valor de un registro dentro del dicciona-rio de objetos se logra simplemente ejecutando dos bucles iterativos e invocandoa una función. Un aspecto negativo de esta solución es que el tiempo de acceso adiferentes registros es distinto y dependiente de cuantos registros fueron defini-dos en ese diccionario en particular, ya que se va recorriendo la X-Macro de arribahacia abajo un elemento a la vez.

Es importante mencionar que el método de búsqueda aquí presentado solo se uti-liza cuando se quiere acceder al diccionario de objetos de forma externa al stack.Si se necesita un dato de forma interna, por ejemplo el módulo de heartbeat nece-sita conocer el timeout de un heartbeat consumido, existen funciones especificasque acceden a ese valor directamente y sin perder tiempo en todas las iteraciones.


Como se ha explicado en el capítulo 2.3.4 un nodo puede funcionar como servidorSDO o cliente SDO. La decisión debe tomarse al momento de llamar a la funcionSDO_Init. Independientemente del rol, la funcionalidad principal del módulo esinterpretar o componer los mensajes recibidos o enviados respectivamente. Los


mensajes interpretados luego serán pasados al diccionario de objetos o al móduloque lo haya pedido, los mensajes compuestos serán enviados por el bus CAN asu destino.

En la figura 3.11, se puede ver la secuencia que se ejecuta en un servidor desdeque el mensaje llega por el bus CAN hasta que se envía la respuesta. El buffer cir-cular funciona en modelo productor/consumidor y permite desacoplar la llegadadel mensaje de su procesamiento. Como en los módulos anteriores, debe llamarsede forma periódica a la función SDO_Process para que el sistema funcione.

SDO module

Parsear mensaje

Generar respuesta

sdo_send_reply_message

Circularbuffer

Diccionariode objetos

Bus CAN

SDO_Client_Request_Received

Poner

Sistemaoperativo

SDO_Init sdo_listen_as_server

SDO_Process()Sacar

Leer/escribir

Llegó un pedidode un cliente

Se le envía larespuesta

FIGURA 3.11: Diagrama de secuencia de un servidor SDO ante lallegada de un mensaje.

En la figura 3.12 se observa el envío de un mensaje por parte de un cliente SDOy el procesamiento de la respuesta. El pedido puede ser iniciado por cualquierotro módulo del programa que necesite información de un nodo remoto, siemprey cuando tenga el cob_id del servidor al que se le quiere hablar.


Como se ha visto en el capítulo 2.3.5 existen dos tipos de PDO, los RPDO y losTPDO. La implementación de los RPDO, que puede observarse en la figura 3.13,consiste en escuchar un cob_id determinado al que le llegarán los mensajes. Comoel módulo soporta el cambio de parámetros y mapeo en tiempo de ejecución, esposible desuscribirse de un cob_id y suscribirse a uno nuevo cuando se requiera.


SDO module

Generar comando

Parsear respuesta

Bus CAN

SDO_Server_Response_Received

Sistemaoperativo

SDO_Init sdo_listen_as_client

Llegó larespuesta delservidor

SDO_Send_Request_To_Server (cob_id)

sdo_send_message (cob_id)

Se envía unpedido a unservidor

Otro módulode CANopen

devolver respuesta

FIGURA 3.12: Diagrama de secuencia de un cliente SDO duranteel envío de un mensaje.

El envío de un TPDO resultó la implementación más compleja de todo el stackCANopen. El proceso está dividido en tres partes ejecutadas secuencialmentedentro de la función motora PDO_Process:

Verificar si los nuevos valores de entrada generan una interrupción.

Contrastar las entradas en interrupción contra las entradas mapeadas encada TPDO.

Enviar cada TPDO que tenga una entrada en interrupción mapeada.

El primer proceso es dependiente de las entradas que tenga el hardware utilizadoy del perfil que implemente el diccionario de objetos. Un ejemplo de asociaciónpara el perfil DS401 se puede ver en el algoritmo 3.11.

1 # def ine PDO_AVAILABLE_INPUT_DIGITAL_SIGNALS \2 X( P6_1 , PDO_TYPE_INPUT, GPIO0 , "GPIO0" ) \3 X( P6_4 , PDO_TYPE_INPUT, GPIO1 , "GPIO1" ) \4 X( P6_5 , PDO_TYPE_INPUT, GPIO2 , "GPIO2" ) \5 X( P6_7 , PDO_TYPE_INPUT, GPIO3 , "GPIO3" ) \6 X( P1_0 , PDO_TYPE_INPUT, TEC1 , "TEC1" ) \7 X( P1_1 , PDO_TYPE_INPUT, TEC2 , "TEC2" ) \8 X( P1_2 , PDO_TYPE_INPUT, TEC3 , "TEC3" ) \9 X( P1_6 , PDO_TYPE_INPUT, TEC4 , "TEC4" )

ALGORITMO 3.11: asociación de entradas a los tpdo.

A esta definición se le aplica una X-macro para asociarlas con el registro 0x6000que, en el diccionario de objetos, corresponde a Read Input 8-Bit. La X-macro haráque el bit cero del registro 0x6000 se corresponda con el valor leído en GPIO0, elbit uno con GPIO1, etc.

En la figura 3.14 se ve esquematizado el proceso que se le hace a la entrada paradetectar interrupciones de flanco ascendente, el bit en rojo simboliza un cambioen una entrada digital con respecto al último estado leido. Lo mismo se hará paralas interrupciones de flanco descendente, ambos flancos y todas las operacionesque defina el estándar DS401. A continuación se ve el algoritmo que implementael esquema de la figura.


PDO

escuchar mensaje

Procesar rpdo

Diccionariode objetos

Bus CANSistemaoperativo

rpdo callout

pdo_init_rpdo

rpdo parameter changed

suscribir(cob_id nuevo)

desuscribir (cob_id viejo)

Mensaje recibidopor un rpdo

Cambio de cob_idque se escuchaen este rpdo

FIGURA 3.13: Diagrama de secuencia de la recepción de un RPDO.

1 /∗ Hay que chequear l a s condic iones de t r i g g e r para cada s e n i a l ∗/2

3 /∗ Chequeamos l a condicion de f l a n c o descendente4 ∗ La operacion es ( V i e j a & Nueva_Negada ) b i t a b i t5 ∗/6 aux = old_value & (~ new_value ) ;7

8 /∗ Se compara contra l a mascara de s e n i a l e s h a b i l i t a d a s para f l a n c odescendente

9 ∗ o cua lquier f l a n c o10 ∗/11 u i n t 8 _ t d i g i t a l _ i n p u t _ t r i g g e r _ a u x = ( aux & p_tr igger_high_to_low [ i ] )

|12 ( aux & p_trigger_any_change [ i ] ) ;13

14 /∗ Chequeamos ahora f l a n c o ascendente o cua lquier cambio ∗/15

16 aux = (~ old_value ) & new_value ;17

18 /∗ Se compara contra l a mascara de s e n i a l e s h a b i l i t a d a s para f l a n c oascendente

19 ∗ o cua lquier f l a n c o y se hace l a OR con e l valor a n t e r i o r20 ∗/21 d i g i t a l _ i n p u t _ t r i g g e r _ a u x = d i g i t a l _ i n p u t _ t r i g g e r _ a u x |22 ( aux & p_tr igger_low_to_high [ i ] ) |23 ( aux & p_trigger_any_change [ i ] ) ;24

25 /∗ Lo escr ib imos en e l r e g i s t r o in terno del OD ∗/26 OD_Set_Digital_Input_Triggered_By_Byte ( i , d i g i t a l _ i n p u t _ t r i g g e r _ a u x )

;

ALGORITMO 3.12: detección de interrupciones en las entradas.


00001010

00010000

00001010

00011010 00010000

Registro 0x6000,Valor de lasentradas leído en8bits.Cada bitrepresenta unaentrada distinta

Detector deflancoascendente(por bit)

10110110

Registro 0x6008,habilitación deinterrupción porflanco ascendente(por bit)

AND

00010000

Registro0x6002, cambio depolaridad (porbit)

Valor anterior de lasentradas, guardado enmemoria

1Registro 0x6005,habilitación global delas interrupciones(único byte)

00010000

¡¡El registro 0x6000dispara unainterrupción!!

XOR

FIGURA 3.14: Detección de interrupción de una entrada.

El segundo paso del proceso consiste en chequear si la entrada que generó lainterrupción está presente en el mapeo de algún TPDO. Esto se hace con un doblebucle como muestra el pseudocódigo del siguiente algoritmo.

1 Para todos l o s TPDO configurados2 Para todos l o s r e g i s t r o s mapeados en ese TPDO3 S i registro_mapeado == r e g i s t r o _ c o n _ i n t e r r u p c i o n entonces enviar

TPDO

ALGORITMO 3.13: pseudocodigo para buscar si hay algun tpdocon un registro específico mapeado.

No hay límite para la cantidad de TPDOs que pueden tener un registro mapeado.Incluso puede ocurrir que un registro en interrupción no este mapeado en nin-gún TPDO. Es decir que la cantidad de TPDOs enviados es independiente de lacantidad de registros en interrupción.

El tercer paso implica tomar todos los valores mapeados en el TPDO para generarel mensaje de salida. Esto es realizado en la función pdo_load_tpdo por un buclecomo indica el siguiente algoritmo.

1 s t a t i c void pdo_load_tpdo ( pdo_tpdo_t ∗ p_tpdo )2 3 . . .4 u i n t 8 _ t total_number_of_mappings = tpdo_mapping−>subindex_0 ; /∗ La

cantidad siempre es e l subindice 0 ∗/5 f o r ( u i n t 3 2 _ t mapping_subindex = 0 ; mapping_subindex <

total_number_of_mappings ; mapping_subindex++) 6 /∗ Copio a l b u f f e r segun e l mapeo configurado , en l a s i g u i e n t e

llamada l e pasa e l i n i c i o7 ∗ de l a parte l i b r e del b u f f e r corriendome l a cantidad de

bytes ya copiados


8 ∗/9 copied_bytes += od_fi l l_mapping ( tpdo_mapping−>mapping [

mapping_subindex ] , b u f f e r + copied_bytes ) ;10 11

ALGORITMO 3.14: función que carga el tpdo en el buffer de envío.

Finalmente, el TPDO es envíado por la función pdo_send_tpdo.

De esta forma se cierra la explicación del diseño de la solución desarrollada y acontinuación en el capítulo 4 se presentan los ensayos realizados y los resultadosobtenidos.

33

Capítulo 4

Ensayos y Resultados

En esta sección se detallan los ensayos y mediciones realizados para validar eldiseño y ruteo del hardware CAN y la correcta implementación de la bibliotecaCAN-bus y el protocolo CANopen.

4.1. Interfaz física

Para validar el correcto funcionamiento del poncho CAN se armaron dos proto-tipos y se conectó cada uno a una EDU-CIAA-NXP. Se generó una red CAN conambas placas y un sniffer CAN conectado a una PC y se utilizó un osciloscopiopara tomar las mediciones del bus. El banco de mediciones final se puede ver enla figura 4.1.

Poncho CAN Poncho CAN

Sniffer

CANH

CANL

OsciloscopioTramas

CAN

FIGURA 4.1: Banco utilizado para medir la interfaz física del pon-cho.

Se configuró una de las placas para enviar periódicamente la trama de heartbeatde la figura 4.2.

34 Capítulo 4. Ensayos y Resultados

12CRC

ACKEOF

1b2b

CRC

0

11b

C

4b

DatosId RTRSOF

1b 1b 1b 16b

7F7FF 00

DLC

1

3b

FIGURA 4.2: Trama de heartbeat a enviar durante la prueba dehardware.

La medición tomada con el osciloscopio se presenta en la figura 4.3. Ambas se-ñales CANL y CANH se ajustan perfectamente a lo esperado, centradas en 2,5Vpara significar un bit recesivo y generando una diferencia de potencial para unbit dominante. La señal matemática se obtuvo en el osciloscopio con la operaciónCANH −CANL, los bits dominantes se observan con 0 y los recesivos con un 1.Es de notar que no se ve ruido en esta señal, lo que indica que los resistores determinación funcionan correctamente.

FIGURA 4.3: Niveles de señal sobre el bus CAN.

La figura 4.4 posiciona los cursores sobre el bit de inicio de trama. Se puede obser-var que su duración de 8µs se condice con la configuración del bus como HIGH-SPEED CAN 125kbps en la ecuación 4.1

tbit(s) =1

speed(kbps)(4.1)

Finalmente, con el tiempo de bit conocido es posible decodificar la trama com-pleta, como muestra la figura 4.5 y comprobar que la información es la esperadasegún la figura 4.2

4.2. Biblioteca CAN-bus 35

FIGURA 4.4: Tiempo de bit en la comunicación CAN.

FIGURA 4.5: Decodificación de la trama de heartbeat.

4.2. Biblioteca CAN-bus

El funcionamiento de la biblioteca CAN-bus desarrollada se probó diseñando yejecutando un algoritmo que utilice todas las funcionalidades y APIs expuestas:

Configuración de interfaz CAN1 y CAN2.

Recepción de un mensaje CAN por encuesta.

Recepción de un mensaje CAN por callout.

Envío de un mensaje CAN de forma sincrónica.

Envío de un mensaje CAN de forma asincrónica.

Suscripción a mensajes CAN en tiempo de compilación.


Suscripción a mensajes CAN en tiempo de ejecución.

Desuscripción de mensajes CAN en tiempo de ejecución.

El banco de pruebas utilizado consta de tres nodos CAN independientes, cadauno con su propio código y conectados como se indica en la figura 4.6. El snifferCAN se utilizó para verificar que las tramas en el bus se condigan con lo reporta-do por cada placa.

Placa 2 Placa 3

Sniffer

CANH

CANL

Placa 1

TramasCAN

FIGURA 4.6: Banco de pruebas para la biblioteca CAN-bus.

Para cubrir todos los casos se diseñó una prueba según el diagrama de secuen-cia de la figura 4.7. Es importante notar que los mensajes CAN enviados llegansiempre a todos los nodos, aunque para simplificar el diagrama sólo se han dibu-jado las transacciones que aportan información a la prueba. La falta de aviso derecepción de un id al que no se estaba suscripto, significa que la biblioteca CANfunciona correctamente. Para hacer la prueba más completa cada trama enviadatiene un cantidad aleatoria de bytes de datos y cada dato también es generado deforma aleatoria.

Otra variación que se agrega es que algunos mensajes serán suscriptos en tiem-po de compilación y otros de forma dinámica, asimismo algunos mensajes seránrecepcionados por un callout y otros por encuesta en el lazo principal. La configu-ración de los mensajes puede verse en la tabla 4.1.

Durante la ejecución del programa cada placa genera un log por su terminal se-rie indicando el evento ocurrido junto a una marca de tiempo. En la figura 4.7se pueden observar todos los eventos reportados por las tres placas ordenadostemporalmente, la indicación de la placa que lo generó y su detalle. Para facilitarla visualización, se resaltó cada linea según la placa que la genera:

Azul: placa uno.

Verde: placa dos.

4.2. Biblioteca CAN-bus 37

Placa 1 Placa 2

Suscribir ID 0x103

Desuscribir ID 0x100Enviar ID 0x100 al bus

Placa 3

Suscribir ID 0x104

Desuscribir ID 0x101

Enviar ID 0x101 al bus

Enviar ID 0x102 al bus

Enviar ID 0x100 al busEnviar ID 0x103 al bus

Enviar ID 0x101Enviar ID 0x104

El mensaje nodebe recibirse

El mensaje nodebe recibirse

FIGURA 4.7: Diagrama de secuencia para la prueba de la bibliotecaCAN-bus.

TABLA 4.1: configuración de mensajes.

Id Tipo de suscripción Forma de recepción Forma de envío

0x100 Estática Encuesta Sincrónica0x101 Estática Callout Sincrónica0x102 Dinámica Encuesta Sincrónica0x103 Dinámica Callout Asincrónica0x104 Dinámica Callout Asincrónica

Marrón: placa tres.

Fue necesario asegurarse que las marcas de tiempo sean consecuentes entre sí,por lo que se liberó el reset de las tres placas de forma sincrónica.

La secuencia de eventos observada en la figura 4.8 se condice perfectamente conla definida por el diagrama de secuencia de la figura 4.7 y los campos de datosenviados y recibidos son exactamente iguales. Por ejemplo en la línea dos se vi-sualiza el envío del primer mensaje a la red con id 0x100, este mensaje es recibidopor la placa dos, pero no por la placa tres. La placa dos procede a desuscribirsedel id y suscribirse al id nuevo en las líneas cuatro y cinco, más adelante en lalínea once el id 0x100 es nuevamente enviado, pero esta vez nadie lo recibe.


FIGURA 4.8: Captura de eventos en prueba CAN-bus.

4.3. Implementación CANopen

Al igual que con la biblioteca CAN-bus el protocolo CANopen se probó ejecutan-do escenarios personalizados que cubran las características del mismo. Por clari-dad y dado que la cantidad de funcionalidades es mayor que con la biblioteca, seseparará cada prueba en una subsección diferente.

4.3.1. Heartbeat

Para demostrar el uso del heartbeat se utilizó el banco de medición de la figura4.6. El valor por defecto del diccionario de objetos de cada nodo se puede ver en latabla 4.2. Los tres nodos producirán un heartbeat, cada uno a distinta frecuenciapara facilitar su visualización. La placa uno será la encargada de controlar que losdemás nodos envíen su heartbeat periódicamente, en caso que el tiempo expiresin la llegada del mensaje, se le mandará un comando para resetear completamen-te la placa.

En la figura 4.9 pueden verse los logs de las tres placas durante funcionamientonormal combinados temporalmente y con el código de colores antes descripto. Enlas líneas dos y tres se observa como la placa uno se configura para monitorearlos heartbeats de los otros dos nodos y en las líneas cinco y diez como el propiomensaje de heartbeat es enviado. En las líneas seis y once se ve el envío del heart-beat de la placa dos, separados cada 4500 ms y su correspondiente recepción en

4.3. Implementación CANopen 39

TABLA 4.2: Configuración por default del heartbeat en el OD.

Característica Registro del OD Placa 1 Placa 2 Placa 3

Id del nodo 0x33 0x44 0x55Hb productor (ms) 0x1017 3500 4500 5000Hb consumidor (ms) 0x1016 10000, 12000 0 0Nodo consumidor 0x1016 0x44, 0x55 x x

las líneas siete y doce. El mismo comportamiento se observa para la placa tres enlas líneas seis y once.

En la figura 4.10 se muestra el caso en que una placa deja de enviar su heartbeat.Para simular esta condición se agregó lógica a la placa dos para dejar de transmitirmensajes luego del cuarto envío. En la línea uno figura la última transmisión dela placa dos alrededor de los 13,5 segundos, la placa uno detecta que expiró eltiempo de espera en la línea cuatro a los 23.5 segundos, esto se condice con los 10segundos configurados en el diccionario de objetos. La placa uno procede a enviarun comando de reset que es recibido y ejecutado, a continuación en la línea ochola placa dos luego de su inicialización reanuda su envío periódico.

FIGURA 4.9: Inicialización y monitoreo de heartbeat en funciona-miento normal.

FIGURA 4.10: Detección de error en heartbeat monitoreado.



El funcionamiento del NMT se probó inyectando los comandos de cambio demodo con el sniffer sobre la placa uno. Se recuerda que según lo explicado enla sección 3.4.1, cada nodo pasa automáticamente del estado initializing a pre-operational una vez terminado el periodo de booteo. La secuencia usada puedeverse en la figura 4.11, de pre-operational pasará a operational, luego a stoppedpara terminar en operational.

1

Pre-operational

2

Operational

3

Stopped

Automático

Initializing

FIGURA 4.11: Secuencia del network management a inyectar en elsistema.

En la figura 4.12 se observa la captura del log de la prueba. La línea dos indicael traspaso de initializing a pre-operational, habilitando la emisión y recepciónde mensajes de heartbeat y SDO. A partir de la línea cuatro se pasa al estadooperational, habilitando también los PDO. En la línea ocho se va al estado destopped, en donde solo el heartbeat queda disponible. Finalmente, se vuelve alestado operational en la línea once.


Para la prueba de los SDO, se realizó la lectura y escritura del valor de tiempo deheartbeat de la placa dos, que ofició de servidor, por parte de la placa uno, queofició de cliente. El registro correspondiente es el 0x1017 y el valor asignado pordefault es de 4500 ms como puede verse en la tabla 4.2.

La captura de la información ordenada temporalmente se encuentra en la figura4.13, por claridad se eliminaron los logs de la placa tres y logs que no aporten a laprueba en curso.

Las líneas uno y dos especifican los roles que tomarán ambas placas durante elintercambio SDO. Como se explicó en la sección 2.3.4, solo puede haber un clienteen la red mientras que pueden existir múltiples servidores. La diferencia de tiem-pos entre la línea cinco y seis indica el ritmo de producción de heartbeat actual. A


FIGURA 4.12: Pogresión de la máquina de estados del networkmanagement.

continuación comienza el intercambio SDO, en primer lugar la placa uno hace unpedido de lectura que es recibido e interpretado por la placa dos en la línea ocho,la respuesta en la línea nueve indica que hay dos bytes de datos validos 0x1194que correspone a los 4500 ms antes mencionados. En las líneas doce y trece seencuentra el pedido de escritura, también de dos bytes, 0x2710 que correspondea 10000 ms. El nuevo valor es aplicado instantáneamente y el siguiente envío delheartbeat se produce 10000 ms después en la línea quince.


La implementación de los PDO fué la más compleja dentro de todos los compo-nentes del protocolo CANopen, ya que comprendió una gran cantidad de funcio-nalidad mandatoria del estándar DS401 [22]. Por la gran cantidad de pruebas rea-lizadas se decidió mostrar la que se considera la más importante, la verificacióndel funcionamiento de los TPDO/RPDO así como los registros fundamentales delestándar mencionado.

Utilizando como base el banco de pruebas 4.6, se le asignó a la placa uno el rolde receptora de los mensajes. La placa dos tendrá conectada en su canal de entra-da analógico CH1 un potenciómetro, que simulará una entrada de señal externaanalógica. La placa tres hará uso de los pulsadores para simular diferentes en-tradas digitales. Estas dos últimas placas utilizarán sus leds para simular salidasdigitales.

La placa dos tendrá configurado un TPDO mapeado al registro de lectura de en-tradas analógicas de 16 bits, registro 0x6401. Es decir que cada vez que se debaenviar el TPDO se estará enviando el valor de la conversión del CH1. El envío delTPDO será comandado por una interrupción, que se disparará cuando el valorconvertido esté por fuera de un rango configurado. Los valores elegidos puedenverse en la tabla 4.3. El TPDO tiene asignado un inhibit time de dos segundos, pa-ra no llenar el bus de mensajes al cambiar la medición en más/menos una cuentapor culpa del ruido.


FIGURA 4.13: Pedido de lectura y escritura del heartbeat a travésde un SDO.

La placa tres tendrá activada la interrupción por flanco ascendente y descenden-te y mapeado el registro 0x6000 que corresponde a lectura de señales de 8 bits.Es decir que cada vez que se active una interrupción, se enviarán 8 bits con losvalores leídos de los cuatro pulsadores y los GPIO0 a GPIO3.

La placa uno no tendrá ningún TPDO asignado, sino que recibirá en sus RPDOslos mensajes provenientes de las otras placas. Una vez recibido el mensaje se en-viará a la placa opuesta la orden de encender un led a través de un SDO. Es decirque apretar un botón en la placa tres encenderá el led próximo al botón de la pla-ca dos. Igualmente en el sentido inverso, al irse la señal analógica del rango detrabajo se encenderá un led en la otra placa.

La captura en la figura 4.14 muestra cada nodo inicializando sus registros deTPDO o RPDO según corresponda.

FIGURA 4.14: Configuracion de los RPDO y TPDO en cada placa.

La figura 4.15 muestra la secuencia al presionarse una pulsador en la placa tres.En las líneas uno, dos y tres el programa detecta el cambio de la entrada, dispara


TABLA 4.3: Configuración de los registros asociados a los PDO.

Característica Registro del OD Placa 1 Placa 2 Placa 3

Id del nodo 0x33 0x44 0x55TPDO1 0x1800 No usado 0x1C4 0x1D5RPDO1 0x1400 0x1C4 No usado No usadoRPDO2 0x1401 0x1D5 No usado No usadoFlanco int. 0x6006 N/A N/A AmbosLímite superior 0x6424 N/A 250 N/ALímite inferior 0x6425 N/A 750 N/AMapeo 0x1A00 N/A 0x6401 0x6000

la interrupción y envía el TPDO, que es recibido por la placa uno en la línea cuatroe interpretado en la línea cinco y seis. En la línea siete se envia el SDO a la placados para indicar el encendido del led correspondiente. De las líneas nueve al finalse ve la misma secuencia al soltar el pulsador.

FIGURA 4.15: Captura del intercambio PDO ante una interrupciónde entrada digital.

La figura 4.16 muestra la misma secuencia para la placa dos y la señal analógicade entrada. Como resultado, cuando el valor esta por debajo del limite configu-rado, se enciende el led amarillo de la placa tres, cuando el valor esta por encimadel límite superior se encenderá el led verde.


FIGURA 4.16: Captura del intercambio PDO ante una interrupciónde entrada analógica.

4.4. Comparación con estado del arte

Una comparación detallada de las características del stack CANopen desarrolladocontra los otros stacks de código libre citados en 1.3, puede verse en las tablas 4.4y 4.5.

Se observa una variación muy grande entre las prestaciones de los productos cu-ya principal plataforma de ejecución es un sistema embebido y entre los que no.Aunque no es parte del alcance de este trabajo hacer un análisis de la extensiónmáxima que puede tener por ejemplo el diccionario de objetos es claro que ellímite estará dado por la cantidad de RAM disponible, es así que es posible corre-lacionar la mayor cantidad de prestaciones contra la mayor cantidad de recursosdisponibles. La tabla no contempla si todas las prestaciones mencionadas estarándisponibles al compilarlos para un entorno de menores recursos, ya que la infor-mación no es evidente en la documentación provista por los desarrolladores.

De toda la información recabada se observa que el stack más similar al del trabajoes CANopenNode, especialmente porque apunta a entornos embebidos con ar-quitecturas similares a la propia, aunque con un nivel de maduración superior yaque está en desarrollo desde el año 2015.

Como nota final, es importante aclarar que para este análisis se han listado lascaracterísticas que cada desarrollador declara soportar pero no se han probado oinvestigado el nivel de madurez real de cada proyecto.

No se hará ningún análisis sobre la biblioteca CAN-bus ya que como se ha men-cionado en 1.3 no hay desarrollos similares contra los cuales comparar.

Por último, en la tabla 4.6 se presenta una comparativa entre el hardware desa-rrollado y las placas presentadas en el capítulo 1.3:

El hardware desarrollado tiene las siguientes ventajas sobre las otras placas pre-sentadas:

4.4. Comparación con estado del arte 45

TABLA 4.4: Comparación de características de distintos stacksCANopen.

CaracterísticasCIAA

CANopenMicro

CANopenCan

Festival

Máquina de estados del NMT Sí Sí SíCapacidad de ser maestro NMT Sí No SíProductor de heartbeat Sí Sí SíConsumidor de heartbeat Sí No SíProductor de objetos de emergencia No No SíConsumidor de objetos de emergencia No No SíCarga estática del OD por archivo No No SíCarga dinámica del OD por archivo No No NoParametros de PDO dinámicos Sí Sí SíMapeo de PDO dinámicos Sí Sí SíTPDO disparado por eventos Sí No SíTPDO disparado por mensaje SYNC Sí Sí SíTiempo de inhibición en TPDO Sí Si SíCliente SDO Sí No SíTransferencia SDO expeditiva Sí Sí SíTransferencia SDO segmentada No No SíDiseñado para sistemas embebidos Sí Si No

Conexión robusta al encastrar sobre la EDU-CIAA-NXP.

Conector de acuerdo al estándar ISO 11898-3:2006.

Diodos de protección en las líneas de bus compartidas.

Costo bajo.


TABLA 4.5: Comparación de características de distintos stacksCANopen (Cont.).

CaracterísticasCANopen

NodeLely

CANopenOpen

CANopen

Máquina de estados del NMT Sí Sí SíCapacidad de ser maestro NMT Sí Sí SíProductor de heartbeat Sí Sí SíConsumidor de heartbeat Sí Sí SíProductor de objetos de emergencia No Sí NoConsumidor de objetos de emergencia No Sí NoCarga estática del OD por archivo Sí Sí NoCarga dinámica del OD por archivo No Sí SíParametros de PDO dinámicos Sí Sí SíMapeo de PDO dinámicos Sí Sí SíTPDO disparado por eventos Sí Sí SíTPDO disparado por mensaje SYNC Sí Sí SíTiempo de inhibición en TPDO Sí Sí SíCliente SDO Sí Sí SíTransferencia SDO expeditiva Sí Sí SíTransferencia SDO segmentada Sí Sí SíDiseñado para sistemas embebidos Sí No No

TABLA 4.6: Comparación de características de distintos módulosCAN.

Característica MKR CANShield Tja1050 MAX13054A

SHIELD Poncho CAN

Modelo transceptor tja1049 tja1050 MAX13054A tja1051Controlador integrado Sí No No NoVelocidad máxima (Mbp/s) 5 1 2 5Soporte de CANtolerante a fallos No No Sí No

Conector interfazcon EDU-CIAA-NXP No No No Sí

Protección contra ESD No No Sí SíProtección térmica No No Sí NoProtección contracorto-circuito No No Sí No

Conector compatiblecon DS-102 No No No Sí

Precio (USD) 36 5 100 7 (estimado)

47

Capítulo 5

Conclusiones

En este capítulo se realiza un repaso de las tareas completadas y pendientes, sehace mención a los conocimientos de la especialización utilizados y los próximospasos del proyecto.

5.1. Conclusiones generales

El trabajo ha cumplido satisfactoriamente los siguientes puntos planteados en laplanificación:

Biblioteca CAN-Bus fácilmente integrable en la sAPI.

Poncho CAN diseñado para la EDU-CIAA-NXP según estándar ISO 11898-3:2006.

Implementación dentro del protocolo CANopen de la funcionalidad SDO,NMT y heartbeat.

Los siguientes puntos, pese a no estar en la planificación original, se han juzga-do imprescindibles conforme avanzó el entendimiento del protocolo CANopen yhan sido satisfactoriamente implementados:

Agregado de los objetos TPDO y RPDO.

Configuración dinámica de los parámetros y mapeos de los TPDO y losRPDO.

Diccionario de objetos acorde a la norma DS401.

Para el satisfactorio desarrollo del trabajo fueron esenciales los siguientes conoci-mientos adquiridos durante la cursada:

Programación de microprocesadores: en esta materia se estudiaron los pa-trones productor/consumidor y diseños de máquinas de estado utilizadosen el proyecto.

Sistemas operativos de tiempo real (I) y (II): lo aprendido en esta materiadefinió la estructura general del programa y la separación en diferentes ta-reas para ser ejecutadas por un sistema operativo.

Diseño de circuitos impresos: a lo largo de esta materia se diseñó el ponchoCAN presentado.

48 Capítulo 5. Conclusiones

5.2. Próximos pasos

5.2.1. Sobre el proyecto actual

Aunque no se plantearon como requisitos al diseñar y escribir el software, se hatratado siempre de perseguir los atributos de calidad de legibilidad y mantenibi-lidad [24]. Se han identificado dos módulos que deberían ser refactorizados paracumplir con los estándares esperados:

Agregar una capa de abstracción que separe la aplicación de los PDO.

Separar el diccionario de objetos entre las funciones básicas del diccionarioy las particulares del estándar DS401.

5.2.2. Trabajo futuro

Para completar la implementación de CANopen y de la biblioteca CAN-bus desa-rrollada se deben realizar las siguientes tareas:

Completar el diccionario de objetos con parámetros faltantes.

Agregar otros registros de estándar DS401 que apliquen a la EDU-CIAA-NXP.

Agregar los filtros de aceptación a la biblioteca CAN-bus.

Por último, es importante mencionar que si se desea que la implementación desa-rrollada sea fácilmente extensible a otros estándares diferentes al DS401, se debehacer un refactor completo de la implementación actual de los PDO y del dic-cionario de objetos, aplicando los conocimientos aprendidos durante el trabajorealizado.

49

Bibliografía

[1] Robert Bosch y col. CAN specification version 2.0. 1991.[2] M. Di Natale y col. Understanding and Using the Controller Area Network

Communication Protocol: Theory and Practice. Springer New York, 2012. ISBN:9781461403135. URL:https://books.google.com.ar/books?id=AJn-vSOL\_3EC.

[3] CiA. CAN in Automation. https://www.can-cia.org/. Mar. de 2020.(Visitado 26-03-2020).

[4] Arduino. Sitio principal de la plataforma arduino. https://www.arduino.cc/.Mar. de 2020. (Visitado 20-03-2020).

[5] Arduino. Shield arduino para CAN.https://store.arduino.cc/usa/mkr-can-shield. Mar. de 2020. (Visitado20-03-2020).

[6] LC Technology. Transceiver CAN. https://arduino-shop.eu/arduino-platform/1170-tja1050-can-controller-interface.html. Mar. de 2020.(Visitado 20-03-2020).

[7] MAXIM Integrated. Evaluation Kit for the MAX10354A.https://www.maximintegrated.com/en/products/interface/transceivers/MAX13054AESHLD.html/tb_tab0. Mar. de 2020. (Visitado30-03-2020).

[8] Maxim Integrated. Maxim Integrated.https://www.maximintegrated.com/en.html. Mar. de 2020. (Visitado30-03-2020).

[9] NXP. Bibliotecas de LPCOpen.https://www.nxp.com/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES.Mar. de 2020. (Visitado 20-03-2020).

[10] O. Pfeiffer, A. Ayre y C. Keydel. Embedded Networking with CAN andCANopen. Copperhill Technologies Corporation, 2008. ISBN:9780976511625. URL:https://books.google.com.ar/books?id=CstN61COZe4C.

[11] CANFestival. Free softwre CANopen framework. https://canfestival.org/.Mar. de 2020. (Visitado 20-03-2020).

[12] CANopenNode. Free and open source CANopen Stack.https://github.com/CANopenNode/CANopenNode. Mar. de 2020.(Visitado 20-03-2020).

[13] Lely CANopen. A feature-rich, open-source stack of industrial quality.https://opensource.lely.com/canopen/. Mar. de 2020. (Visitado20-03-2020).

[14] OpenCANopen. https://github.com/marel-keytech/openCANopen.Mar. de 2020. (Visitado 20-03-2020).

[15] Proyecto CIAA. Computadora Industrial Abierta Argentina. Visitado el2016-06-25. 2014. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

https://books.google.com.ar/books?id=AJn-vSOL\_3EC

https://www.can-cia.org/

https://www.arduino.cc/

https://store.arduino.cc/usa/mkr-can-shield

https://arduino-shop.eu/arduino-platform/1170-tja1050-can-controller-interface.html

https://arduino-shop.eu/arduino-platform/1170-tja1050-can-controller-interface.html

https://www.maximintegrated.com/en/products/interface/transceivers/MAX13054AESHLD.html/tb_tab0

https://www.maximintegrated.com/en/products/interface/transceivers/MAX13054AESHLD.html/tb_tab0

https://www.maximintegrated.com/en.html

https://www.nxp.com/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES

https://www.nxp.com/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES

https://books.google.com.ar/books?id=CstN61COZe4C

https://canfestival.org/

https://github.com/CANopenNode/CANopenNode

https://opensource.lely.com/canopen/

https://github.com/marel-keytech/openCANopen

http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start

50 BIBLIOGRAFÍA

[16] EDU-CIAA-NXP. Plataforma educativa del Proyecto CIAA.http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp. Mar. de 2020. (Visitado 26-03-2020).

[17] Eric Pernia. Biblioteca sAPI. https://github.com/epernia/sapi. Mar. de2020. (Visitado 26-03-2020).

[18] International Standardization Organization. Road vehicles — Controller areanetwork (CAN) - Part 1. Dic. de 2015. URL:https://www.iso.org/standard/63648.html (visitado 26-03-2020).

[19] H. Zimmermann. «OSI Reference Model–The ISO Model of Architecturefor Open Systems Interconnection». En: Communications, IEEE Transactionson [legacy, pre - 1988] 28.4 (1980), págs. 425-432.

[20] CAN in Automation. CiA 102 version 3.0.0. Feb. de 2010. URL:https://www.can-cia.org/groups/specifications/ (visitado 26-03-2020).

[21] CAN in Automation. CiA 301 version 4.2.0. Feb. de 2011. URL:https://www.can-cia.org/groups/specifications/ (visitado 26-03-2020).

[22] CAN in Automation. Device Profile for Generic I/O Modules v3.0.0. Jun. de2008. URL: https://www.can-cia.org/can-knowledge/canopen/cia401/(visitado 20-03-2020).

[23] Andrew Lucas. Reduce C-language coding errors with X macros – Part 1.https://www.embedded.com/reduce-c-language-coding-errors-with-x-macros-part-1/. Mar. de 2020. (Visitado 24-03-2020).

[24] L. Bass, P. Clements y R. Kazman. Software Architecture in Practice: SoftwareArchitect Practice_c3. SEI Series in Software Engineering. PearsonEducation, 2012. ISBN: 9780132942782. URL:https://books.google.com.ar/books?id=-II73rBDXCYC.

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp

https://github.com/epernia/sapi

https://www.iso.org/standard/63648.html

https://www.can-cia.org/groups/specifications/

https://www.can-cia.org/groups/specifications/

https://www.can-cia.org/can-knowledge/canopen/cia401/

https://www.embedded.com/reduce-c-language-coding-errors-with-x-macros-part-1/

https://www.embedded.com/reduce-c-language-coding-errors-with-x-macros-part-1/

https://books.google.com.ar/books?id=-II73rBDXCYC

implementación de biblioteca can para sapi

Documents