CAN Driver (Can)

La función síncrona y no reentrante Can_Init inicializa la totalidad del módulo controlador CAN, así como las unidades de hardware correspondientes, según la configuración transferida [SWS_Can_00223].

Uso y contexto de llamada

La llamada de Can_Init la realiza obligatoriamente el ECU State Manager durante la fase de inicio de la unidad de control, antes de que se permita invocar cualquier otra función del controlador CAN [SWS_Can_91012]. Como parámetro, la función recibe a través de Config un puntero a la configuración del controlador (const Can_ConfigType*) y no devuelve ningún valor de retorno [SWS_Can_00223].

Alcance de inicialización y transiciones de estado

En el marco de la inicialización, la función establece todos los registros de hardware necesarios e inicializa todos los controladores CAN AUTOSAR_SWS_CANDriver p. 33:

• inicialización de variables estáticas y flags internos [SWS_Can_91012],
• configuración de ajustes comunes para la unidad de hardware CAN completa [SWS_Can_91012],
• ajustes específicos de controlador para cada controlador CAN individual [SWS_Can_91012].

Mediante la llamada a la función se desencadenan transiciones de estado del hardware CAN AUTOSAR_SWS_CANDriver p. 10, en las que Can_Init realiza la configuración de registros para pasar los controladores al estado básico previsto [SWS_Can_91010] AUTOSAR_SWS_CANDriver p. 36.

Concurrencia y restricciones

Dado que Can_Init está especificada como no reentrante, no debe tener lugar ninguna llamada paralela o repetida durante una inicialización en curso [SWS_Can_00223]. Además, determinados ajustes globales de la unidad de hardware solo pueden configurarse dentro de Can_Init AUTOSAR_SWS_CANDriver p. 33.

La función Can_DeInit sirve para la desinicialización del módulo del controlador de CAN ([SWS_Can_91002]). Posee la firma void Can_DeInit(void), no acepta parámetros, no devuelve ningún valor y se ejecuta de forma síncrona y no reentrante ([SWS_Can_91002]). La interfaz está disponible a través de la cabecera Can.h ([SWS_Can_91002]).

La llamada inicia una transición de estado controlada por software (AUTOSAR_SWS_CANDriver p. 10; AUTOSAR_SWS_CANDriver p. 41). En este proceso, Can_DeInit cambia el estado del módulo (AUTOSAR_SWS_CANDriver p. 33) y restablece todos los controladores de CAN (AUTOSAR_SWS_CANDriver p. 41).

Concurrencia y restricciones

Para la ejecución se aplican estrictas precondiciones y requisitos de secuencia respecto a los estados del hardware y del módulo:

• El invocador debe asegurarse de que ningún controlador de CAN se encuentre en un estado no permitido (AUTOSAR_SWS_CANDriver p. 61); presumiblemente, los procesos de comunicación activos deben haber finalizado previamente. Pregunta Q-311343fa42add3a3 (abierta)
• Si el módulo CAN no se encuentra en el estado inicial requerido en el momento de la llamada (AUTOSAR_SWS_CANDriver p. 41), la función notifica el error CAN_E_TRANSITION (AUTOSAR_SWS_CANDriver p. 61).
• Asimismo, se desencadena el error CAN_E_TRANSITION si un controlador de CAN permanece en un estado que impide la desinicialización (AUTOSAR_SWS_CANDriver p. 61). Interpretación: es probable que el controlador presuponga un estado detenido de todos los controladores antes de la transición. Pregunta Q-435095949dafba5c (abierta)

Interacción

El comportamiento ante errores y de transición refleja los flujos depurados del controlador, según los cuales las transiciones de estado no válidas se interceptan de manera uniforme ([SWS_Can_00441]).

La función Can_SetControllerMode (proporcionada a través de Can.h con el Service-ID 0x03) ejecuta transiciones de estado activadas por software de la máquina de estados del controlador CAN ([SWS_Can_00230], AUTOSAR_SWS_CANDriver p. 35). Realiza los ajustes de registros relativos al hardware para propiciar las transiciones entre los estados básicos del controlador UNINIT, STOPPED, STARTED y SLEEP ([SWS_Can_91010], AUTOSAR_SWS_CANDriver §7.3 «CAN Controller State Machine»).

