Забавно, слышать, что для Agile строятся планы по внедрению чего-то.
Видимо наш клиент, который решил разработать для себя некую систему и вплести в неё нашу систему, как-то не так понимает этот Agile. Устраивает встречи с болтовнёй иногда на несколько часов, рассказывает, что они хотят увидеть от нас к такой-то дате (Agile или всё таки Waterfall). А потом, когда сроки подходят, начинаю орать «а-а-а-а-а, всё пропало, половину того, что сделано, надо выкинуть и сделать совершенно другое и вообще мы делали не то, что они запланировали». А когда им показываешь бумагу с итогами встречи, то говорят, чтоб мы эту бумагу запихнули куда подальше, а у них Agile.
Видимо мы что-то не понимаем в Agile, либо клиент и у них в головах вместо Agile бардак.
Но какое это отношение имеет к рассматриваемому примеру? И что вообще должен был проиллюстрировать пример? Мне показалось, что неявно подразумевалось утверждение «устройство, посылающее 7E2, будет мешать устройству, пославшему 7DF».
Я плохой пример привёл, а после освежения знаний понял, что он не правильный. Проблема действительно возникнет только когда 2 устройства пошлют сообщения с одним идентификатором.
Стоп. Если широковещательный запрос подразумевает получение ответов в диапазоне 7E8+X, то его и должны обрабатывать все, кто посылает такие ответы.
В принципе да.
Я ранее не правильный пример привёл, проблемы начинаются, когда 2 устройства начинают посылать диагностические запросы с помощью широковещательного сообщения.
То есть, подразумевается, что на широковещательный запрос 7DF ответы приходят те же самые, 7E8+X, что и на адресные запросы?
Да, это так, но это в случае стандартизированной диагностики. Некоторые модули могут слушать сообщения вообще с другими идентификаторами и работать по протоколу UDS.
А что изменится, если не будет адресного запроса 7E2, а только широковещательный? Все равно ведь придут те же 7EA и 7EC, не так ли?
Нет, только от того, кто этот запрос может обработать.
может случиться, что устройство отвалится от шины или вообще выйдет из строя, и не пошлет ожидаемого сообщения, и тогда если вместо фильтра по ID мы таки ждем «первое пришедшее», то опять же примем не то что ожидали.
Там даётся время, в течении которого должен прийти ответ. Время на память не помню, но отрезок маленький.
Освежил сведения, да, время, в пределах которого ожидается ответ, минимально и равно 50мс. И да, в ответе содержится информация, что за ответ прилетел.
Но даже если представить, что ответ у нас содержит информацию, что запросили, как будет разруливаться ситуация, когда два устройства посылают 7DF? Тут никакой арбитраж не поможет. Вылезет ошибка.
Арбитраж есть, но он по сути также отвечает за приоритет отправки сообщений.
Стандартная диагностика живёт на запросах широковещательных 7DF или адресных 7E0+X и ответах 7E8+X, где X от 0 до 7. При отправке широковещательного запроса на 7DF, ответ прилетит от 7E8+X.
А теперь представьте картину, ваши устройства отправили запросы с идентификаторами 7DF и 7E2, а ответы прилетят 7EA и 7EC. Как мы видим, устройство, оправившее адресный запрос 7E2, ожидает ответ от 7EA и корректно отработает, а вот устройство, отправившее 7DF, обработает первый ответ из интервала 7E8+X.
А так, шина предполагает, что в ней не будет работать 2 устройства, которые посылают сообщения с одним идентификатором.
С этим согласен. И когда сканируешь CAN, то лучше это делать на ходу и не одному.
Я, для одного проекта, как раз записывал в лог данные шины во время поездки, а после сидел и пялился на цифры, припоминая маршрут и что было на пути. А чтобы было проще, то записанный лог проигрывался в программе.
В итоге нашёл всё необходимое и больше.
А почему решили работать через диагностику, а не с сырыми данными? Просто, если решите параллельно подцепить ELM327 или что-то иное, то железо начнёт конфликтовать.
За климат и отображение его отвечает низкоскоростная шина комфорта, которая живёт отдельно, но, как и высокоскоростная основная, тоже заведена в на шлюз.
Лучше работать с данными напрямую, не нужно будет дёргать шлюз, выдерживать таймеры, а просто читать прилетевшие данные и отображать. Это будет более оперативно (высокоприоритетные данные могут прилетать каждые 10мс). А чтобы лишнее не прилетало, то задать фильтры. Правда у MCP2515 их всего 6, но что-то в даташите как-то непонятно про них. Тут бы я воспользовался каким-нибудь STM32 (F105 например) с CAN на борту. Там их 28 полноценных штук. Хватит за глаза.
Если нужно будет как-то стирать ошибки, то можно подсмотреть в шине, что посылает шлюз в шину, когда стирает ошибки из разных блоков.
Видимо наш клиент, который решил разработать для себя некую систему и вплести в неё нашу систему, как-то не так понимает этот Agile. Устраивает встречи с болтовнёй иногда на несколько часов, рассказывает, что они хотят увидеть от нас к такой-то дате (Agile или всё таки Waterfall). А потом, когда сроки подходят, начинаю орать «а-а-а-а-а, всё пропало, половину того, что сделано, надо выкинуть и сделать совершенно другое и вообще мы делали не то, что они запланировали». А когда им показываешь бумагу с итогами встречи, то говорят, чтоб мы эту бумагу запихнули куда подальше, а у них Agile.
Видимо мы что-то не понимаем в Agile, либо клиент и у них в головах вместо Agile бардак.
В принципе да.
Я ранее не правильный пример привёл, проблемы начинаются, когда 2 устройства начинают посылать диагностические запросы с помощью широковещательного сообщения.
Нет, только от того, кто этот запрос может обработать.
Там даётся время, в течении которого должен прийти ответ. Время на память не помню, но отрезок маленький.
Освежил сведения, да, время, в пределах которого ожидается ответ, минимально и равно 50мс. И да, в ответе содержится информация, что за ответ прилетел.
Но даже если представить, что ответ у нас содержит информацию, что запросили, как будет разруливаться ситуация, когда два устройства посылают 7DF? Тут никакой арбитраж не поможет. Вылезет ошибка.
Стандартная диагностика живёт на запросах широковещательных 7DF или адресных 7E0+X и ответах 7E8+X, где X от 0 до 7. При отправке широковещательного запроса на 7DF, ответ прилетит от 7E8+X.
А теперь представьте картину, ваши устройства отправили запросы с идентификаторами 7DF и 7E2, а ответы прилетят 7EA и 7EC. Как мы видим, устройство, оправившее адресный запрос 7E2, ожидает ответ от 7EA и корректно отработает, а вот устройство, отправившее 7DF, обработает первый ответ из интервала 7E8+X.
А так, шина предполагает, что в ней не будет работать 2 устройства, которые посылают сообщения с одним идентификатором.
Я, для одного проекта, как раз записывал в лог данные шины во время поездки, а после сидел и пялился на цифры, припоминая маршрут и что было на пути. А чтобы было проще, то записанный лог проигрывался в программе.
В итоге нашёл всё необходимое и больше.
За климат и отображение его отвечает низкоскоростная шина комфорта, которая живёт отдельно, но, как и высокоскоростная основная, тоже заведена в на шлюз.
Лучше работать с данными напрямую, не нужно будет дёргать шлюз, выдерживать таймеры, а просто читать прилетевшие данные и отображать. Это будет более оперативно (высокоприоритетные данные могут прилетать каждые 10мс). А чтобы лишнее не прилетало, то задать фильтры. Правда у MCP2515 их всего 6, но что-то в даташите как-то непонятно про них. Тут бы я воспользовался каким-нибудь STM32 (F105 например) с CAN на борту. Там их 28 полноценных штук. Хватит за глаза.
Если нужно будет как-то стирать ошибки, то можно подсмотреть в шине, что посылает шлюз в шину, когда стирает ошибки из разных блоков.