ЗАО «ЗЭО»
Техническая поддержка пользователей => Тион270, Тион-Про270, Сириус270 => Тема начата: Ivan от 22 Июля, 2010, 13:20:36
-
Добрый день.
Есть тион-про270. Загрузил туда образ, в котором значится поддержка RS 485, но у меня получилось заставить его работать только на прием (то-есть сообщения от компьютера принимаются, а в обратную сторону - никак).
По данной ссылке http://zao-zeo.ru/dokuwiki/doku.php/tion-pro270 нашел следующее:
"Для работы интерфейса RS-485 требуется программное управление сигналом BT_RTS для разрешения передачи."
Собственно не могу разобраться, что под этим подразумевается и как с этим бороться. Был бы признателен за какую-нибудь простенькую программу-пример, или любые другие подсказки.
P.S.: Операционная система WinCE 6.0
-
Расскажите хотя бы, какую ножку процессора дергать для управления этим сигналом, а то из документации я чет понять не могу...
-
Добрый день.
Для того, чтобы передать сообщение по RS485 необходимо в своей программе управлять сигналом DE микросхемы ADM485, т.е. разрешить передачу.
Этот сигнал выведен на GPIO45, через инвертор.
Перед началом передачи GPIO45 нужно установить в "0", по окончании передачи опять установить в "1".
Пример работы с GPIO можно посмотреть здесь: http://www.zao-zeo.ru/dokuwiki/doku.php/wince-dev
-
Благодарю за помощь! Сейчас буду пробовать.
-
Еще раз благодарю, с вашим драйвером и вашей тестовой программой все работает. Остается только добавить в свою программу недостающие куски.
-
Еще раз добрый день.
Необходимо подключить плату к устройству, которое считывает команды и отвечает на них (подключаем как-раз через 485 интерфейс). В ходе экспериментов выяснилось, что быстродействия драйвера не хватает, для того чтобы успевать переключать направление приема/передачи (Использую DeviceIoControl с соответствующими параметрами, как в GPIO_Test). В связи с этим, очень хотелось бы иметь доступ к исходному коду драйвера, который доступен для скачивания только в виде dll. Это возможно?
-
Собрать драйвер отдельно не получится, только вместе с BSP. Можем передать BSP.
Однако я не думаю, что драйвер вносит сильные задержки, т.к. там минимальное количество команд.
Задержка, вероятно, возникает при вызове DeviceIoControl из прикладной программы, т.к. при этом происходит смена процессов. Как с этим бороться не знаю, не исследовал эту ситуацию...видимо нужно как-то менять приоритеты процессов.
Либо изменять момент смены уровня сигнала.
Насколько сильная задержка? Как Вы ее определяете?
-
BSP уже есть. Задержку мерили с помощью осциллографа. На самом деле, драйвер GPIO уже не актуален, так как удалось доработать обычный драйвер serail-интерфейса так, чтобы сигнал RTS автоматически выставлялся. Как оказалось, проблема не только в задержке. Насколько я понимаю, сейчас дело в том, что в момент передачи происходит также прерывание на запись (так как реализовано "зеркало"), и из-за обработки этого прерывания не видится ответ от устройства...
Так что буду копать дальше.
Спасибо за ответ.
-
Еще раз добрый день.
Продолжаю копаться с 485 интерфейсом и все никак не могу решить эту проблему. Есть устройство, которое отвечает на запрос примерно через 2 мс. Ответ от него поймать не получается - принимаю только "зеркало". Если эмулировать работу устройства на компьютере (то есть, написать простенькую программу, которая вычитывает порт до тех пор, пока не прочитает пакет, а потом немедленно на него отвечает), то удается получить на тионе ответ в виде то, что посылали + ответ от компьютера.
Включив некоторые отладочные сообщения увидел, что при работе с компьютером в момент его ответа происходит прерывание на прием, а при работе с устройством этих прерываний нет. Ради интереса, попробовал вставить прерывания вручную и естественно прочитал 0 байт. Более подробные логи привожу во вложении.
Не подскажите, в какую сторону копать?
-
> устройство, которое отвечает на запрос примерно через 2 мс
Данные от этого устройства проходят за ADM485, т.е. их можно видеть на выводе 1 ИМС U12?
Или данные не проходят, так как ADM485 ещё включён на передачу, так как сигнал DE (вывод 3) ещё не убран?
-
Ну оно в теории отвечает через 2 мс, даже быстрее. Реально данные не проходят, скорее всего потому, что я не успеваю переключить направление передачи. Собственно, с этим и борюсь.
-
За 2 мс действительно можно не успеть переключить сигнал...
Кстати, отладочные сообщения тормозят систему.
-
Забил на wince...
Теперь собрал linux для этой машины. Делал, как описано здесь: http://www.emb-linux.narod.ru/tion-pro-270/index.html
(для удобства, качал все те же самые версии ядра/патчей/кфс, что и в статье, только патч для u-boot'а пришлось взять другой). Все вроде работает, но с 485 естественно та же проблема.
Пытаюсь теперь разобраться в коде драйвера под linux - нашел в <папка с исходниками ядра>/drivers/serial файл pxa.c, но насколько я понимаю, это не единственный файл, который там используется. Не подскажите, какие еще файлы используются для сборки этого драйвера?
-
В Linux будет та же самая проблема: управлять передачей GPIO и её так же не получиться по нормальному решить. Два варианта:
1. Отключать передачу по истечению расчётного таймаута (зависит от текущей скорости передачи) для буфера сдвига, так как нет прерывания, что он очистился
2. В цикле проверять принятые данные и сравнивать с переданными, понятно, что это не "самый" быстрый способ
Для сравнительно быстро отвечающих устройств на RS485 Тион-Про270 не годиться, так как нужно аппаратное управление передачей (как на EP93xx: Тион-Про2).
-
Я, почему-то, так и подумал...
Но все-же, хотелось бы знать, в каких файлах копаться...
А то я честно написал программу, взяв за основу вот это http://www.zao-zeo.ru/dokuwiki/doku.php/linux#последовательный_порт,
но она не реагирует ни на write, ни на read. Хочу проследить цепочку вызовов, чтоб знать, куда лучше воткнуть управление сигналом
-
> куда лучше воткнуть управление сигналом
drivers/serial/pxa.c достаточно
-
Наконец-то проследил цепочку вызовов - в результате вставил в transmitt_chars () установку и сброс сигнала RTS
mcr |= TIOCM_RTS;
serial_out (up, UART_MCR, mcr);
//передача данных
mcr &= ~TIOCM_RTS;
serial_out (up, UART_MCR, mcr);
В результате тестовые программы приема/передачи работают, но когда пытаюсь сделать так, что сначала программа что-то передает, а затем принимает, то передача идет успешно, а принять ничего не могу. С помощью добавления множества отладочных сообщений удалось выяснить, что в таком случае просто не происходит прерывания на прием. Такое впечатление, что после передачи данных сбрасывается/устанавливается какой-то бит, который не дает возникнуть этому прерыванию, но определить, что это за бит, мне пока не удается.
Возможно, вы сталкивались с подобной проблемой.
Буду признателен за любую помощь.
-
Разобрался сам.
Надо было делать так:
serial_pxa_set_mctrl (&up->port, TIOCM_OUT2 | TIOCM_DTR);
передача данных
serial_pxa_set_mctrl (&up->port, TIOCM_OUT2 | TIOCM_DTR | TIOCM_RTS);
Может кому-нибудь пригодится...
Правда, быстродействия для меня предсказуемо не хватает, хотя работает шустрее, чем в wince 6.
-
> Может кому-нибудь пригодится...
Если сделаете патч, тогда кому-то может и пригодиться.
-
Патч может сделаю, когда все окончательно отлажу.
Сейчас возникла вообще очень странная ситуация - убрал все отладочные сообщения и все перестало работать. Вернул какую-то часть - все опять заработало. При этом даже удается ловить несколько последних байтов ответа от моего устройства, то есть все работает достаточно быстро. Логично предположить, что если убрать отладочные сообщения, то заработает еще быстрее.
Но сейчас складывается впечатление, что если я, например, в функции uart_write (файла drivers/serial/serial_core.c) не поставлю что-нибудь типа
printk ("uart_write\n"),
то эта функция вообще не вызывается. Возможно, вы сталкивались с подобным на каком-либо этапе разработки.
Хотелось бы услышать какие-нибудь советы по этому поводу, потому что сам я пока вообще слабо понимаю, как такое возможно.
-
Сейчас возникла вообще очень странная ситуация - убрал все отладочные сообщения и все перестало работать. Вернул какую-то часть - все опять заработало.
Учитывайте, что после подачи сигнала DE микросхеме нужно какое-то время (макс. 25 нс по документации) для включения передатчика (при отключении ждать нет смысла, не успел, так не успел).
Но сейчас складывается впечатление, что если я, например, в функции uart_write (файла drivers/serial/serial_core.c) не поставлю что-нибудь типа
printk ("uart_write\n"),
Нет, такого не может быть. Вероятно дело в задержках, которые добавляют printk, уберите console с последовательного порта (задержки будут меньше) и посмотрите как будет при коде с printk.
-
Спасибо за оперативный ответ. Вероятнее всего, проблема возникала именно из-за того, что не учитывал необходимость задержки для переключения микросхемы. Сейчас попробую добавить задержку...
-
в конечном итоге, дело было даже не в этой задержке. Требовалось установить задержку для "действительной" передачи байтов (может коряво описываю, но других слов подобрать не могу). Опытным путем узнал, что на передачу одного байта уходит порядка 83 мкс (у меня получилось 83.(3), но это весьма приблизительная цифра). Таким образом, поставив после кода передачи байтов задержку в (83 * кол-во байт), и сразу после этого реализовав переключение RTS, удалось добиться того, что успешно считываю ответ от своего устройства.
Если кому-либо понадобится решать схожую проблему, выкладываю во вложении вывод diff для файла pxa.c. В других файлах я вроде ничего не трогал...
-
На какой скорости открыт порт?
-
115200
-
83 мкс -- это приблизительное время на передачу байта на скорости 115200.
При 8-ми битах данный, одном старт и одном стоп бите, без чётности:
115200 бит/с / (8 + 1 + 1) = 11520 байт/с
1/11520 = 86.8 мкс
-
Ну, в общем да....
Тогда по хорошему надо будет конечно при выставлении задержки учитывать параметры порта, но у нас все на 115200 8n1, поэтому пока будет работать так. Потом может перепишу по-нормальному.
-
В общем, я таки набросал патч... Желающие могут ознакомиться во вложении.