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

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

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

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

Я лет эдак 10 назад делал расширитель - с 1 RS232 или RS485 на 8 портов RS485. На 115200 работало
Непонятна необходимость в 3х интерфейсах 485, ведь это моноканал фактически, или таковы тех условия? Сами устройства могут жить на виртуально одной паре? если да, то этот хаб - самое оно
вот что-то типа такого
http://www.rs485.com/pdffiles/multiplerepe.../MHUBX8RevE.pdf
http://www.rs485.com/pmhubx8.html

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



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



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



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

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

LPC не везде мастер, в том то и дело. По одному из типов датчиков он должен только "прослушивать" обмен фирменной панели индикации с датчиками, и подхватывать данные, которые идут по запросу панели. И на запросы по некоторым адресам "подсовывать" данные с датчиков другого типа, имитируя совместимые с панелью.

Выкинуть панель и опрашивать самостоятельно нельзя.

Так что вариантов не морочиться с разработкой и использовать коммерчески доступное оборудование похоже нет. А хотелось... Изделие по сути даже не мелкосерийное а "несколькоштучное".

не увидел препятствий
ну так сделайте ту линию "мастером"

А может взять преобразователи RS485 в RS232, а то и UART сразу, те что сами умеют переключать прием - передачу автоматом. С вашей стороны они все будут нормальными 2 направленными интерфейсами, а вопрос направления решат буферы внутри устройств. Вам же на некоторые задержки в передаче - пофиг, как я понимаю...

хотя я думаю легче отключить FIFO на приемнике - передатчике и пусть АРМ все он-лайн разрулит, или он еще что-то делать будет?

там с передачей все нормально емкость разруливает в этом хабе, от контроллера - только RX/TX

Hm... Мастером чего?

Три шины, с разными протоколами...

На одной устройство должно быть слейвом и подслушивать обмен плюс подсовывать переформатированные данные с датчиков на второй шине (где оно мастер и должно само опрашивать слейвов). Датчики на второй шине не совместимы по протоколу с оригинальными, которым не удалось найти полноценную замену, и пришлось ставить то что функционально и по габаритам подходит. Производителя оригинальных датчиков в природе уже нет. На eBay за 2 года не пробегали ни разу, мониторится постоянно.

Плюс третья шина на которой еще один зоопарк в MODBUS RTU.

И все это должно окучиваться и передаваться оператору на комп по Ethernet (дальше не моя епархия).

Причём тут FIFO? Чем FIFO мешает? К тому же автор написал, что есть интервалы с высокой загрузкой прикладной задачей, в которые нежелательно много дрыгаться (к тому же под ОС).
Проблема у автора не в FIFO, а в том, что в LPC нет прерывания по установке бита 6 LSR (завершении передачи последнего бита). Это существенный недостаток UART-ов 16550.
Сам постоянно плююсь от этого.


Вижу 2 варианта:
1. Классически: по получению прерывания опустошения буфера (одного из UART), разрешаем прерывания таймера и в нём мониторим биты TEMT LSR. Если вы не уверены в корректности ПО на той стороне и в необходимых задержках
RX->TX на той стороне, придётся конечно увеличить частоту этого прерывания до максимума (хоть до максимальной бодовой скорости) и оптимально писать ISR (может на асме). Сильно это не загрузит процессор, так как разрешаться
это прерывание будет по THRE одного из UART, а запрещаться - при TEMT==1 для всех разрешённых UART. А это всего лишь длительность одного байта на текущей скорости (ну конечно могут быть наложения по времени от неск. UART).
Так как характер времён высокой загрузки у вас порядка десятков мсек, то такой ISR никак не помешает.
2. Завести линию TX каждого UART на отдельное прерывание GPIO, разрешать его по THRE, запрещать по TEMT своего UART. В остальном - подобно п.1.

Предлагаю следующий проверенный вариант:
1. Шина приводится в активное предопределенное состояние на одном из концов резисторами путем "раскорячки": между A и + питания - 330 Ом, между B и землей - 330 ом, между A и B - тоже 330 ом.
2. Вход DI полудуплексного RS-485 чипа садится на землю.
3. Вход DE через инвертор подключается к TX микроконтроллера.
4. Вход RE тоже на землю; во время собственной передачи с шины будет приходить эхо, которое можно обрабатывать программно на предмет совпадения того, что послали и приняли - возможность оценить ошибки на шине - или просто игнорировать.

У меня возникло большое желание отрать один таймер на это дело и использовать все 4 compare регистра для генерации прерываний примерно через половинку битового интервала после расчетного времени окончания передачи очередного символа. После загрузки байта на передачу обработчик прерываний UART вызывает функцию, которая пихает переданное время (плюс текущее значение счетчика) в соответствующий compare канал. При достижении счетчиком заданного значения генерится прерывание, в котором уже разберемся, не пора ли "погасить" передачу. Если канал уже "ждет" предыдущий символ. то значение в compare регистре увеличивается ровно на длину символа со стартом и стопом.