lead_seller

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

Спасибо за информацию. Действительно начал вчитываться в доступное, там расписывается алгоритм арбитража именно в Arbitration field. Не подскажите, где можно посмотреть именно по коллизиям вне поле арбитража? К сожалению доступа к ISO 11898 не имею, а общедоступные статьи описывают только арбитраж в поле заголовка пакета.

Stuff error - это ошибка стаффинга. Возникает она в случае, если передающее устройство передает больше чем 5 одинаковых бит. В стандарте CAN заложено прореживание последовательностей из 5 одинаковых бит, противоположными битами. Например, если вы передаете 0xFF ну или 0b1111 1111, то в шину будет передано 0b111110111. Соответственно, либо к Вам приходит сообщение, которое нарушает этот стандарт (а это может происходить из-за разницы в скоростях приемник-передатчик), либо Ваша шина находится в доминантном состоянии, что расценивается как непрерывная передача бита "1". Посмотрите, что происходит на шине, при включении Вашего приемника. И посмотрите, что происходит на ногах CAN_RX и CAN_TX драйвера. Попробуйте поотправлять сообщения при подключенном драйвере, но отключенной шине. При включении любого CAN-приемника в сеть, Вы должны увидеть прямоугольный импульс - это проходит тестирование шины. Так же, при начале передачи каждого пакета вы увидите переход из рецессии в доминанту - это занятие линии.

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

После конца фрейма - 1.5 байта, перед началом следующего 2 байта промежутка. Отсюда и набегают те самые 3.5 байта. Намного проще не завязываться на эти самые байты, а сделать регулируемый разрыв пакетов в сервере, и соответственно его же настроить на клиенте. Как собсно в большинстве модбас устройств и делается.

Вообще в CAN коллизия ошибкой не является и не ведет к порче данных. Передатчик, проигравший арбитраж, перестает передавать и ждет освобождения шины, после чего передает свое сообщение. Ошибкой может стать блокировка шины, когда на шине образуется доминанта, и передатчики не могут запустить передачу. Тогда формируются ошибки шины связи.

Вообще, насколько помню EIA/TIA-485, официальное ограничение на дальность - 1,2 км. Дальше на свой страх и риск. Из собственной практики - 3 - 3.5 км на нормальной витухе при скорости 9200, и 2.5-3 км. на утопленный и счаленный в нескольких местах шахтный кабель неизвестного происхождения. Но, повторяюсь, на свой страх и риск - стандарт не одобряет. Единственно - нормальная терминация длинной линии, заземление экранов кабеля, ну и защита приемо-передатчиков.

В стандарте CAN 2.0B, если не изменяет память, есть система TimeStamp. Позволяет маркировать сообщения TimeStamp ом - меткой времени. Этот штамп можно использования в протоколе передачи данных.

В связи с переездом в РФ ищу работу инженера-электроника/программиста ПО микроконтроллеров Ключевые навыки и опыт: - Семейства микроконтроллеров: C51, AVR, AVR32 (ограниченно), PIC12-PIC24, ARM (STM32F0 - STM32F4, STM32W, LPC210x), TI CC2530 (ограниченно) - Среды программирования: uVison KEIL (C51, ARM); WinAVR+AVRStudio, CodeVision (AVR) и др. - Интерфейсы: наплатные: I2C(TWI), I2S, SPI, 1-Wire Fieldbus: RS232/485 (Modbus,DBUS) /422, CAN, Ethernet, USB - Пакеты САПР: Altium Designer/PCAD, SolidWorks, AutoCAD - Опыт разработки аналоговых цепей, для работы с датчиками физических величин (концентрация газов, давление, температура) - Разработка блоков питания/ИБП мощностью до 100 Вт, для специфических условий применения - Разработка многослойных ПП (до 4 слоев), включая платы для радиопередатчиков на частотах 2.4ГГц (для RF SoC STM32W и CC2530) с применением наплатных и дискретных чип-антенн, плат с использованием HF RFID меток - Опыт разработки взрывозащищенного и искробезопасного оборудования для применения в условиях угольных шахт и других взрывоопасных сред - Опыт внедрения и шеф-монтажа распределенных систем автоматизации (системы комплексной автоматизации и безопасности угольных шахт). Наладка, определение неполадок и их устранение в ходе монтажа и эксплуатации оборудования систем и каналов связи. - Опыт работы ведущим инженером и сопровождения электронных устройств на всех этапах их жизненного цикла. - Опыт управления группами инженеров и монтажно-наладочным персоналом. Для связи: [email protected] С полным опытом работы и другой информацией можно ознакомиться по адресу: http://hh.ru/resume/4b5df3f2ff020c8f430039ed1f61316770374c

У TJA роль терминальных резисторов выполняют два резистора, которые цепляются на спец. ноги. При этом номинал этих резисторов подбирается в зависимости от количества устройств на шине. В моей практике прекрасно уживались MCP и TJA. При этом TJA со своей обвязкой прекрасно работали в качестве терминаторов линии. Проблемы с Fault-safe CAN на скорости 125 кб/с могут возникать не из-за совместной работы MCP и TJA, а из-за ограничения скорости в 100 кб/с для Fault-safe драйверов.

не знаю, актуально еще или нет. Это у Вас не автогенерация, а срывающееся тестирование линии. При старте передаче CAN устройство в первый квант времени выставляет доминанту на линии и проверяет скорость ее установления на линии. Если скорость не удовлетворяет устройство, оно начинает гнать вот такой меандр, в надежде что параметры линии улучшатся. Возникает такая ситуация при большой емкости линии - скорее всего превышена максимальная длина сегмента для выбранной Вами скорости. Опять же, репитеры у вас взяты физические, фактически они лишь усиливают сигнал, при этом не отправляя подтверждений передающим устройствам, вполне возможно Ваша проблема связана именно с этим. Попробуйте в обоих сегментах, разделенных репитером установить по CAN-устройству.

http://cq.cx/ladder-ru.html Посмотрите в сторону этого. Оно и полностью сишный код генерит для контроллеров и есть исходники исполняющей машины, так что вполне можно вставить отдельно в свой проект.

С атмеловским CAN не работал, но общие размышления подкину. Посмотрите в сторону прерываний модуля CAN. Вполне возможно, что у Вас есть прерывание проигрыша арбитража, или вообще ошибок на линии. В таком случае, периферия контроллера может ожидать обработки этого прерывания, или хотя бы сброса флага этого прерывания. А вообще - скорости 100 кб, и тем более 500 кб это не такие уж и маленькие скорости для CAN, может быть проблема в длине линии передачи?

MCP2551 - это дравер физического уровня HS-CAN. К нему нужен еще сам приемо-передатчик - либо внешний, вроде того же MCP2515, либо внутренний - сейчас у большинства производителей микрокоонтроллеров есть камни со встроенным CAN передатчиком (у PIC в 18 серии что-то было, у ST CAN есть в сериях старше 103-ей). На мой взгляд удобней внутренний - у того же STM в их stm32f103 серии очень вменяемая и удобная CAN-периферия.

Попробуйте поотключать остальные устройства от USB. У меня были проблемы с одновременно подключенным PICKit и устройством на FT232. Вытаскивал одно из них - все начинало работать.