Посоветуйте как мне обмениваться данными через 485 интерфейс. По привычке разрешение приема в драйвере посадил на землю - соответсвенно прием всегда идет. В 8-ми битниках при передаче всегда отключал приемник и проблем не было. В LPC такое не прокатило - отключаешь фифо соответственно передача прекращается. Как народ поступает в данном случае? Передача и прием ведутся через кольцевые буферы с которыми и сонованя прога работает. Может как-то извернуться не на уровне железа?

1. Абсолютно бесполезное действие, ибо никаких аппаратных завязок на RTS-CTS-DTR-DSR-CD
в 550 совметимых девайсах не предусмотрено.

2.Не забирать, а по окончании сбросить Tx FIFO.

Вариантов много, например:
1. Запретить прерывания приема, перед разрешением выгрести фифо.
2. Иметь в обработчике прерывания флаг разрешения/запрещения приема. В зависимости от - обрабатывать/не обрабатыать принятые байты.
3.Отрезать нафиг землю от RE' и посадить туда пин контроллера (или объединиить с DE). Все равно плату переразводить, поскольку в ней куча других ошибок

Ну и как вариант - принимать всё, с контролем того что отправляете, ошибок, коллизий и т.д.
Особо полезно мастер-девайсу.
Кстати приём/передача где/как переключается?

2 Andy Mozzhevilov А какие ошибки кроме памяти - будьте так любезны? К сожалению опытная партия уже производится. В плате в принципе можно порезать дороги/проводками соединить. Многие я видел приемник драйвера 485 интерфейса включают постоянно - то есть управляющую ногу садят на землю. Предполагаю, что это действительно делается, как сказал Alex03, для контроля передачи. В общем спасибо за советы - буду перед передачей отключать прерывание на прием, а перед разрешением читать U0LSR и сбрасывать буфер приема. Кстати, немаловажный момент, получается, что отключить передатчик драйвера 485 в обработчике прерывания уарта нельзя, так как он контролирует освобождение буфера, но не сдвигового регистра. То есть приведенный код постоянно должен крутиться в основном цикле. Правильно я понимаю?

void UART0_CheckBuferEmty(void)
{
if(uart0.flags.tx_in_progress == 0)
{
if(U0LSR & (1<<U0LSR_TEMT_BIT))
{
IO0CLR |= (1<<RS485_TX); //Отключим передатчик RS485
U0IER |= (1<<U0IER_RBR_Interrupt_Enable_BIT);
U0FCR |= (1<<U0FCR_Rx_FIFO_Reset_BIT);
}
}
}

По своему опыту скажу, что при первом проходе платы обычно вылавливается 3-5 ошибок и/или пожеланий. Для начала производства требуется 2-3 прохода. Так что не расстраивайтесь.




предостерегу вас сразу от ошибки, связанной с оперированием регистром FCR:
http://electronix.ru/forum/index.php?showtopic=8032&hl=FCR

А так, я сейчас на вскидку не вспомню, в какой момент устанавливается THRE.

Спасибо. Про особенности FCR я знал, но про тонкости работы с ним не догадывался. Получается надо тогда просто писать
U0FCR = (1<<U0FCR_FIFO_Enable_BIT) | (1<<U0FCR_Tx_FIFO_Reset_BIT) | (1<<U0FCR_Rx_FIFO_Reset_BIT);

чтобы не было неоднозначностей.

Еще - не могу понять. Уарт в LPC полудуплексный или дуплексный? Я к тому клоню, что головы фифо на прием и передачу расположены по одному адресу. Не получится ли, что при передаче данных они через драйвер 485 будут возвращаться и портить общий фифо или это я бред несу?

да, именно так, нельзя использовыать чтение-модификацию-запись для этого регистра


uart дуплексный, конечно.
вообще он прикидывается по регистрам пи-си-шным 16С550 (типа industry standart).
RBR и THR регистры ReadOnly и WriteOnly соотвесттвенно.

Я поступаю обычно так: пины разрешения not RD и WR корочу на трансивере rs485 и сажу на один управляющий пин с МК, т.о. естественным путем выполняется блок приема при передаче. Проблем с ошибками приема в такой реализации никогда не испытывал.

Только еще pull-up резистор на RX надо повесить.

в общем случае - да.

совершенно не обязательно, делайте правильные протоколы.

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