CAN Driver (Can)

Синхронная, нереентерабельная функция Can_Init инициализирует весь модуль драйвера CAN, а также соответствующие аппаратные блоки в соответствии с переданной конфигурацией [SWS_Can_00223].

Использование и контекст вызова

Вызов Can_Init обязательно выполняется менеджером состояния ECU (ECU State Manager) во время фазы запуска блока управления, еще до того, как будет разрешено вызвать любую другую функцию драйвера CAN [SWS_Can_91012]. В качестве параметра функция принимает через Config указатель на конфигурацию драйвера (const Can_ConfigType*) и не возвращает значения [SWS_Can_00223].

Объем инициализации и переходы состояний

В рамках инициализации функция устанавливает все необходимые аппаратные регистры и инициализирует все CAN-контроллеры AUTOSAR_SWS_CANDriver с. 33:

• инициализация статических переменных и внутренних флагов [SWS_Can_91012],
• конфигурация общих настроек для всего аппаратного блока CAN [SWS_Can_91012],
• специфичные для контроллера настройки для каждого отдельного CAN-контроллера [SWS_Can_91012].

Вызов функции запускает переходы состояний аппаратного обеспечения CAN AUTOSAR_SWS_CANDriver с. 10, при этом Can_Init выполняет конфигурацию регистров для перевода контроллеров в предусмотренное базовое состояние [SWS_Can_91010] AUTOSAR_SWS_CANDriver с. 36.

Параллелизм и ограничения

Поскольку Can_Init специфицирована как нереентерабельная, параллельный или повторный вызов во время выполняющейся инициализации недопустим [SWS_Can_00223]. Кроме того, определенные глобальные настройки аппаратного блока могут быть заданы исключительно внутри Can_Init AUTOSAR_SWS_CANDriver с. 33.

Функция Can_DeInit служит для деинициализации модуля драйвера CAN ([SWS_Can_91002]). Она имеет сигнатуру void Can_DeInit(void), не принимает параметров, не возвращает значения и выполняется синхронно, а также нереентерабельно ([SWS_Can_91002]). Интерфейс доступен через заголовок Can.h ([SWS_Can_91002]).

Вызов инициирует программно управляемый переход состояния (AUTOSAR_SWS_CANDriver с. 10; AUTOSAR_SWS_CANDriver с. 41). При этом Can_DeInit меняет состояние модуля (AUTOSAR_SWS_CANDriver с. 33) и сбрасывает все CAN-контроллеры (AUTOSAR_SWS_CANDriver с. 41).

Параллелизм и ограничения

Для выполнения действуют строгие предусловия и требования к последовательности относительно состояний аппаратного обеспечения и модуля:

• Вызывающая сторона должна убедиться, что ни один CAN-контроллер не находится в недопустимом состоянии (AUTOSAR_SWS_CANDriver с. 61); предположительно, активные процессы коммуникации должны быть предварительно завершены. Вопрос Q-311343fa42add3a3 (открытый)
• Если модуль CAN при вызове не находится в требуемом исходном состоянии (AUTOSAR_SWS_CANDriver с. 41), функция сообщает об ошибке CAN_E_TRANSITION (AUTOSAR_SWS_CANDriver с. 61).
• Аналогично ошибка CAN_E_TRANSITION генерируется, если CAN-контроллер остается в состоянии, препятствующем деинициализации (AUTOSAR_SWS_CANDriver с. 61). Интерпретация: драйвер, вероятно, требует остановленного состояния всех контроллеров перед переходом. Вопрос Q-435095949dafba5c (открытый)

Взаимодействие

Поведение при ошибках и переходах отражает скорректированные процессы драйвера, согласно которым недействительные переходы состояний единообразно перехватываются ([SWS_Can_00441]).

Функция Can_SetControllerMode (предоставляемая через Can.h с Service-ID 0x03) выполняет программно инициированные переходы состояний конечного автомата CAN-контроллера ([SWS_Can_00230], AUTOSAR_SWS_CANDriver с. 35). Она выполняет аппаратные настройки регистров, чтобы вызвать переходы между базовыми состояниями контроллера UNINIT, STOPPED, STARTED и SLEEP ([SWS_Can_91010], AUTOSAR_SWS_CANDriver §7.3 «CAN Controller State Machine»).

