jcxz

Вроде как очевидно о какой задержке речь: Сейчас результат решения "отправится кадр сейчас или нет" определяется уже в конце передачи CAN-ID + пара_бит. Соответственно - начиная с этого момента отправляющая сторона уже может считать кадр отправленным. И например - начинать готовить новый кадр на передачу; или готовиться к приёму ответа (если таковой ожидается). С этого момента может освободить память, занимаемую отправляемым кадром и использовать её для других нужд. Если же арбитраж шёл бы по всему кадру, то такой момент времени наступал бы гораздо позже - после полного завершения отправки всего кадра. Если будет понятнее по аналогии с UART, то: Когда записывать следующий байт в TX-буфер UART: после получения флага "буфер передатчика пуст" или после "сдвиговый регистр передатчика пуст"? Стандартно - по первому флагу. Но можно действовать и по второму флагу, но тогда вероятность межсимвольных дырок в передаваемом потоке будет гораздо выше. Здесь (в CAN) то же самое. Только разница во временах значительно больше. Также и в CAN - если бы арбитраж шёл по всему кадру, то у отправителя было бы очень мало времени для подготовки нового кадра. (Если по каким-либо причинам невозможно готовить новый кадр при неотправленном предыдущем) А значит - вероятность межкадровых дырок в сплошном потоке кадров выросла бы. Т.е. - упала бы средняя скорость потока данных. Ок. Не нравится аналогия с дверью+пальцем, тогда аналогия со смартфоном: Вот предположим - разработчики вашего смартфона - ваши единомышленники. Причём все - всех компонентов смартфона. А значит - иногда у вас на экране выводится какой-то мусор, иногда из динамика валит шум, иногда звонить отказывается. Ну а на ваше недовольство его работой, разработчики также вам скажут: "ну какие проблемы? Чего тебе трудно ещё раз попробовать позвонить? или ещё раз перегрузить телефон? или батарейку вынуть/вставить - трудно что-ль? Телефон же не сгорел, чего же страшного?" "Не выпала монетка - кидай ещё раз". А если разработчики вашего авто такие же? Не побоитесь садиться в него?? PS: Но почему-то халтурщики и кое-какеры возмущаются, когда сталкиваются с чужой халтурой. Сами же халтурить считают нормальным. Почему так??....

Да вы что! Обычная костылестроительная практика. Да и не исправляется ничего, а просто костылится.

Эх - боитесь вы юзверя, боитесь!

Вот мнение Всемирного Разума по вашему вопросу: Целых 5 пунктов!

Типа "керосин осветительный " ? ..или "освЯтительный". Смотря о каких лампадах шла речь. Вообще вода, будучи очищенной до состояния дистиллированной, имеет довольно высокое сопротивление - порядка нескольких МОм/см. Лучший совет.

Неправильно помните. Только на ID + несколько стартовых бит заголовка кадра. Если один девайс, то конечно - какие проблемы? А если их несколько, то чем больше и чем чаще орут - тем выше вероятность, что получите коллизии. А если при этом по шине ещё и штатный обмен идёт? Да ещё довольно интенсивно? То вероятность коллизий получите весьма высокую. Если вам дверью прищемило палец - и что? Через рандомное время ведь всё равно заживёт. Так и здесь. С таким подходом конечно - какая разница? А в нормально разработанном девайсе не должно быть коллизий, возникающих при штатной работе девайса в идеальных условиях. Если девайс генерит коллизии при штатной работе в идеальных условиях - такой девайс годится только в мусорку. Имхо. Всё зависит от задачи. Где-то и раз в час можно новые двеайсы обнаруживать, а где-то это слишком долго. Зачем выдумывать кривые варианты, если для такого есть нормальное решение? Без коллизий и прочего непотребства? Обсуждали ведь уже ранее... И здесь у Arlleex протокол вообще не про это.

Плохой способ. Если количество источников данных, их размерность и периодичность посылки от каждого источника - задаются пользователем (конфигурятся) и варьируются в широких пределах. Тоже плохой способ. Забываете про коллизии. Будете получать мусор или ошибки CRC на шине при штатной работе без воздействия каких-либо помех. Смысл этой фразы неясен... Передачи различающихся данных от разных узлов CAN "на одном ID" чреваты неразрешаемыми коллизиями в данных. Только абсолютно идентичные данные так можно передавать.