Uso y semántica

La llamada se realiza con el parámetro Controller para la identificación del controlador CAN, así como con Transition del tipo Can_ControllerStateType para especificar la transición de estado deseada ([SWS_Can_00230]). El servicio está definido como asíncrono y no reentrante (Non Reentrant) ([SWS_Can_00230]). Un valor de retorno de E_OK confirma que la solicitud ha sido aceptada; E_NOT_OK indica que la solicitud ha sido rechazada y que existe un error de desarrollo ([SWS_Can_00230], [SWS_Can_00441]).

Secuencia e interacción

Tras aplicar la configuración de registros, se abandona de nuevo Can_SetControllerMode (AUTOSAR_SWS_CANDriver p. 38). Dado que el módulo Can no almacena por sí mismo los cambios de estado del hardware ([SWS_Can_91010]), presumiblemente la función cíclica Can_Mainfunction_Mode asume la finalización asíncrona o la comprobación de la transición iniciada por Can_SetControllerMode (AUTOSAR_SWS_CANDriver p. 38). Pregunta Q-03edb1b665a1624b (abierta)

La función síncrona y reentrante Can_DisableControllerInterrupts desactiva todas las interrupciones para un controlador CAN especificado ([SWS_Can_00231]). La transferencia se realiza a través del parámetro Controller sin valor de retorno ([SWS_Can_00231]).