Использование и семантика

Вызов осуществляется с параметром Controller для идентификации CAN-контроллера, а также с Transition типа Can_ControllerStateType для задания желаемого перехода состояния ([SWS_Can_00230]). Служба определена как асинхронная и нереентерабельная (Non Reentrant) ([SWS_Can_00230]). Возвращаемое значение E_OK подтверждает, что запрос был принят; E_NOT_OK указывает на то, что запрос был отклонен и имеет место ошибка разработки ([SWS_Can_00230], [SWS_Can_00441]).

Порядок выполнения и взаимодействие

После установки конфигурации регистров происходит выход из Can_SetControllerMode (AUTOSAR_SWS_CANDriver с. 38). Поскольку модуль Can сам не сохраняет смену состояний аппаратного обеспечения ([SWS_Can_91010]), циклическая функция Can_Mainfunction_Mode, вероятно, берет на себя асинхронное завершение или проверку перехода, инициированного Can_SetControllerMode (AUTOSAR_SWS_CANDriver с. 38). Вопрос Q-03edb1b665a1624b (открытый)

Синхронная и реентерабельная функция Can_DisableControllerInterrupts деактивирует все прерывания для указанного CAN-контроллера ([SWS_Can_00231]). Передача осуществляется через параметр Controller без возвращаемого значения ([SWS_Can_00231]).