Таймеры XMC4xxx не имеют "худых концов". Любые мыслимые взаимодействия между ними возможны. Аппаратными сигналами между таймерами, конфигурируемыми самим программистом. Рекомендую.

Варианта 2: или традиционный - сверху вниз; или современный - слева направо. Можно и так и так. Такое ощущение, что никто тут на форуме про Unicode даже не слышал.... Проснитесь! Весь мир уже давно в Unicode живёт. В моём 3D-принтере (пришедшем как раз с али) уже все иероглифы (да и буквы других языков) хранились в прошивке в Unicode (UTF-8). В самом обычном, "народном", STM32F103. И ничего - как-то справлялся. В 1914-м, в начале 1-й Мировой, тоже никто не думал, что конец династии Романовых совсем близок. И тоже наверняка были подобные прогнозёры. А минуло всего 3 года и....

Ясно в целом. У вас получается несколько другая цель протокола. И соответственно - сделан упор на реализацию другой его части, чем у меня. Вот ещё вопрос: Раз цель - чтобы "сторонний разработчик не вдавался в детали", то почему нет компонента, выдающего прогнозируемую загрузку шины? Например: Настройщик (или кто там настраивает конфигурацию CAN-ID на шине) так как он не хочет "вдаваться в детали", то может выставить такой конфиг, при котором будет невозможна работа шины из-за недостаточной пропускной способности на данной скорости. У меня, в части настройки адресов (CAN-ID), с которых будет осуществляться периодическая отправка сообщений (телеметрии), конфигурационная программа показывает настройщику примерную прогнозируемую загрузку шины (конечно - для случая идеальной, безпомеховой связи). И выдаёт предупреждение, когда эта загрузка приближается к 100% (точнее 100% - заданный_порог_резерва). Имхо: При такой идеологии (расчёт на недумающий персонал) такой компонент был бы весьма полезен.

Так если они сконфигурены на заводе не понятно как, то тогда вероятны конфликты по полям CAN_ID_RX_TOP_ROOT и CAN_ID_TX_TOP_ROOT (почему я про них и спрашивал). А значит в общем случае - не всегда будет возможно опросить. Уникальными вообще (глобально) они быть не могут, поскольку малоразрядные. Или возможно - я чего-то не понял из вашего протокола... (читал мельком - нету времени).

Т.е. - CAN_ID_RX_TOP_ROOT и CAN_ID_TX_TOP_ROOT - эти 8-битные идентификаторы должны быть сконфигурены на узлах? А почему не Unicode? Вдруг экспортировать куда-нить захотите... Я у себя задаваемый пользователем идентификатор узла делал в UTF-8. PS: А вообще конечно - труд эпический! Всё это самостоятельно писали?

Что является существенным недостатком UART-а STM-ов. Гораздо правильнее было бы в DMA отдавать слова данных дополненные флагами ошибок. Для каждого слова.

Как это работает в STM-ах я прекрасно знаю. И говорю на основе собственного опыта и мануала. А судя по вашим постам - вы только теоретизируете. Я сказал следующее: Просто прочитать принятое слово и всё. Что именно здесь по вашему является "глупостью" и почему? И ни от чего не отказываюсь. Всё так и есть. А вот за понимание вами написанного - я ручаться не могу. Или лучше расскажите - как следует по вашему работать с флагами в STM? Если вы реально имеете какой -то опыт, а не теоретизируете впустую. Ну вот - сперва ляпнул глупость, а теперь начинает выкручиваться.

Я писал для общего случая. PS: Совсем не обязательно, что у ТС-а при каждом fault-е одна и та же картина в регистрах причины fault. И вполне возможно (и судя по всему так оно и есть), что багов там несколько. И возможно они вызывают разные fault-ы. Вроде как очевидно, что раз мы знаем, что соответствующий флаг стоит (который нужно сбросить), то как мы об этом узнали (что он стоит)? Очевидно - что уже ранее прочитали регистр статуса. А значит теперь для его сброса нужно только чтение слова данных. Нестоящий флаг сбрасывать нельзя.