Ожидает ли работа периферийного устройства CAN в STM32 выполнение кода процедуры ISR? - PullRequest
Новая
       81

Ожидает ли работа периферийного устройства CAN в STM32 выполнение кода процедуры ISR?

0 голосов
/ 26 февраля 2019

Я разрабатываю на микроконтроллере STM32L433 уровень стека, использующий протокол CAN;фундаментальной частью стека является аутентификация устройств.Во время аутентификации может произойти, что два (или более) устройства начинают отправлять сообщение CAN (сообщение аутентификации) с одним и тем же идентификатором и различной полезной нагрузкой (истинное случайное значение).В этом случае каждое устройство должно быть в состоянии определить, было ли это сообщение отправлено первым с другого устройства.

Я изучил этот случай, и могут возникнуть 3 ситуации:

  1. устройства начинаютотправить сообщение одновременно;в этом случае только одно устройство может отправить сообщение, потому что все другие устройства обнаруживают одну ошибку и затем прерывают передачу.
  2. только одно устройство может отправить сообщение и занять шину до того, как все другие устройства загрузятПОЧТОВЫЙ ЯЩИК CAN периферийного устройства или перед тем, как периферийное устройство CAN других устройств установит сообщение, которое будет отправлено в состоянии SCHEDULED.В этом случае устройства, которые не смогли отправить сообщение, получат прерывание приема;в рамках процедуры приема ISR я могу прервать передачу.
  3. только одно устройство может отправить сообщение и занять шину, а все другие периферийные устройства CAN других устройств имеют сообщение в состоянии SCHEDULED и ожидаютэтот автобус простаивает.В этом случае устройства, которые не смогли отправить сообщение, получат прерывание приема.Также в этой ситуации я думал остановить передачу в рамках процедуры приема ISR (как в ситуации 2)), но я не уверен, что это гарантировано для всех сообщений, потому что если периферийное устройство CAN устанавливает сообщение, которое будет отправленов состоянии ПЕРЕДАЧИ до того, как код внутри ISR будет выполнен, операция прерывания не будет иметь никакого эффекта.

Мой вопрос (относится к ситуации 3): сообщение в сообщении MAILBOX в SCHEDULEDсостояние устанавливается в состояние TRANSMISSION, после чего выполняется код в принимающей подпрограмме ISR, или это не гарантируется?

1 Ответ

0 голосов
/ 26 февраля 2019

Сначала ответьте на ваш 3-й случай, нет, это не гарантирует, что ваше сообщение не находится на шине, во время получения.Потому что прерывания также могут иметь некоторую задержку, и в течение этого времени почтовый ящик сможет продолжить передачу.

Ваша «аутентификация» также звучит немного хлопотно, поскольку никто из сторон не может на самом деле решить,какой именно ECU был именно тем, который выиграл арбитраж и фактически отправил это конкретное сообщение.

У нас есть ECU в транспортных средствах, которые определяют во время работы в соответствии с определенными методами, где они монтируются с помощью булавки и некоторого приема CAN,но только в режиме прослушивания TX фактически отключен в стеке.После того, как это обнаружение завершено, мы переключаем конфигурации и перезагружаем comm-стек и далее инициализируем SW, повышающийся.Но эти «настройки» обычно определяются заранее, например, из-за главного / подчиненного (связь между автомобилем / частной шиной), или, возможно, некоторыми соединительными штырьками, подключенными к GND / OPEN / UBAT, или, возможно, некоторым сообщением шины, которое сообщает, на какой шине оно включено.,

Это кажется более надежным, чем ваш метод.

...