Что касается контекста вызова и параллелизма, функция спроектирована как реентерабельная и поддерживает многократные вызовы (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Интерпретация: многократный вызов, вероятно, увеличивает внутренний счетчик вложенности, так что прерывания снова активируются только после соответствующего количества разрешающих вызовов (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts», AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Вопрос Q-61be56207aa92ee0 (открытый)

В области обработки ошибок спецификация требует генерации ошибки CAN_E_UNINIT, если модуль драйвера при вызове еще не инициализирован (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»). Кроме того, спецификация требует генерации еще одной ошибки (AUTOSAR_SWS_CANDriver §8.3 «Can_DisableControllerInterrupts»); вероятно, это служит для проверки на недействительный идентификатор контроллера. Вопрос (открытый)

Во взаимодействии внутри драйвера CAN вызов служит для защиты связанных с контроллером критических секций, в то время как контроллер остается активным (AUTOSAR_SWS_CANDriver §7.5 «Interrupt handling»). Формальные очистки и исторические изменения интерфейса драйвера задокументированы в примечаниях к релизу ([SWS_Can_00441]).

Синхронная и реентерабельная функция Can_EnableControllerInterrupts повторно активирует все допустимые прерывания для CAN-контроллера, указанного через параметр Controller ([SWS_Can_00232]). Она не имеет возвращаемого значения и предоставляется через заголовочный файл Can.h ([SWS_Can_00232]).

Что касается процесса, функция считывает программные управляющие флаги (AUTOSAR_SWS_CANDriver с. 65). Если прерывания контроллера ранее были деактивированы многократно, Can_EnableControllerInterrupts перед фактической активацией должна быть вызвана столько же раз (AUTOSAR_SWS_CANDriver с. 65). Интерпретация: драйвер, вероятно, управляет вложенными участками блокировки через внутренние счетчики или флаги, так что аппаратные прерывания активируются только после полной компенсации всех вызовов деактивации. Вопрос Q-6781f0fc9ad7d221 (открытый)

Если функция вызывается до того, как драйвер CAN был надлежащим образом инициализирован, она сообщает об ошибке CAN_E_UNINIT (AUTOSAR_SWS_CANDriver с. 66). В контексте драйвера это, вероятно, обрабатывается как Development Error ([SWS_Can_00441]). Вопрос Q-efbbcf03a2589e4e (открытый) В неинициализированном состоянии функция не выполняет никаких дальнейших действий над контроллером (AUTOSAR_SWS_CANDriver с. 66).

Использование и поведение

Синхронная функция Can_CheckWakeup проверяет для определенного CAN-контроллера, было ли обнаружено событие Wake-up ([SWS_Can_00360], AUTOSAR_SWS_CANDriver с. 48, AUTOSAR_SWS_CANDriver с. 67). Она доступна через заголовочный файл Can.h и имеет Service-ID 0x0b ([SWS_Can_00360]).

• Параметр: Controller (in) обозначает идентификатор CAN-контроллера, состояние которого должно быть проверено на наличие Wake-up ([SWS_Can_00360]).
• Возвращаемое значение: возвращает Std_ReturnType. Возвращаемое значение E_OK сигнализирует о том, что вызов API был принят, тогда как E_NOT_OK указывает на отклонение ([SWS_Can_00360]).
• Параллелизм: функция определена как нереентерабельная (Non Reentrant) ([SWS_Can_00360]).

Конфигурация и обработка ошибок

Доступность функции конфигурируется во время предварительной компиляции; служба Can_CheckWakeup с помощью этого может быть включена в код или удалена из него (AUTOSAR_SWS_CANDriver с. 67, AUTOSAR_SWS_CANDriver с. 97). Если функция вызывается до того, как был инициализирован драйвер CAN, она сообщает об ошибке CAN_E_UNINIT (AUTOSAR_SWS_CANDriver с. 67).

Взаимодействие

Вызов Can_CheckWakeup обычно инициируется интерфейсом CAN-Interface (AUTOSAR_SWS_CANDriver с. 48). В случае события Wake-up на шине CanIf_CheckWakeup может вызываться во время обработки EcuM_CheckWakeup (AUTOSAR_SWS_CANInterface §7.18.4.1 «Wake-up detection»). Согласно [SWS_CANIF_00395], CanIf при этом опрашивает через Can_CheckWakeup() или CanTrcv_CheckWakeup(), какое конкретное аппаратное устройство вызвало Bus-Wake-up (AUTOSAR_SWS_CANInterface с. 55).

Использование и семантика

Функция Can_Write вызывается синхронно модулем CanIf, чтобы передать CAN-сообщение для передачи в драйвер CAN (CanDrv) ([SWS_Can_00233]). При этом вызывающая сторона передает два параметра:

• Hth: аппаратный дескриптор отправки, определяющий используемый объект отправки и неявно определяющий контроллер, поскольку номера дескрипторов уникальны в пределах аппаратного блока ([SWS_Can_00233]).
• PduInfo: указатель на структуру с полезными данными SDU, длиной данных и CAN-идентификатором ([SWS_Can_00233]).

Перед отправкой функция проверяет адресованный аппаратный объект отправки (SWS_CANDriver с. 73) и сохраняет переданный swPduHandle (SWS_CANDriver с. 43). Через возвращаемое значение типа Std_ReturnType (SRS_BSWGeneral §5.2.3.6 «Types and keywords») E_OK сигнализирует о принятии задания, тогда как CAN_BUSY указывает на то, что аппаратный буфер отправки недоступен ([SWS_Can_00233], SWS_CANDriver с. 51).

Обработка ошибок

Если во время выполнения возникает ошибка разработки, функция возвращает E_NOT_OK ([SWS_Can_00233], [SWS_Can_00441]). Интерпретация: специфические коды ошибок DET в доступном фрагменте явно не названы; однако ошибочные дескрипторы или недействительные указатели, вероятно, приводят к возврату E_NOT_OK. Вопрос Q-ca947a7e0e4fd7d6 (открытый)

Параллелизм и ограничения

Can_Write специфицирована как реентерабельная или потокобезопасная (thread-safe) ([SWS_Can_00233], SWS_CANDriver с. 49). Если вытесняющий вызов со стороны драйвера не может быть выполнен реентерабельно, об этом CanIf также сообщается через возвращаемое значение CAN_BUSY ([SWS_Can_00233]). Вызывающая сторона должна гарантировать, что память PDU остается неизменной и валидной до возврата из вызова функции (SWS_CANDriver с. 45).

Взаимодействие

Через [SWS_Can_00416] при вызове передается, о каком типе PDU идет речь (SWS_CANDriver с. 51), причем драйвер поддерживает передачу вплоть до максимальной длины PDU (SWS_CANDriver с. 52).

Использование и контекст вызова

Конфигурируемый интерфейс call-out <LPDU_CalloutName> опционально вызывается CAN-модулем AUTOSAR при каждом приёме L-PDU (SWS_CANDriver §8.4.1 «Call-out function»). Объявление функции предоставляется через заголовочный файл Can_Externals.h ([SWS_Can_00443]). Фактическое имя функции конфигурируется для конкретного проекта ([SWS_Can_00443]).

В качестве входных параметров передаются аппаратный дескриптор приёма Hrh, идентификатор CanId, длина данных CanDataLegth, а также указатель на полезные данные CanSduPtr ([SWS_Can_00443]).

Фильтрация и возвращаемое значение

Функция возвращает значение типа boolean. Если call-out возвращает false, принятый L-PDU не подлежит дальнейшей обработке ([SWS_Can_00444]). Интерпретация: если вызов возвращает true, вероятно, происходит штатная передача L-PDU вышележащим уровням. Вопрос Q-e96e75e93881c3af (открытый)

Параллелизм и ограничения

Функция снабжена Service-ID 0x20 и специфицирована как асинхронная (Asynchronous), а также нереентерабельная (Non Reentrant) ([SWS_Can_00443]). Поскольку она не является реентерабельной, параллельные вызовы в одном и том же контексте не допускаются.

Функция Can_MainFunction_Write выполняет циклический опрос подтверждений отправки (TX-Confirmation), если параметр CAN_TX_PROCESSING сконфигурирован на POLLING [SWS_Can_00225], AUTOSAR SWS CAN Driver §7 «Scheduled functions». Она не имеет параметров (void Can_MainFunction_Write(void)), имеет Service-ID 0x01 и предоставляется планировщику через заголовочный файл SchM_Can.h [SWS_Can_00225]. С помощью конфигурационных переключателей функция может быть активирована или деактивирована для обработки передачи PDU AUTOSAR SWS CAN Driver §10 «CanMainFunctionWrite».

Если опрос для процессов отправки вообще не используется в системе, Can_MainFunction_Write, согласно спецификации, должна быть реализована как пустой define AUTOSAR SWS CAN Driver §7 «Scheduled functions». Это, вероятно, позволяет избежать ненужных накладных расходов планировщика в системах, управляемых исключительно прерываниями. Вопрос Q-2152a35397130945 (открытый)

Во взаимодействии с Can_MainFunction_Read и Can_MainFunction_BusOff процедура формирует циклический интерфейс драйвера к SchM AUTOSAR SWS CAN Driver §7 «Scheduled functions». Обработка подтверждений происходит в зависимости от режима непосредственно на аппаратном ресурсе или в контексте Can_MainFunction_Write AUTOSAR SWS CAN Driver §7 «Hardware Resources». Конкретный вызов и сопоставление определяются соответствующими элементами, на которые даны ссылки AUTOSAR SWS CAN Driver §10 «CanMainFunctionWrite», AUTOSAR SWS CAN Driver §10 «Call Context», при поддержке обработки Tx, ориентированной на контроллер [SWS_Can_00441].

Функция Can_MainFunction_Read служит для циклического опроса (polling) сообщений приема CAN ([SWS_Can_00226]). Она имеет сигнатуру void Can_MainFunction_Read (void) с Service-ID 0x08 и предоставляется через заголовочный файл SchM_Can.h для управления выполнением ([SWS_Can_00226]).

Использование и конфигурация

Функция выполняет опрос индикаций RX, если параметр конфигурации CAN_RX_PROCESSING установлен в POLLING ([SWS_Can_00226]). В системе эта обработка может быть сконфигурирована по контроллерам ([SWS_Can_00441]). Если в драйвере CAN опрос вообще не используется, Can_MainFunction_Read может быть определена как пустой макрос (AUTOSAR_SWS_CANDriver с. 77).

Параллелизм и ограничения

Вызов происходит периодически в контексте планировщика в соответствии с параметризованным периодом триггера (AUTOSAR_SWS_CANDriver с. 22). Для выполнения действуют строгие условия:

• Функция не должна прерываться самой собой (AUTOSAR_SWS_CANDriver с. 47).
• В целом основные функции CAN, такие как Can_MainFunction_Read, не должны прерываться (AUTOSAR_SWS_CANDriver с. 49), чтобы обеспечить согласованный доступ к ресурсам драйвера и аппаратного обеспечения в режиме опроса (AUTOSAR_SWS_CANDriver с. 46).

Интерпретация: сконфигурированный интервал вызова задачи, вероятно, должен быть рассчитан таким образом, чтобы фаза обработки всегда завершалась до начала следующего цикла, поскольку реентерабельность недопустима (AUTOSAR_SWS_CANDriver с. 47). Вопрос Q-1f2fa9db14970b12 (открытый)

Запланированная основная функция Can_MainFunction_BusOff служит для циклического опроса событий Bus-Off CAN-контроллеров, если они статически сконфигурированы для опроса [SWS_Can_00227], [SWS_Can_00109]. Она имеет сигнатуру void Can_MainFunction_BusOff(void), не принимает параметров, не возвращает значения и предоставляется через заголовок SchM_Can.h для управления выполнением [SWS_Can_00227].

Использование и взаимодействие

Аппаратные события могут фиксироваться в драйвере CAN либо по прерыванию, либо путем опроса соответствующих флагов состояния, при этом конфигурация опроса зависит от аппаратного обеспечения [SWS_Can_00099]. Драйвер также может быть сконфигурирован таким образом, чтобы полностью отказаться от прерываний [SWS_Can_00007]. Если опрос не применяется во всей системе вообще, модулю Can разрешается реализовать функцию как пустой макрос [SWS_Can_00183].

Если в Can_MainFunction_BusOff событие Bus-Off обнаруживается через биты состояния, модуль выполняет необходимые настройки регистров — например, во избежание автоматического аппаратного восстановления SWS_CANDriver §7.3 «CAN Controller State Machine», [SWS_Can_91010]. Затем модуль уведомляет вышележащий уровень CanIf через соответствующий callback, в котором происходит программное изменение состояния контроллера SWS_CANDriver §7.3 «CAN Controller State Machine».

Контекст вызова и ограничения

При работе методом опроса контекстом вызова уведомления обратного вызова является не ISR, а исполняющая задача Can_MainFunction_BusOff; тем не менее все функции обратного вызова должны быть реализованы так, как если бы они вызывались из контекста ISR SWS_CANDriver §7.9 «Notification concept». Относительно реентерабельности payload не содержит явных указаний; вероятно, функция является нереентерабельной, поскольку она обращается к глобальным регистрам и состояниям контроллера. Вопрос Q-38fcd72c40ce3e66 (открытый)

Основная функция Can_MainFunction_Wakeup выполняет циклический опрос событий Wake-up, которые статически сконфигурированы как подлежащие опросу ([SWS_Can_00228]). Функция имеет сигнатуру void Can_MainFunction_Wakeup(void), не принимает параметров, не возвращает значения и предоставляется через заголовок SchM_Can.h для Schedule Manager (AUTOSAR_SWS_CANDriver с. 79). Период выполнения функции конфигурируется в секундах (AUTOSAR_SWS_CANDriver с. 92).

В рамках конечного автомата CAN-контроллера (SWS_CANDriver §7.3 «CAN Controller State Machine») внешние аппаратные события Wakeup вместо прерываний могут сигнализироваться через бит состояния, опрашиваемый в Can_MainFunction_Wakeup ([SWS_Can_91010]). Кроме того, функция при переходах состояний опрашивает соответствующий флаг регистра состояния CAN до тех пор, пока он не просигнализирует о вступлении изменения в силу ([SWS_Can_00370]). После успешной смены состояния драйвер CAN сообщает о новом состоянии с помощью функции обратного вызова CanIf_ControllerModeIndication интерфейсу CAN-Interface применительно к абстрактному CanIf ControllerId ([SWS_Can_00370]).

Что касается конфигурации и использования ресурсов, API Can_MainFunction_Wakeup() для обработки событий Wakeup может быть активирован или деактивирован (AUTOSAR_SWS_CANDriver с. 97). Если в блоке управления опрос для событий Wakeup вообще не используется, Can_MainFunction_Wakeup может быть определен как пустой макрос (AUTOSAR_SWS_CANDriver с. 79).

Использование и принцип работы

Запланированная основная функция Can_MainFunction_Mode ([SWS_Can_00368]) выполняет опрос переходов состояний CAN-контроллеров. Она не имеет ни входных параметров, ни возвращаемого значения (void Can_MainFunction_Mode(void), Service-ID 0x0c) и объявляется через заголовок SchM_Can.h SWS_CANDriver §8.5.1.5 «Can_MainFunction_Mode».

Функция непрерывно вызывается циклически (AUTOSAR_SWS_CANInterface с. 143). Она проверяет аппаратное обеспечение на предмет изменения режима CAN-контроллера. При обнаружении изменения интерфейс CAN-Interface уведомляется через вызов CanIf_ControllerModeIndication(Controller, ControllerMode).

Асинхронный мониторинг режима

Если ранее через Can_SetControllerMode() было запрошено изменение режима и этот вызов успешно возвращается в CanIf, Can_MainFunction_Mode распознает совершенный переход состояния аппаратного обеспечения контроллера. Затем она асинхронно информирует CanIf с помощью CanIf_ControllerModeIndication о новом состоянии, таком как CAN_CS_STARTED AUTOSAR_SWS_CANInterface с. 144.

Контекст вызова и граничные условия

Вследствие предоставления через SchM_Can.h и определения в качестве Scheduled Function периодический вызов, вероятно, осуществляется планировщиком BSW. Вопрос Q-42edbc2aa591e8d7 (открытый) Специфические коды ошибок или этапы разработки для этой функции в payload не определены.

Тип перечисления Can_ErrorStateType из Can_GeneralTypes.h описывает состояния ошибок и рабочие состояния CAN-контроллера [SWS_Can_91003]. Он отображает поведение контроллера на шине CAN через три состояния SWS_CANDriver §8.2.7 «Can_ErrorStateType»:

• CAN_ERRORSTATE_ACTIVE: CAN-контроллер в полном объеме участвует в коммуникации по шине [SWS_Can_91003].
• CAN_ERRORSTATE_PASSIVE: CAN-контроллер участвует в коммуникации, но больше не отправляет активных кадров ошибок (Error Frames) [SWS_Can_91003].
• CAN_ERRORSTATE_BUSOFF: CAN-контроллер изолирован от шины вследствие серьезных ошибок передачи и больше не участвует в коммуникации [SWS_Can_91003].

Во время выполнения состояние опрашивается через синхронную службу драйвера Can_GetControllerErrorState [SWS_Can_91004]. Ее выходной параметр ErrorStatePtr принимает определенное значение. Ту же сигнатуру использует и вышележащая функция CanIf_GetControllerErrorState в CAN-Interface AUTOSAR_SWS_CANInterface с. 78 «CanIf_GetControllerErrorState». В отношении параллелизма действует правило: Can_GetControllerErrorState для одного и того же ControllerId специфицирована как нереентерабельная [SWS_Can_91004].

В случае ошибки Can_GetControllerErrorState возвращает значение E_NOT_OK, при успешном опросе — E_OK [SWS_Can_91004]. При активированном обнаружении ошибок разработки (DET) вызов до инициализации драйвера приводит к ошибке CAN_E_UNINIT [SWS_Can_91005]. Недопустимый ControllerId вызывает ошибку разработки CAN_E_PARAM_CONTROLLER [SWS_Can_91006], а передача нулевого указателя для ErrorStatePtr отклоняется ошибкой разработки [SWS_Can_91007].

Интерпретация: вызывающей стороне, вероятно, необходимо самостоятельно выделять область памяти для ErrorStatePtr, поскольку интерфейс обрабатывает указатель как чисто выходной параметр и исключает нулевые указатели через ошибку разработки. Вопрос Q-5c907c21bcb50893 (открытый)

Тип перечисления Can_ControllerStateType определяет базовые рабочие состояния CAN-контроллера: CAN_CS_UNINIT, CAN_CS_STARTED, CAN_CS_STOPPED и CAN_CS_SLEEP [SWS_Can_91013]. Этот тип используется между модулями для программно управляемого ведения состояний конечного автомата CAN-контроллера [SWS_Can_00017].

Значения применяются в следующих контекстах:

• Запрос состояния: в Can_SetControllerMode тип служит значением перехода (параметр Transition) для асинхронного запроса нового рабочего состояния [SWS_Can_00230]; соответственно ему существует CanIf_SetControllerMode AUTOSAR_SWS_CANInterface §- «CanIf_SetControllerMode». Драйвер передает запрос аппаратному обеспечению контроллера, при этом фактическое изменение состояния вступает в силу немедленно или через несколько миллисекунд AUTOSAR_SWS_CANInterface §- «Can_SetControllerMode». Переход в CAN_CS_STARTED дополнительно инициирует реинициализацию контроллера [SWS_Can_00384].
• Опрос состояния: с помощью Can_GetControllerMode текущее состояние можно запросить синхронно через выходной указатель ControllerModePtr [SWS_Can_91014], [SWS_Can_91015] (аналогично в CanIf_GetControllerMode AUTOSAR_SWS_CANInterface §- «CanIf_GetControllerMode»).
• Индикация состояния: после завершения переключения функции обратного вызова, такие как CanSM_ControllerModeIndication [SWS_CanSM_00396], CanIf_ControllerModeIndication AUTOSAR_SWS_CANInterface §- «CanIf_ControllerModeIndication», а также пользовательские функции обратного вызова AUTOSAR_SWS_CANInterface §- «User_ControllerModeIndication» синхронно уведомляют вышележащие уровни о новом режиме контроллера.

В отношении параллелизма и обработки ошибок действует следующее: функции драйвера Can_SetControllerMode и Can_GetControllerMode не являются реентерабельными [SWS_Can_00230], [SWS_Can_91014]. При вызове Can_GetControllerMode до инициализации драйвера сообщается об ошибке разработки CAN_E_UNINIT и возвращается E_NOT_OK [SWS_Can_91016]. Функция обратного вызова CanSM_ControllerModeIndication реентерабельна для различных контроллеров и сообщает о несконфигурированном ID контроллера с CANSM_E_PARAM_CONTROLLER в DET [SWS_CanSM_00396], [SWS_CanSM_00397].

Перечислимый тип Can_ErrorType определяет стандартизированное надмножество причин ошибок CAN, которые типичное аппаратное обеспечение CAN может фиксировать и сообщать вышележащим уровням [SWS_Can_91021]. Он предоставляется через заголовочный файл Can_GeneralTypes.h SWS_CANDriver §8.2.9 «Can_ErrorType».

Поскольку перечисление спроектировано как надмножество, не каждый CAN-контроллер обязательно поддерживает все специфицированные значения [SWS_Can_91021]. К определенным состояниям ошибок относятся:

• битовые ошибки при мониторинге шины (CAN_ERROR_BIT_MONITORING1, CAN_ERROR_BIT_MONITORING0 или обобщённо CAN_ERROR_BIT),
• ошибки подтверждения приёма (CAN_ERROR_CHECK_ACK_FAILED, CAN_ERROR_ACK_DELIMITER),
• потеря арбитража передатчиком (CAN_ERROR_ARBITRATION_LOST),
• состояния перегрузки из-за переполнения приёмных буферов (CAN_ERROR_OVERLOAD),
• нарушения формата и бит-стаффинга (CAN_ERROR_CHECK_FORM_FAILED, CAN_ERROR_CHECK_STUFFING_FAILED),
• ошибки CRC (CAN_ERROR_CHECK_CRC_FAILED), а также
• постоянная блокировка шины на доминантном уровне (CAN_ERROR_BUS_LOCK) SWS_CANDriver §8.2.9 «Can_ErrorType».

Во взаимодействии BSW-модулей данный тип служит параметром функции обратного вызова CanIf_ErrorNotification для пересылки ошибок контроллера в CAN-интерфейс AUTOSAR_SWS_CANInterface §8.x «CanIf_ErrorNotification». Передаваемое значение при этом, вероятно, соответствует состоянию ошибки, обнаруженному базовым аппаратным обеспечением AUTOSAR_SWS_CANDriver §7.x «Error Notification». Вопрос Q-d23c45dd3b23ec71 (открытый)