Comments 53
"Стрелка осциллографа" - сразу плюс от меня вам. А вообще, я поражаюсь продуктивности таких, как вы авторов. Спасибо, что стараетесь!
Сравнение интерфейсов можно произвести вот в этом реестре
что то как то много знаков вопроса в этой таблице.
Зачем в CAN нужен remote кадр?
многие похоже не осилили эту мощную технику. даже довольно сложные анализаторы не все умеют правильно реагировать на этот бит. изобретатели протоколов игнорируют эту возможность, реализуют ее на своем уровне, да еще инкапсуляция пакетов: теряется оригинальная изящная задумка.
Как определить сколько time quantum (Tq) следует выделить предделителем
самое интересное что есть некоторые рекомендации не делать слишком маленький квант помимо аппаратных ограничений, на вскидку не могу найти
самое интересное что есть некоторые рекомендации не делать слишком маленький квант
Для коротких Tq нужна нужна высокая частота тактирования CAN-трансиверов. Высокая частота - подскакивает энергопотребление. Следствие - сажается аккумулятор.
Результат - утром не завести автомобиль .
это как же надо жрать что такой акум высадить :) я думаю что на потребления и в автомобильной электронике не очень парятся, судя по некислому оверинжиирингу, тем более что can гонять, особенно все шины, на выключенном по сути автомобиле - тоже овержинжиниринг. ну и не автомобилем единым can работает.
в НИИЭТовских контроллерах прописано ограничение 24 чтоли tq а они больше для электроприводов
Если CAN в авто постоянно просыпается и этим высаживает батарейку, то это авто болеет. Надо искать больной блок, что будит всю машину. А ещё у современных авто на батарейке есть измеритель тока, который запишет ошибку если потребление во сне или при выключенном зажигании выше определённого порога.
Это для того, чтобы после ID ответчик прям тут же дорисовал кадр запрошенными данными? Тогда изящно, да.
CAN-матрица
а это стандартизованный термин? вроде не вот часто встречаю
CAN-матрица — это схема организации данных в сети CAN, определяющая, какие данные передаются между какими устройствами, и как эти данные интерпретируются. CAN-матрица обычно представляет собой таблицу, в которой указаны идентификаторы сообщений, данные, которые они содержат, и устройства, которые их отправляют и получают. Она позволяет разработчикам настраивать и управлять обменом данными в сети CAN.
CAN-шина (Теория)
У меня вопрос по теории: как проектировать системы, использующие CAN?
У нас есть N устройств, которые должны в гарантированные промежутки времени (обещали реалтайм!) "высказаться". Часть из них более приоритетные, часть - менее. Если устройств достаточно много то как определить успеют ли они высказаться все в какую-то единицу времени?
То есть, где гарантия что все устройства (разложенные по приоритетам и всё такое прочее) успеют высказаться? "Математически" это доказать можно?
Что об этом говорят официальные гайды от производителей, например?
Зная скорость можно расчитать сколько шина через себя успеет прокачать. Если всё не сильно жестко, можно посчитать сколько пакетов шина через себя может пропустить. И посчитать сколько будут генерировать устройства. Если пакетов меньше чем шина через себя готова пропускать, то с большой вероятностью оно будет работать. Хорошо бы запас конечно иметь 10% на случай перепосылки.
Именно про это мой вопрос: а как это посчитать? Оно ведь явно не просто суммируется, ведь могут быть коллизии
Именно про это мой вопрос: а как это посчитать?
Берем размер пакета, желательно максимального, считаем сколько в нем бит(включая все служебные), берем скорость и делим на это число. получаем число пакетов в секунду.
ведь могут быть коллизии
По идее и быть не должно, даже при одновремнной начале передачи пакета несколькими устройствами, арбитраж выигрывает устройство с меньшим адресом.
Часть из них более приоритетные, часть - менее.
В кане не бывает 2х устройств с одинаковым приоритетом. Каждый ID отличается от соседнего на 1 ступень в ту или иную сторону. ID с максимальным приоритетом это 0. В теории он может забить шину и все остальные лососнут тунца. В противовес ему есть ID с нулевым приоритетом: 7FF для стандартного ID и 1FFFFF для расширенного ID. Этот может не высказаться ни разу, даже если 0 не забивает шину. Приоритезация сообщений на шине это задача проектировщика, нужно планировать такое поведение ID с высоким приоритетом, чтобы они давали хотя-бы теоретическую возможность высказаться ID с низким приоритетом.
Все узлы на шине, которые правильно получают сообщение (независимо от того, «интересуются» ли они его содержимым или нет), должны выполнить подтверждение, то есть отправить доминирующий уровень в так называемом слоте подтверждения в сообщении.
То есть, технически, все принимающие устройства одновременно подтянут шину вверх в нужный момент (в момент прохождения флага ask)?
Как будет выглядеть вырожденный вариант шины на 2 устройства?
Я пробовал соединить их CAN_H и CAN_L, и даже ставить резистор в 60Ω между ними, связности нет
А теперь внимание, все эти механизмы работают полностью аппаратно на уровне ASIC или MAC
Я так понимаю, что это не обязательно. Просто есть недорогие аппаратные приемо-передатчики. Но что может помешать реализовать програмно если аппаратной поддержки в требуемом контроллере нет?
Малейший джиттер вашей программной реализации положит всю шину наглухо. Аппаратная реализация нужна для выдерживания жёстких таймингов, ведь надо успеть дать АСК проверив контрольную сумму битом ранее.
Но что может помешать реализовать програмно если аппаратной поддержки в требуемом контроллере нет?
Если MCU не поддерживает CAN (например MIK32), то можно пристегнуть ASIC трансиверы переходники с SPI на CAN. Например
TJA1145T/FD
MCP2515
TCAN4550RGYRQ1
TCAN4550-Q
Но что может помешать реализовать програмно если аппаратной поддержки в требуемом контроллере нет?
Тогда уж на Verilog HDL.
Но что может помешать реализовать програмно если аппаратной поддержки в требуемом контроллере нет?
Ничего не мешает написать код (FSM), который по массиву семплов от CAN-RX в post обработке распознает CAN пакет. Семплы можно читать либо GPIO либо ADC.
Через ADC(GPIO)+DMA записали c линии CAN_RX 0101010110000111 (однобитные семплы) за последние 1ms и положили в FIFO.
Только надо много RAM памяти, чтобы семплы эти где-то хранить.
Далее ЦОС обработка. Обсчитываем и извлекаем структуру пакета через конечные автоматы.
Условно записали через ADC+DMA 2....5 ms c линии CAN_RX и 10ms...100ms их обсчитываем.
Просто это будет работать не в real time.
+ надо какое-нибудь фиктивное устройство, которое будет ACK ставить, так как это надо делать в real time. Без этого на стой стороне начнется flude.
С отправкой всё много проще.
Сформировали массив семплов и отправили по GPIO(DAC) через DMA в CAN_TX.
С отправкой всё много проще.
Сформировали массив семплов и отправили по GPIO(DAC) через DMA в CAN_TX.
Ага, наплевав на арбитраж - главное свойство CAN шины. Передатчик CAN всегда мониторит шину на предмет соответствия того, что он выдаёт. Если он обнаруживает несоответствие, то обязан отключиться и ждать следующее окно для переотправки. Так организован арбитраж и 0 коллизий на шине.
Но что может помешать реализовать програмно если аппаратной поддержки в требуемом контроллере нет?
Прям помешают - только криворукость программиста который должен будет учесть много нюансов в том числе и чисто аппаратных. Мне хотелось бы верить что can аппаратуру тестируют долго и упорно на все все возможные баги, сертификация опять же - что дает некоторые гарантии стабильной работы. И вполне вероятно что в ее состав входит не чисто схемотехника, а какой нить микрокод.
Как минимум это (сильно) грузит основной проц работой. Так что делать такое приходиться "не от хорошей жизни", но таланты на такое иногда находятся. так usb сделали программно и этот код тысячи устройств используют, а уж uart и всякие интерфейсы (магнитофон, АОН) попроще делали кодом еще во во врмена ВМ80 и Z80
На конце каждого CAN узла заложен резистор 120 Ом.
По концам шины нужны терминирующие резисторы.
Вы уж определитесь. Правильный вариант только один.
Вы ведь даже картинку привели
Скрытый текст
Подать тактирование на CAN трансивер
CAN трансивер - это ваша TJA1044. И никакое тактирование на нее подавать не надо. Вероятно, вы хотели сказать "включить тактирование контроллера интерфейса CAN в микроконтроллере"
Скрытый текст
Не та ветка
Если нет CAN переходника к компу, а надо прям край и есть 485 переходник, то можно сделать вот так
Нужно было настроить одно оборудование, утилита для работы с ним была, а переходника не было. Так и извернулся. Но это я на 9600 тестировал и то - десяток регистров поправить.
сдается мне то был знаменитый can который совсем не can а uart с физикой от can, что применяется в некоторых счетчиках. Иначе кроме физики еще надо по биту оцифровывать и передавать, т.к. стандартная структура пакетов очень разная
Зачем такое извращенье?
Возможно, оно и было так, обработкой пакетов занималась фирменная утилита, а я в подробности не вдавался. Физика там была точно кановская, потому что я изучил входные цепи этого оборудования,и там был именно кан-трансивер, не помню какой но распространенный. Но факт - мой rs485 определялся виндой как ком-порт, утилита хватала этот ком-порт и уже с ним работала именно как с uart. Значит, оно.
До такого могли додуматься только наши российские люди.
Вот еще пример на тему того, как наши люди "микроскопом гвозди забивают".
Аппаратный таймер в качестве датчика звука
https://habr.com/ru/articles/845330/
С чем связан такой пиар каншины??
Когда я работал в АвтоВАЗе, то за чаепитием с российскими программистами МК там я с удивлением для себя обнаружил, что никто из них не знает, что такое CAN bus-off
При этом у каждого них по 10 -15+ лет российского embedded опыта.
Вот и решил написать небольшой ликбез по основам CAN classic.
с чем связан такой вопрос :)
Есть ли какая бесплатная клиентская Windows CAN утилита, которая посылает и принимает по ISO-TP огромные массивы сырых данных (бинарные файлы)?
Утилита, которая оперирует не на канальном уровне, а на транспортном.
Что-нибудь типа аналога культового tool-ы NetCat, только не для Ethernet, а для CAN.
Как можно протестировать готовый драйвер CAN трансивера?
Какие эффективные модульные тесты провернуть?
Какие эффективные интеграционные и нагрузочные тесты составить?
CAN-шина (Теория)