Печать

Пожалуйста, войдите или зарегистрируйтесь.
1 час 1 день 1 неделя 1 месяц Навсегда

[Ivan]

Добрый день.

Есть тион-про270. Загрузил туда образ, в котором значится поддержка RS 485, но у меня получилось заставить его работать только на прием (то-есть сообщения от компьютера принимаются, а в обратную сторону - никак).
По данной ссылке http://zao-zeo.ru/dokuwiki/doku.php/tion-pro270 нашел следующее:
"Для работы интерфейса RS-485 требуется программное управление сигналом BT_RTS для разрешения передачи."

Собственно не могу разобраться, что под этим подразумевается и как с этим бороться. Был бы признателен за какую-нибудь простенькую программу-пример, или любые другие подсказки.

P.S.: Операционная система WinCE 6.0

[Ivan]

Расскажите хотя бы, какую ножку процессора дергать для управления этим сигналом, а то из документации я чет понять не могу...

[Danila]

Добрый день.
Для того, чтобы передать сообщение по RS485 необходимо в своей программе управлять сигналом DE микросхемы ADM485, т.е. разрешить передачу.
Этот сигнал выведен на GPIO45, через инвертор.
Перед началом передачи  GPIO45 нужно установить в "0", по окончании передачи опять установить в "1".
Пример работы с GPIO  можно посмотреть здесь: http://www.zao-zeo.ru/dokuwiki/doku.php/wince-dev

[Ivan]

Благодарю за помощь! Сейчас буду пробовать.

[Ivan]

Еще раз благодарю, с вашим драйвером и вашей тестовой программой все работает. Остается только добавить в свою программу недостающие куски.

[Ivan]

Еще раз добрый день.
Необходимо подключить плату к устройству, которое считывает команды и отвечает на них (подключаем как-раз через 485 интерфейс). В ходе экспериментов выяснилось, что быстродействия драйвера не хватает, для того чтобы успевать переключать направление приема/передачи (Использую DeviceIoControl с соответствующими параметрами, как в GPIO_Test). В связи с этим, очень хотелось бы иметь доступ к исходному коду драйвера, который доступен для скачивания только в виде dll. Это возможно?

[Danila]

Собрать драйвер отдельно не получится, только вместе с BSP. Можем передать BSP.
Однако я не думаю, что драйвер вносит сильные задержки, т.к. там минимальное количество команд.
Задержка, вероятно, возникает при вызове DeviceIoControl из прикладной программы, т.к. при этом происходит смена процессов. Как с этим бороться не знаю, не исследовал эту ситуацию...видимо нужно как-то менять приоритеты процессов.
Либо изменять момент смены уровня сигнала.

Насколько сильная задержка? Как Вы ее определяете?

[Ivan]

BSP уже есть. Задержку мерили с помощью осциллографа. На самом деле, драйвер GPIO уже не актуален, так как удалось доработать обычный драйвер serail-интерфейса так, чтобы сигнал RTS автоматически выставлялся. Как оказалось, проблема не только в задержке. Насколько я понимаю, сейчас дело в том, что в момент передачи происходит также прерывание на запись (так как реализовано "зеркало"), и из-за обработки этого прерывания не видится ответ от устройства...
Так что буду копать дальше.
Спасибо за ответ.

[Ivan]

Еще раз добрый день.
Продолжаю копаться с 485 интерфейсом и все никак не могу решить эту проблему. Есть устройство, которое отвечает на запрос примерно через 2 мс. Ответ от него поймать не получается - принимаю только "зеркало". Если эмулировать работу устройства на компьютере (то есть, написать простенькую программу, которая вычитывает порт до тех пор, пока не прочитает пакет, а потом немедленно на него отвечает), то удается получить на тионе ответ в виде то, что посылали + ответ от компьютера.
Включив некоторые отладочные сообщения увидел, что при работе с компьютером в момент его ответа происходит прерывание на прием, а при работе с устройством этих прерываний нет. Ради интереса, попробовал вставить прерывания вручную и естественно прочитал 0 байт. Более подробные логи привожу во вложении.

Не подскажите, в какую сторону копать?

[asv]

> устройство, которое отвечает на запрос примерно через 2 мс

Данные от этого устройства проходят за ADM485, т.е. их можно видеть на выводе 1 ИМС U12?
Или данные не проходят, так как ADM485 ещё включён на передачу, так как сигнал DE (вывод 3) ещё не убран?

[Ivan]

Ну оно в теории отвечает через 2 мс, даже быстрее. Реально данные не проходят, скорее всего потому, что я не успеваю переключить направление передачи. Собственно, с этим и борюсь.

[Danila]

За 2 мс действительно можно не успеть переключить сигнал...
Кстати, отладочные сообщения тормозят систему.

[Ivan]

Забил на wince...
Теперь собрал linux для этой машины. Делал, как описано здесь: http://www.emb-linux.narod.ru/tion-pro-270/index.html
(для удобства, качал все те же самые версии ядра/патчей/кфс, что и в статье, только патч для u-boot'а пришлось взять другой). Все вроде работает, но с 485 естественно та же проблема.
Пытаюсь теперь разобраться в коде драйвера под linux - нашел в <папка с исходниками ядра>/drivers/serial файл pxa.c, но насколько я понимаю, это не единственный файл, который там используется. Не подскажите, какие еще файлы используются для сборки этого драйвера?

[asv]

В Linux будет та же самая проблема: управлять передачей GPIO и её так же не получиться по нормальному решить. Два варианта:
1. Отключать передачу по истечению расчётного таймаута (зависит от текущей скорости передачи) для буфера сдвига, так как нет прерывания, что он очистился
2. В цикле проверять принятые данные и сравнивать с переданными, понятно, что это не "самый" быстрый способ

Для сравнительно быстро отвечающих устройств на RS485 Тион-Про270 не годиться, так как нужно аппаратное управление передачей (как на EP93xx: Тион-Про2).

[Ivan]

Я, почему-то, так и подумал...
Но все-же, хотелось бы знать, в каких файлах копаться...
А то я честно написал программу, взяв за основу вот это http://www.zao-zeo.ru/dokuwiki/doku.php/linux#последовательный_порт,
но она не реагирует ни на write, ни на read. Хочу проследить цепочку вызовов, чтоб знать, куда лучше воткнуть управление сигналом