ЗАО «ЗЭО»
Техническая поддержка пользователей => Тион, Тион-Про, Тион-Про v2, Сириус => Тема начата: MOHOMAX от 11 Июня, 2011, 15:42:22
-
Здравствуйте!
Купил у вас CAN адаптер для тион-про2. Пытаюсь наладить соединение по CAN с внешним устройством, но пока не получается. Вот какие мои действия:
1. подлючил CAN адаптер к тиону
2. На тион залито ядро с подержкой CAN
3. выплняю команду ifconfig can0 up и вижу, что появился интерфейс CAN:
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MULTICAST MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
4. Скачал с вашего сайта пример программы по работе с CAN (can-test_svn733), собрал её для тиона и запускаю:
Запуск выглядит так:
# ./can-test -e 0xAA -l 5 -d 12345
can-test: ext. id, hex: AA
can-test: length: 5
can-test: data, hex: 00 00 01 23 45
wwwwwwwwwwwwwwwwwwwwwwwwwwwww
И вижу, что символ "w" печатается и печатается.
Функция send возвращает ошибку и strerror говорит, что ошибка No buffer space available.
5. Смотрю осциллографом на линии CAN - там тишина
Что я делаю не так? Как заставить CAN адаптер отправлять и принимать данные?
PS: плата тион-про2, ОС Linux
-
5V на X5 подали?
-
X5 это разъем на адаптере который? Да, подавал. Хотя я прозванивал линии и понял, что эти 5В идут только на DC-DC, а питание микросхем адаптера осуществляется от 3В с SPI разъема. Хотя может я и ошибаюсь.
В общем 5В я подавал и на выходе ничего не видел.
Есть ли возможность получить принципиальную схему адаптера?
-
> Есть ли возможность получить принципиальную схему адаптера?
5V ещё на ИМС изолятора и на ИМС формирования физ. уровней.
> Есть ли возможность получить принципиальную схему адаптера?
http://www.zao-zeo.ru/media/files/adapters/can-spi-adapter_rev2_circuit.pdf
-
за схему спасибо!
Я ещё раз проведу эксперимент с подачей 5В на разъем и отпишусь
-
> Смотрю осциллографом на линии CAN - там тишина
Вы смотрите сразу или после сообщения об ошибке?
Ошибка нормальна, если у вас нет на шине принимающего сообщения устройства.
-
осциллограф я включаю до отправки какой либо команды. Осциллограф работает в режиме триггера по изменению уровня. То есть любая активность на линии CAN будет отображаться на экране. Я отправляю команду на отправку данных по CAN, но на линиях тишина. Осциллограф подключен так: земля - к CAN-H, сигнал - CAN-L.
Но принимающего устройства действительно нет.
-
ситуация немного изменилась.Я подал 5В на X5 и смотрю осциллографом на линии CAN. Выполняю:
# ./can-test -e 0xAA -l 5 -d 12345
can-test: ext. id, hex: AA
can-test: length: 5
can-test: data, hex: 00 00 01 23 45
..........wwwwwwwwwwwwwwwwwwwwwwwwwwwww
can-test: Send packets (-1): 10, errors: 0
#
Как можно заметить в начале мы видим 10 точек, что говорит о том, что отправка якобы прошла успешно. Но при этом на линиях CAN по прежнему тишина. У меня два адаптера CAN. На обоих одинаковая картина. Такая картина и при подключенном внешнем прибора, и без него.
Дополнительный вопрос: как настраивается скорость передачи на шине CAN?
-
Изменение режима и скорости возможно только при выключенном CAN-интерфейсе.
Включение режима передачи:
echo 0 > /sys/class/can0/listen_only
Выключение режима передачи (выключен по умолчанию):
echo 1 > /sys/class/can0/listen_only
Задание скорости (по умолчанию 500 кбит/с):
echo 250000 > /sys/class/can0/bit_rate
Чтение скорости
cat /sys/class/can0/bit_rate
Включение CAN-интерфейса:
ifconfig can0 up
Выключение CAN-интерфейса:
ifconfig can0 down
-
А режим передачи надо постоянно выставлять? Каков вообще алгоритм работы? Я хочу отправить на удаленное устройство пакет и получить ответ. Какие мои действия?
Я понимаю так:
1. Выключить CAN интерфейс (ifconfig can0 down)
2. включить режим передачи (echo 0 > /sys/class/can0/listen_only)
3. Включить CAN интерфейс (ifconfig can0 up)
4. Отправить пакет запроса
5. Выключить CAN интерфейс (ifconfig can0 down)
6. выключить режим передачи (echo 1 > /sys/class/can0/listen_only)
7. Включить CAN интерфейс (ifconfig can0 up)
8. начать слушать канал, чтобы получить ответ
Так что ли? Как то больно сложно получается. Наверно есть какой то другой алгоритм работы?
-
listen_only нужен чтобы аппаратно запретить адаптеру что-либо передавать на шину (для мониторинга), даже не отмечать подтвержение приёма пакета.
Т.е. достаточно переключить режим из listen_only, задать скорость и ifconfig can0 up.
После этого можете передавать и принимать.
-
после включения режима передачи
echo 0 > /sys/class/can0/listen_only
я увидел активность на линии. Спасибо!
Продолжаю разбираться с CAN.
-
Ещё пара вопросов по работе с CAN адаптером
1. Если отправляется сообщение на шину, но на шине нет приемника, при этом через несколько секунд после отправки в консоль выводится сообщение о таймауте отправки. Но осциллографом я вижу, что это сообщение бесконечно отправляется на шину. Это нормально? Можно ли его прервать? Помогает только перезагрузка тиона. ifconfig can0 down ifconfig can0 up не помогает
2. Как программно определить, что приемник не получил сообщения? После send ошибок не происходит. То есть видимо send говорит, что данные успешно отправлены "на отправку", но как определить, доставлены ли они физически или нет?
-
> Если отправляется сообщение на шину, но на шине нет приемника,
> при этом через несколько секунд после отправки в консоль выводится
> сообщение о таймауте отправки. Но осциллографом я вижу, что это
> сообщение бесконечно отправляется на шину
Оно не должно отравляться бесконечно, сообщения (с ошибками) отправляются
пока счётчик ошибок при передаче (TEC в документации на MCP2515) не достигнет
определённого значения. После чего они перестают передаваться, а устройство входит
в одно из состояний ошибок (active, passive, bus-off).
> ifconfig can0 down ifconfig can0 up не помогает
Выходить из этого состояния устройство должно автоматически: при определённых условиях.
> Как программно определить, что приемник не получил сообщения
Вероятно определить какая ошибка в каком конкретно сообщении не получится, так как инф.
об ошибках получается в прерывании. Общее состояние должно быть в статистике интерфейса.
> доставлены ли они физически или нет
Может быть вам нужен какой-то более высокоуровневый протокол поверх CAN?
-
> Оно не должно отравляться бесконечно, сообщения (с ошибками) отправляются
> пока счётчик ошибок при передаче (TEC в документации на MCP2515) не достигнет
Судя по осциллографу передатчик вещает что-то на линию даже после того, как в консоли появилось сообщение о таймауте. по крайней мере минут 10 точно идет. Дольше я не смотрел. может надо как то сбрасывать состояние буферов?
>>> доставлены ли они физически или нет
>Может быть вам нужен какой-то более высокоуровневый протокол поверх CAN?
Протокол CAN имеет возможность определять, доставлено ли сообщение (сигнал ACK ведь присутствует). Определить, был ли ACK мне было бы достаточно. Поиграюсь ещё с типами ошибок, но по-моему их (ошибок) не возникает.
-
> Определить, был ли ACK мне было бы достаточно.
Можете определить что ACK был, если статистика ошибок не изменилась.
Но так как сообщения буферизируются и ошибка сообщается по прерыванию, как определить для какого
сообщения была ошибка? Кроме того, оно автоматически будет отправлено ещё (и ещё...).
> Поиграюсь ещё с типами ошибок, но по-моему их (ошибок) не возникает.
В статистике интерфейса нет ошибок?
-
статистика интерфейса действительно дает информацию об успешно отправленных пакетах
В примере ниже сначала я отправил несолько (26) пакетов устройству и получил на них ответы. TX packets:26 - успешно отправили пакеты. Затем я отключил устройство и отправил на него 1 пакет. Через несколько секунд получил в консоль
# NETDEV WATCHDOG: can0: transmit timed out
И осциллографом вижу, что передача на линии не прекращается. Статистика показывает следующее:
# ifconfig can0
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MULTICAST MTU:16 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:1 dropped:0 overruns:0 carrier:3
collisions:59474 txqueuelen:10
RX bytes:208 (208.0 B) TX bytes:0 (0.0 B)
collisions постоянно растет с неимоверной скоростью. За несколько секунд оно выросло с 0 до 59474. Как это остановить? Может надо установить какой то лимит попыток отправки пакетов?
Оно не должно отравляться бесконечно, сообщения (с ошибками) отправляются
пока счётчик ошибок при передаче (TEC в документации на MCP2515) не достигнет
определённого значения. После чего они перестают передаваться, а устройство входит
в одно из состояний ошибок (active, passive, bus-off).
Видимо этого не происходит. Как узнать состояние ошибки?
Но так как сообщения буферизируются и ошибка сообщается по прерыванию, как определить для какого
сообщения была ошибка? Кроме того, оно автоматически будет отправлено ещё (и ещё...).
Что значит "Кроме того, оно автоматически будет отправлено ещё (и ещё...)." Значит ли это, что сообщение, которое не отправлено, будет отправляться бесконечно?