Respecto al contexto de llamada y la concurrencia, la función está diseñada como reentrante y admite llamadas múltiples (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Interpretación: Es de esperar que una llamada múltiple incremente un contador de anidamiento interno, de modo que las interrupciones se vuelvan a activar únicamente tras un número equivalente de llamadas de habilitación (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts», AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Pregunta Q-61be56207aa92ee0 (abierta)

En el ámbito del tratamiento de errores, la especificación exige disparar el error CAN_E_UNINIT en caso de que el módulo controlador aún no esté inicializado en el momento de la llamada (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Asimismo, la especificación requiere disparar otro error (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»); presumiblemente esto sirve para comprobar si el identificador de controlador no es válido. Pregunta (abierta)

En la interacción dentro del controlador CAN, la llamada sirve para proteger secciones críticas relativas al controlador mientras este permanece activo (AUTOSAR_SWS_CANDriver §7.5 «Interrupt handling»). Las depuraciones formales y los cambios históricos de interfaz del controlador están documentados en las notas de la versión ([SWS_Can_00441]).

La función síncrona y reentrante Can_EnableControllerInterrupts reactiva todas las interrupciones permitidas para el controlador CAN indicado a través del parámetro Controller ([SWS_Can_00232]). No posee valor de retorno y se proporciona a través del archivo de cabecera Can.h ([SWS_Can_00232]).

En cuanto al flujo de ejecución, la función lee flags de control del lado del software (AUTOSAR_SWS_CANDriver p. 65). Si las interrupciones del controlador se habían desactivado previamente varias veces, Can_EnableControllerInterrupts debe llamarse tantas veces antes de la habilitación efectiva (AUTOSAR_SWS_CANDriver p. 65). Interpretación: El controlador gestiona presumiblemente las secciones de bloqueo anidadas mediante contadores o flags internos, de manera que las interrupciones de hardware no se reactivan hasta la compensación completa de todas las llamadas de desactivación. Pregunta Q-6781f0fc9ad7d221 (abierta)

Si la función se invoca antes de que el controlador de CAN se haya inicializado correctamente, notifica el error CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 66). Es probable que esto se trate como Development-Error en el contexto del controlador ([SWS_Can_00441]). Pregunta Q-efbbcf03a2589e4e (abierta) En estado no inicializado, la función no realiza ninguna otra acción en el controlador (AUTOSAR_SWS_CANDriver p. 66).

Uso y comportamiento

La función síncrona Can_CheckWakeup comprueba para un determinado controlador de CAN si se ha detectado un evento de wake-up ([SWS_Can_00360], AUTOSAR_SWS_CANDriver p. 48, AUTOSAR_SWS_CANDriver p. 67). Está disponible a través del archivo de cabecera Can.h y posee el Service-ID 0x0b ([SWS_Can_00360]).

• Parámetro: Controller (in) designa el identificador del controlador de CAN cuyo estado se debe comprobar en busca de un wake-up ([SWS_Can_00360]).
• Valor de retorno: Devuelve Std_ReturnType. El valor de retorno E_OK señaliza que la llamada a la API fue aceptada, mientras que E_NOT_OK indica el rechazo ([SWS_Can_00360]).
• Concurrencia: La función está definida como no reentrante (Non Reentrant) ([SWS_Can_00360]).

Configuración y tratamiento de errores

La disponibilidad de la función es configurable en tiempo de precompilación; el servicio Can_CheckWakeup se puede incluir en el código o eliminar de él a través de ella (AUTOSAR_SWS_CANDriver p. 67, AUTOSAR_SWS_CANDriver p. 97). Si la función se invoca antes de que el controlador de CAN haya sido inicializado, notifica el error CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 67).

Interacción

La llamada a Can_CheckWakeup suele ser desencadenada por la interfaz de CAN (AUTOSAR_SWS_CANDriver p. 48). En caso de producirse un evento de wake-up en el bus, CanIf_CheckWakeup se puede invocar durante el procesamiento de EcuM_CheckWakeup (AUTOSAR_SWS_CANInterface §7.18.4.1 «Wake-up detection»). Según [SWS_CANIF_00395], CanIf consulta aquí mediante Can_CheckWakeup() u CanTrcv_CheckWakeup() qué dispositivo de hardware concreto ha desencadenado el wake-up del bus (AUTOSAR_SWS_CANInterface p. 55).

Uso y semántica

La función Can_Write es invocada de forma síncrona por el módulo CanIf para transferir un mensaje CAN al controlador de CAN (CanDrv) para su transmisión ([SWS_Can_00233]). Al hacerlo, el invocador transfiere dos parámetros:

• Hth: Manejador de transmisión de hardware que define el objeto de transmisión que se va a utilizar y determina implícitamente el controlador, ya que los números de manejador son unívocos dentro de una unidad de hardware ([SWS_Can_00233]).
• PduInfo: Puntero a una estructura con datos útiles de la SDU, longitud de datos e identificador CAN ([SWS_Can_00233]).

Antes de la transmisión, la función comprueba el objeto de transmisión de hardware direccionado (SWS_CANDriver p. 73) y asegura la swPduHandle transferida (SWS_CANDriver p. 43). Mediante el valor de retorno del tipo Std_ReturnType (SRS_BSWGeneral §5.2.3.6 «Types and keywords»), E_OK señaliza la aceptación de la orden, mientras que CAN_BUSY indica que no hay ningún búfer de transmisión de hardware disponible ([SWS_Can_00233], SWS_CANDriver p. 51).

Manejo de errores

Si se produce un error de desarrollo durante la ejecución, la función devuelve E_NOT_OK ([SWS_Can_00233], [SWS_Can_00441]). Interpretación: los códigos de error DET específicos no se mencionan explícitamente en el extracto disponible; no obstante, es probable que los manejadores defectuosos o los punteros no válidos provoquen la devolución de E_NOT_OK. Pregunta Q-ca947a7e0e4fd7d6 (abierta)

Concurrencia y restricciones

Can_Write está especificada como reentrante o thread-safe ([SWS_Can_00233], SWS_CANDriver p. 49). Si una invocación preferente (preemptive) no se puede ejecutar de forma reentrante en el controlador, esto también se notifica a CanIf a través del valor de retorno CAN_BUSY ([SWS_Can_00233]). El invocador debe garantizar que la memoria de la PDU permanezca válida sin cambios hasta el retorno de la llamada a la función (SWS_CANDriver p. 45).

Interacción

Mediante [SWS_Can_00416] se transmite durante la invocación de qué tipo de PDU se trata (SWS_CANDriver p. 51), donde el controlador soporta la transmisión hasta la longitud máxima de PDU (SWS_CANDriver p. 52).

Uso y contexto de llamada

El módulo CAN de AUTOSAR llama a la interfaz de callout configurable <LPDU_CalloutName> opcionalmente con cada recepción de una L-PDU (SWS_CANDriver §8.4.1 «Call-out function»). La declaración de la función se proporciona a través del archivo de cabecera Can_Externals.h ([SWS_Can_00443]). El nombre real de la función se configura de forma específica para el proyecto ([SWS_Can_00443]).

Como parámetros de entrada se transfieren el handle de recepción de hardware Hrh, el identificador CanId, la longitud de datos CanDataLegth así como un puntero a los datos útiles CanSduPtr ([SWS_Can_00443]).

Filtrado y valor de retorno

La función devuelve un valor boolean. Si el callout devuelve false, la L-PDU recibida no debe procesarse posteriormente ([SWS_Can_00444]). Interpretación: Si la llamada proporciona true, debería tener lugar la transferencia regular de la L-PDU a las capas superiores. Pregunta Q-e96e75e93881c3af (abierta)

Concurrencia y restricciones

La función está provista del ID de servicio 0x20 y especificada como asíncrona (Asynchronous) y no reentrante (Non Reentrant) ([SWS_Can_00443]). Al no ser reentrante, no deben producirse llamadas paralelas en el mismo contexto.

La función Can_MainFunction_Write realiza el sondeo cíclico de confirmaciones de transmisión (TX-Confirmation) siempre que el parámetro CAN_TX_PROCESSING esté configurado en POLLING [SWS_Can_00225], AUTOSAR SWS CAN Driver §7 «Scheduled functions». Carece de parámetros (void Can_MainFunction_Write(void)), posee el Service-ID 0x01 y se proporciona al planificador a través del archivo de cabecera SchM_Can.h [SWS_Can_00225]. Mediante interruptores de configuración se puede activar o desactivar la función para el procesamiento de la transmisión de PDU AUTOSAR SWS CAN Driver §10 «CanMainFunctionWrite».

Si en el sistema no se utiliza ningún sondeo para operaciones de transmisión, Can_MainFunction_Write debe implementarse, según la especificación, como un define vacío AUTOSAR SWS CAN Driver §7 «Scheduled functions». Es de esperar que esto evite sobrecarga innecesaria del planificador en sistemas controlados puramente por interrupciones. Pregunta Q-2152a35397130945 (abierta)

En interacción con Can_MainFunction_Read y Can_MainFunction_BusOff, la rutina forma la interfaz cíclica del controlador con el SchM AUTOSAR SWS CAN Driver §7 «Scheduled functions». El procesamiento de confirmación tiene lugar, en función del modo, directamente en el recurso de hardware o en el contexto de Can_MainFunction_Write AUTOSAR SWS CAN Driver §7 «Hardware Resources». La llamada concreta y la asignación se rigen por los elementos referenciados respectivamente AUTOSAR SWS CAN Driver §10 «CanMainFunctionWrite», AUTOSAR SWS CAN Driver §10 «Call Context», respaldadas por un procesamiento de Tx específico de controlador [SWS_Can_00441].

La función Can_MainFunction_Read sirve para la consulta cíclica (sondeo) de mensajes de recepción CAN ([SWS_Can_00226]). Posee la firma void Can_MainFunction_Read (void) con el Service-ID 0x08 y se proporciona a través del archivo de cabecera SchM_Can.h para el control de la ejecución ([SWS_Can_00226]).

Uso y configuración

La función ejecuta el sondeo de indicaciones de RX si el parámetro de configuración CAN_RX_PROCESSING está ajustado a POLLING ([SWS_Can_00226]). En el sistema, este procesamiento puede configurarse por controlador ([SWS_Can_00441]). Si en el controlador CAN no se utiliza ningún sondeo en absoluto, Can_MainFunction_Read puede definirse como una macro vacía (AUTOSAR_SWS_CANDriver p. 77).

Concurrencia y restricciones

La llamada se realiza periódicamente en el contexto del planificador según el periodo de activación parametrizado (AUTOSAR_SWS_CANDriver p. 22). Para la ejecución se aplican condiciones estrictas:

• La función no debe ser interrumpida por sí misma (AUTOSAR_SWS_CANDriver p. 47).
• Por regla general, las funciones principales de CAN como Can_MainFunction_Read no deben ser interrumpidas (AUTOSAR_SWS_CANDriver p. 49), con el fin de asegurar el acceso coherente a los recursos de hardware y del controlador en el modo de sondeo (AUTOSAR_SWS_CANDriver p. 46).

Interpretación: El intervalo de llamada configurado de la tarea probablemente deba dimensionarse de tal forma que una fase de procesamiento siempre haya finalizado antes del inicio del siguiente ciclo, ya que la reentrancia no está permitida (AUTOSAR_SWS_CANDriver p. 47). Pregunta Q-1f2fa9db14970b12 (abierta)

La función principal planificada Can_MainFunction_BusOff sirve para el sondeo cíclico de eventos de Bus-Off de los controladores CAN, siempre que estos estén configurados estáticamente para ser sondeados [SWS_Can_00227], [SWS_Can_00109]. Posee la firma void Can_MainFunction_BusOff(void), no recibe ningún parámetro, no devuelve ningún valor y se proporciona a través de la cabecera SchM_Can.h para el control de la ejecución [SWS_Can_00227].

Uso e interacción

Los eventos de hardware pueden registrarse en el controlador CAN bien mediante interrupción o bien por sondeo de los flags de estado correspondientes, dependiendo de la configuración de la consulta respecto al hardware [SWS_Can_00099]. El controlador también puede configurarse de modo que se prescinda por completo de las interrupciones [SWS_Can_00007]. Si no se utiliza ningún sondeo en todo el sistema, el módulo Can puede implementar la función como una macro vacía [SWS_Can_00183].

Si en Can_MainFunction_BusOff se detecta un evento de Bus-Off mediante bits de estado, el módulo realiza los ajustes de registros necesarios, por ejemplo, para evitar una recuperación automática de hardware SWS_CANDriver §7.3 «CAN Controller State Machine», [SWS_Can_91010]. A continuación, el módulo notifica a la capa superior CanIf a través de la retrollamada correspondiente, en la cual se produce el cambio de estado de software del controlador SWS_CANDriver §7.3 «CAN Controller State Machine».

Contexto de llamada y restricciones

En el funcionamiento sondeado, el contexto de llamada de la notificación de retrollamada no es la ISR, sino la tarea ejecutora de Can_MainFunction_BusOff; no obstante, todas las funciones de retrollamada deben implementarse como si se invocaran desde el contexto de la ISR SWS_CANDriver §7.9 «Notification concept». En cuanto a la reentrancia, el payload no contiene indicaciones explícitas; presumiblemente la función no es reentrante, ya que accede a registros y estados globales del controlador. Pregunta Q-38fcd72c40ce3e66 (abierta)

La función principal Can_MainFunction_Wakeup realiza el sondeo cíclico de eventos de reactivación configurados estáticamente para ser sondeados ([SWS_Can_00228]). La función posee la firma void Can_MainFunction_Wakeup(void), no recibe ningún parámetro, no devuelve ningún valor de retorno y se proporciona para el Schedule Manager a través de la cabecera SchM_Can.h (AUTOSAR_SWS_CANDriver p. 79). El periodo de ejecución de la función se configura en segundos (AUTOSAR_SWS_CANDriver p. 92).

En el marco de la máquina de estados del controlador CAN (SWS_CANDriver §7.3 «CAN Controller State Machine»), los eventos de reactivación de hardware externos pueden señalizarse, en lugar de mediante interrupciones, a través de un bit de estado que se consulta en Can_MainFunction_Wakeup ([SWS_Can_91010]). Además, en las transiciones de estado, la función sondea un flag correspondiente del registro de estado de CAN hasta que este señalice la efectividad del cambio ([SWS_Can_00370]). Tras un cambio de estado satisfactorio, el controlador CAN notifica el nuevo estado a la interfaz CAN mediante la función de retrollamada CanIf_ControllerModeIndication, en relación con la CanIf ControllerId abstracta ([SWS_Can_00370]).

En relación con la configuración y el uso de recursos, la API Can_MainFunction_Wakeup() puede activarse o desactivarse para el tratamiento de eventos de reactivación (AUTOSAR_SWS_CANDriver p. 97). En caso de que en la unidad de control no se utilice sondeo alguno para eventos de reactivación, Can_MainFunction_Wakeup puede definirse como una macro vacía (AUTOSAR_SWS_CANDriver p. 79).

Uso y funcionamiento

La función principal planificada Can_MainFunction_Mode ([SWS_Can_00368]) realiza el polling de transiciones de estado de los controladores de CAN. No posee parámetros de entrada ni valor de retorno (void Can_MainFunction_Mode(void), Service-ID 0x0c) y se declara a través de la cabecera SchM_Can.h SWS_CANDriver §8.5.1.5 «Can_MainFunction_Mode».

La función se invoca cíclicamente de forma continua (AUTOSAR_SWS_CANInterface p. 143). Comprueba en el hardware si ha cambiado el modo de un controlador de CAN. Si se detecta un cambio, se notifica a la interfaz de CAN mediante la llamada a CanIf_ControllerModeIndication(Controller, ControllerMode).

Supervisión asíncrona de modo

Si previamente se solicitó un cambio de modo a través de Can_SetControllerMode() y esta llamada retorna con éxito a CanIf, Can_MainFunction_Mode detecta la transición de estado consumada del hardware del controlador. A continuación, informa de forma asíncrona a CanIf mediante CanIf_ControllerModeIndication sobre el nuevo estado, como por ejemplo CAN_CS_STARTED AUTOSAR_SWS_CANInterface p. 144.

Contexto de llamada y condiciones de contorno

Debido a su puesta a disposición a través de SchM_Can.h y a su definición como Scheduled Function, es probable que la llamada periódica sea realizada por el BSW-Scheduler. Pregunta Q-42edbc2aa591e8d7 (abierta) En el payload no se definen códigos de error específicos ni pasos de desarrollo para esta función.

El tipo de enumeración Can_ErrorStateType de Can_GeneralTypes.h describe los estados de error y de funcionamiento de un controlador de CAN [SWS_Can_91003]. Representa el comportamiento del controlador en el bus CAN a través de tres estados SWS_CANDriver §8.2.7 «Can_ErrorStateType»:

• CAN_ERRORSTATE_ACTIVE: El controlador de CAN participa plenamente en la comunicación del bus [SWS_Can_91003].
• CAN_ERRORSTATE_PASSIVE: El controlador de CAN participa en la comunicación, pero ya no envía tramas de error (Error Frames) activas [SWS_Can_91003].
• CAN_ERRORSTATE_BUSOFF: El controlador de CAN está aislado del bus debido a errores de transmisión graves y ya no participa en la comunicación [SWS_Can_91003].

En tiempo de ejecución, el estado se consulta a través del servicio síncrono del controlador Can_GetControllerErrorState [SWS_Can_91004]. Su parámetro de salida ErrorStatePtr recibe el valor determinado. La misma firma es utilizada también por la función de nivel superior CanIf_GetControllerErrorState en la interfaz de CAN AUTOSAR_SWS_CANInterface p. 78 «CanIf_GetControllerErrorState». En lo relativo a la concurrencia, se aplica que Can_GetControllerErrorState está especificada como no reentrante para el mismo ControllerId [SWS_Can_91004].

En caso de error, Can_GetControllerErrorState proporciona el valor de retorno E_NOT_OK, y E_OK en caso de consulta exitosa [SWS_Can_91004]. Con la detección de desarrollo (DET) activada, una llamada antes de la inicialización del controlador provoca el error CAN_E_UNINIT [SWS_Can_91005]. Un ControllerId no permitido desencadena el error de desarrollo CAN_E_PARAM_CONTROLLER [SWS_Can_91006], y la transferencia de un puntero nulo para ErrorStatePtr se rechaza con un error de desarrollo [SWS_Can_91007].

Interpretación: es probable que el invocador deba asignar el área de memoria para ErrorStatePtr bajo su propia responsabilidad, ya que la interfaz trata el puntero como un parámetro de salida puro y excluye los punteros nulos mediante un error de desarrollo. Pregunta Q-5c907c21bcb50893 (abierta)

El tipo de enumeración Can_ControllerStateType define los estados de funcionamiento básicos de un controlador de CAN: CAN_CS_UNINIT, CAN_CS_STARTED, CAN_CS_STOPPED y CAN_CS_SLEEP [SWS_Can_91013]. El tipo se utiliza a nivel intermodular para la gestión de estados controlada por software de la máquina de estados del controlador de CAN [SWS_Can_00017].

Los valores se emplean en los siguientes contextos:

• Solicitud de estado: En Can_SetControllerMode, el tipo sirve como valor de transición (parámetro Transition) para la solicitud asíncrona de un nuevo estado de funcionamiento [SWS_Can_00230]; de forma correspondiente a esto existe CanIf_SetControllerMode AUTOSAR_SWS_CANInterface §- «CanIf_SetControllerMode». El controlador reenvía la solicitud al hardware del controlador, surtiendo efecto el cambio de estado real de forma inmediata o tras unos milisegundos AUTOSAR_SWS_CANInterface §- «Can_SetControllerMode». Una transición a CAN_CS_STARTED desencadena además una reinicialización del controlador [SWS_Can_00384].
• Consulta de estado: Mediante Can_GetControllerMode se puede consultar el estado actual de forma síncrona a través del puntero de salida ControllerModePtr [SWS_Can_91014], [SWS_Can_91015] (de forma análoga en CanIf_GetControllerMode AUTOSAR_SWS_CANInterface §- «CanIf_GetControllerMode»).
• Indicación de estado: Tras consumarse el cambio, callbacks como CanSM_ControllerModeIndication [SWS_CanSM_00396], CanIf_ControllerModeIndication AUTOSAR_SWS_CANInterface §- «CanIf_ControllerModeIndication» así como callbacks de usuario AUTOSAR_SWS_CANInterface §- «User_ControllerModeIndication» notifican de forma síncrona a las capas superiores sobre el nuevo modo del controlador.

En cuanto a concurrencia y tratamiento de errores, se aplica: las funciones del controlador Can_SetControllerMode y Can_GetControllerMode no son reentrantes [SWS_Can_00230], [SWS_Can_91014]. En caso de invocación de Can_GetControllerMode antes de la inicialización del controlador, se notifica el error de desarrollo CAN_E_UNINIT y se devuelve E_NOT_OK [SWS_Can_91016]. La función de callback CanSM_ControllerModeIndication es reentrante para diferentes controladores y notifica un ID de controlador no configurado con CANSM_E_PARAM_CONTROLLER al DET [SWS_CanSM_00396], [SWS_CanSM_00397].

El tipo de enumeración Can_ErrorType define un superconjunto estandarizado de causas de error de CAN que el hardware CAN típico puede registrar y notificar a capas superiores [SWS_Can_91021]. Se proporciona a través del archivo de cabecera Can_GeneralTypes.h SWS_CANDriver §8.2.9 «Can_ErrorType».

Dado que la enumeración está concebida como un superconjunto, no todos los controladores CAN admiten necesariamente la totalidad de los valores especificados [SWS_Can_91021]. Entre los estados de error definidos se encuentran:

• errores de bit en la monitorización del bus (CAN_ERROR_BIT_MONITORING1, CAN_ERROR_BIT_MONITORING0 o, en resumen, CAN_ERROR_BIT),
• errores de acuse de recibo (CAN_ERROR_CHECK_ACK_FAILED, CAN_ERROR_ACK_DELIMITER),
• pérdida de arbitraje del transmisor (CAN_ERROR_ARBITRATION_LOST),
• estados de sobrecarga por búferes de recepción llenos (CAN_ERROR_OVERLOAD),
• infracciones de formato y de relleno de bits (bit stuffing) (CAN_ERROR_CHECK_FORM_FAILED, CAN_ERROR_CHECK_STUFFING_FAILED),
• errores de CRC (CAN_ERROR_CHECK_CRC_FAILED), así como
• un bloqueo permanente del bus en nivel dominante (CAN_ERROR_BUS_LOCK) SWS_CANDriver §8.2.9 «Can_ErrorType».

En la interacción de los módulos BSW, el tipo sirve como parámetro de la función de callback CanIf_ErrorNotification para la transmisión de errores de controlador a la interfaz CAN AUTOSAR_SWS_CANInterface §8.x «CanIf_ErrorNotification». El valor transferido debería corresponder en este caso al estado de error determinado por el hardware subyacente AUTOSAR_SWS_CANDriver §7.x «Error Notification». Pregunta Q-d23c45dd3b23ec71 (abierta)