Три RS-485 на LPC-1768, Может есть примеры? Опции

[Velund]

Встала задача - реализовать три интерфейса RS-485 на плате расширения к изделию сделанному на LPC1768. Пины всех трех UART (кроме того самого единственного UART1 который аппаратно держит RS-485) и несколько свободных GPIO выведены на разъем расширения. Скорости - скорее всего выше 19200 не будет но хотелось бы потенциально держать до 115200.

Встает целый ряд вопросов с тем, какие "пируэты" придется делать вокруг FIFO этих портов чтобы корректно переключать прием/передачу.
Первая идея была оставить loopback и обрабатывая прерывания приемника от эха определять завершение передачи. Но в чистом виде это не годится - один сбой из за помехи на шине и все "завязывается в узел". Так что видимо придется еще и периодическим таймером поллить состояние передатчиков и "помогать" обработчику прерываний.

Наверняка кто то подобным уже занимался и есть какие то минимально проверенные решения в инете. Может кто нибудь подсказать на что стоит обратить внимание?

[jcxz]

По-моему вы выдумываете проблемы на ровном месте...
Никаких проблем для RS-485 со всеми UART-и в LPC нет. Единственное неудобство, как вы уже заметили - это необходимость обнаруживать появление бита 6 в LSR после опустошения FIFO.
Кроме как поллингом я думаю это вряд-ли как-то удобно сделать. Ну и что? Ну будет маленькая задержка на переключение, но на той стороне корректно написанное ПО для работы с RS-485
всегда должно вставлять задержку при переключении RX->TX.
У меня в проектах RS-485 работают до 230400 (выше - преобразователь RS-485-RS232 не держит) и никогда не использую функции RS485 UART1.
Какая у вас тактовая частота и загрузка CPU?

[Velund]

По-моему вы выдумываете проблемы на ровном месте...
Никаких проблем для RS-485 со всеми UART-и в LPC нет. Единственное неудобство, как вы уже заметили - это необходимость обнаруживать появление бита 6 в LSR после опустошения FIFO.

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

Кроме как поллингом я думаю это вряд-ли как-то удобно сделать. Ну и что? Ну будет маленькая задержка на переключение, но на той стороне корректно написанное ПО для работы с RS-485 всегда должно вставлять задержку при переключении RX->TX.

Есть сомнения в "корректности" ПО на другой стороне. По части устройств (датчиков) с которыми придется работать уже и производителя нет физически, даже жаловаться некому, если что.

Какая у вас тактовая частота и загрузка CPU?

80 MHz, загрузка невысокая в среднем, но периодически более приоритетная задача в RTOS блокирует процессор на 20-50 мсек полностью (прерывания при этом большую часть времени разрешены, но ими нельзя злоупотреблять особо).

Непонятна необходимость в 3х интерфейсах 485, ведь это моноканал фактически, или таковы тех условия? Сами устройства могут жить на виртуально одной паре?

Нет, не могут. Адская смесь старья с несовместимыми протоколами и с несовпадающими скоростями, которые не получится поменять.

[toweroff]

Нет, не могут. Адская смесь старья с несовместимыми протоколами и с несовпадающими скоростями, которые не получится поменять.

посмотрите схемотехнику этого хаба
спокойно до 230кбод можно сделать для простого UART без всяких пинодрыгов (ну, если LPC мастер, конечно)