Встроенное устройство Linux, блокирующее шину RS485 при запуске
У меня проблемы с промышленным компьютером Linux, с которым я работаю, чтобы установить связь по шине RS485 с несколькими подключенными устройствами. Я столкнулся с тем, что выводы ввода-вывода, используемые драйвером RS485 USART, устанавливаются на разные уровни при запуске вместо перехода в режим ожидания / три состояния RS485. В результате другие устройства на шине блокируются более чем на 30 секунд, пока устройство загружается, вызывая всевозможные внешние проблемы. Ход событий можно посмотреть на прилагаемом изображении, где я измерил выходные напряжения с помощью осциллографа во время запуска.
Я предполагаю, что фактический драйвер не запускается, пока уровни напряжения не достигнут своих уровней в трех состояниях (например, ~2,2 В для этого устройства). После этого все работает как положено.
Я попытался найти любые файлы конфигурации, чтобы установить уровень IO по умолчанию для выводов при загрузке (думая, что это может быть установлено загрузчиком), но безрезультатно.
Кроме того, я попытался применить скрипт запуска для запуска "достаточно рано", чтобы установить DATA- high, но рассматриваемое устройство не предоставляет интерфейс для управления этими выводами как обычными GPIO, насколько я могу судить.
Любая помощь, советы или идеи будут высоко оценены!
РЕДАКТИРОВАТЬ: я не опытный разработчик Linux, поэтому, пожалуйста, выделите, если я пропустил какие-либо важные детали.
Некоторые характеристики:
- ARM920T rev 0 (v41) CPU
- Собственный дистрибутив Linux 2.6
- Использует Busybox
- Драйверы Atmel USART
Извлечь из журнала загрузки:
Версия Linux 2.6.28.10 (root@) (версия gcc 4.1.2) #94 ПРЕДИСЛОВИЕ Вторник, 29 октября 10:22:19 CET 2013
Процессор: ARM920T [41129200] ревизия 0 (ARMv4T), cr = c0003177
/...
... /
Режим RS485 для порта /dev/ttyS3 включен
/...
... (я предполагаю, что здесь проходит ~30 секунд)
... /
atmel_usart.3: ttyS3 в MMIO 0xfffcc000 (irq = 9) является ATMEL_SERIAL
atmel_serial.3: установка пин-кода RS485 RTS
/...
...
... /
Полный журнал загрузки: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Аналогичная проблема:
Возможно, аналогичная проблема обсуждается здесь: Инициализация UART: не допускайте, чтобы UART поднял RTS до максимума.
Но я не уверен, как поступить с предложенным решением.
3 ответа
Это немного больше, чем дикие предположения, но, возможно, стоит добавить сценарий запуска, который отображает на устройстве символ NULL (например, /dev/ttyS1 или любой другой), как можно раньше во время запуска. Этого может быть достаточно, чтобы заставить драйвер инициализировать оборудование.
Вы также можете попытаться найти драйвер в источнике Linux, чтобы посмотреть, как он запускается.
Вероятно, у вас есть доступ к исходному коду, поэтому вы можете выяснить, кто и когда связывался с этим GPIO. Просто найдите источник ядра для адресов портов контроллера Atmel gpio, чтобы выяснить, что происходит. Если вам повезет, возможно, найдется опция командной строки ядра, которую вы можете передать из загрузчика, чтобы заранее установить строку, необходимую вам.
этот ответ может сработать, если вы найдете нужные вещи, указанные ниже на вашей доске!
Когда-то у меня тоже была такая же проблема с ШИМ. Там я обнаружил, что мой загрузчик отвечает за то же самое, я изменил конфигурацию загрузчика, и он начал работать нормально.
Проверьте ваш BSP, предоставленный поставщиком платы или третьей стороной (если у вас есть источник), если ваш загрузчик U-boot, вы можете найти его внутри U-boot-(source)/include/configs/(your-board).h там вы можете найти конфигурацию для RS484. В соответствии с вашей таблицей данных для платы вы можете проверить другие вещи, которые мультиплексируются на одном и том же выводе, и отключить их, если они не требуются во время загрузки, и включить RS485.
enabling/disabling может быть сделано путем изменения значений 0, 1 or 2 согласно вашей конфигурации, а также вы можете просто отключить что-нибудь, просто комментируя // вне линии.