[maxim_P 0]

Добрый день. Стоит задача обмена данными между двумя процессорами msp430f5419 и msp430f1611 через полудплекс. msp430f1611 (далее 1611) посылает команду, а msp430f5419 (далее 5419) должен ответить. 5419 команду принимает корректно, формирует ответ, а вот уже ответа на 1611 нет. Смотрел осциллографом, импульсы ответа очень низкие по амплитуде. Не могу понять что не так.

 

настройки UART Для 5419:

 

P3DIR |= BIT4;

P3SEL = BIT4 + BIT5; // разрешаем работу USART0

UCA0CTL1 |= UCSWRST; // **Put state machine in reset**

UCA0CTL1 |= UCSSEL_1; // ACLK

UCA0BR0 = 0x03; // 9600

UCA0BR1 = 0; // 9600

UCA0MCTL = 0x06; // Modulation

UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**

UCA0IE |= UCRXIE; // Enable USCI_A0 RX interrupt

 

прием по прерыванию.

как только был принят последний байт

начинаю передавать данные:

for (n2 = 0; n2 < transmit_buf[1] + 1; n2 ++)

{

while (!(UCA0IFG&UCTXIFG)); // USCI_A0 TX buffer ready?

UCA0TXBUF = transmit_buf[write_rec_ptr]; // TX -> RXed character

}

данные передаю в прерывании по приему.

 

настройки UART Для 1611:

 

P3SEL |= (BIT4 + BIT5); // P3.4,5 = USART0 TXD/RXD

P3DIR |= BIT4;

U0CTL |= SWRST ; // RST

U0CTL &= ~SYNC ; // UART MODE

U0CTL |= CHAR; // 8-bit char, SWRST=1 1 Stop Bit

UTCTL0 |= SSEL0; // UCLK = ACLK

U0BR0 = 0x03; // 9600 from 8,0Mz

U0BR1 = 0x00;

U0MCTL = 0x06; // Modulation

UCTL0 &= ~SWRST; // Enable USART

ME1 |= UTXE0; // Enabled UART0 TXD

 

как только был передан последний байт

переключаемся на прием:

ME1 = URXE0; // Enabled UART0 RXD

IE1 = URXIE0;

 

[rezident 0]

1. Если вы пользуетесь прерываниями, то не нужно опрашивать флаги готовности. Если опрашиваете флаг UCTXIFGx или UTXIFGx, то запретите прерывания от передатчика.

2. Маски при инициализации регистров следует накладывать только после того, как вы записали туда вместо дефолтного значения (после POR) явное значение.

3. При переключении с приема на передачу не следует отключать сам модуль USART, достаточно только запретить/разрешить прерывание. Команда

ME1 |= UTXE0; // Enabled UART0 TXD

разрешает функцию пина P3.4 как TXD, но не разрешает функцию P3.5 как RXD. Возможно поэтому возникает конфликт на линии и сигнал "просаживается". Ведь значение P3DIR.bit5 вы явно нигде не задали. И P3OUT.bit5 по-умолчанию в нуле.

[maxim_P 0]

1. Если вы пользуетесь прерываниями, то не нужно опрашивать флаги готовности. Если опрашиваете флаг UCTXIFGx или UTXIFGx, то запретите прерывания от передатчика.

2. Маски при инициализации регистров следует накладывать только после того, как вы записали туда вместо дефолтного значения (после POR) явное значение.

3. При переключении с приема на передачу не следует отключать сам модуль USART, достаточно только запретить/разрешить прерывание. Команда

ME1 |= UTXE0; // Enabled UART0 TXD

разрешает функцию пина P3.4 как TXD, но не разрешает функцию P3.5 как RXD. Возможно поэтому возникает конфликт на линии и сигнал "просаживается". Ведь значение P3DIR.bit5 вы явно нигде не задали. И P3OUT.bit5 по-умолчанию в нуле.

 

1. Прерывания от передатчика запрещены в обоих процессорах, прерывания только по приему.

2. Не совсем понял.

3. P3.5 выбран как RXD (P3SEL |= BIT4 + BIT5) или ему еще нужно направление задать? Модули все включил, все вавно та же ситуация.

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

Изменено 1 апреля, 2011 пользователем maxim_P

[rezident 0]

2. Не совсем понял.

После подачи питания или сброса регистры периферии (не все!) принимают какое-то дефотное состояние. Я вам рекомендую не надеятся на это и прописывать все регистры используемой периферии явными значениями и только потом уже в коде программы накладывать маски, модифицируя отдельные биты.

3. P3.5 выбран как RXD (P3SEL |= BIT4 + BIT5) или ему еще нужно направление задать?

Конечно нужно. Посмотрите внимательно схемотехнику (блок-схему) пинов в конце даташита.

в моей ситуации уровень не доходит до нуля, он только немного опускается

А не может так случиться, что пин уже "битый"? Осциллографом, например, неудачно ткнулись. Кстати, осциллограф у вас заземлен? Проверьте это предположение (неисправности пина), запрограммировав его как входной пин GPIO. Также проверьте соответствующий подключению пин на другом кристалле, запрограммировав его как выходной пин GPIO, при этом сформируйте программно его переключение. Эти простые тесты помогут определиться с тем, где именно проблема - в аппаратуре или в программе?

[maxim_P 0]

После подачи питания или сброса регистры периферии (не все!) принимают какое-то дефотное состояние. Я вам рекомендую не надеятся на это и прописывать все регистры используемой периферии явными значениями и только потом уже в коде программы накладывать маски, модифицируя отдельные биты.

Конечно нужно. Посмотрите внимательно схемотехнику (блок-схему) пинов в конце даташита.

А не может так случиться, что пин уже "битый"? Осциллографом, например, неудачно ткнулись. Кстати, осциллограф у вас заземлен? Проверьте это предположение (неисправности пина), запрограммировав его как входной пин GPIO. Также проверьте соответствующий подключению пин на другом кристалле, запрограммировав его как выходной пин GPIO, при этом сформируйте программно его переключение. Эти простые тесты помогут определиться с тем, где именно проблема - в аппаратуре или в программе?

Все порты РхDIR и РхOUT в начале программы обнуляются. А какое направление RXD еще нужно задать? Пины не битые. При разрыве линии между процессорами сигналы четкие с обоих сторон. А когда линию соединяю, послылаю команду, то сигнал тоже не опускается полностью до нуля, но по амплитуде он достаточно высокий, чтобы прочитать данные. Питание 3,3 вольта. Амплитуда команды примерно 2,7В, амплитуда ответа примерно 0,6В. В сумме они дают 3,3В. Осциллограф заземлен. Прикладываю осциллограмму.

Изменено 1 апреля, 2011 пользователем maxim_P

[rezident 0]

Все порты РхDIR и РхOUT в начале программы обнуляются.

Ну я же не профессиональный телепат, чтобы угадывать неопубликованные исходные тексты. :rolleyes:

А какое направление RXD еще нужно задать?

Для RXD вход, для TXD - выход. Пин RXD одного контроллера должен соединяться с TXD второго. Соответственно TXD первого с RXD второго.

Питание 3,3 вольта. Амплитуда команды примерно 2,7В, амплитуда ответа примерно 0,6В. В сумме они дают 3,3В.

А выводы DVSS обоих контроллеров соединить не забыли случайно?

Осциллограф заземлен.

Именно заземлен или подключен к трехпроводной сети? Рекомендую убрать заземляющий контакт у осциллографа. Особенно, когда к плате подключен эмулятор, подключенный в свою очередь к PC.

 

 

[maxim_P 0]

Для RXD вход, для TXD - выход. Пин RXD одного контроллера должен соединяться с TXD второго. Соответственно TXD первого с RXD второго.

Я же настраиваю P3.4, P3.5 на UART, как настроены POUT, PDIR не имеет значения, так по крайней мере написано в конце даташита. Используется полудуплекс - RXD и TXD закорочены на обоих контроллерах.

А выводы DVSS обоих контроллеров соединить не забыли случайно?

Именно заземлен или подключен к трехпроводной сети? Рекомендую убрать заземляющий контакт у осциллографа. Особенно, когда к плате подключен эмулятор, подключенный в свою очередь к PC.

Земля между контроллерами есть. По поводу заземления точно сказать не могу. Как я уже выше писал, если линию разорвать, то импульсы имеют амплитуду

3,3В (что и требуется) на обоих контроллерах (измерял осциллографом в тех же условиях), то есть проблема не с осциллографом, а скорее с настройками обмена данных.

Изменено 1 апреля, 2011 пользователем maxim_P

[rezident 0]

Используется полудуплекс - RXD и TXD закорочены на обоих контроллерах.

Поясните эту фразу. Что значит "закорочены"? Соединены между собой? У вас обмен между МК всего по одному проводу идет что ли? :cranky:

[maxim_P 0]

Поясните эту фразу. Что значит "закорочены"? Соединены между собой? У вас обмен между МК всего по одному проводу идет что ли? :cranky:

ага

[rezident 0]

Вот же блин! :twak: В таком случае вам нужно после передачи обязательно выключать функцию пина TXD, сбрасывая соответствующие биты в регистрах P3SEL и P3DIR. А устанавливать бит 4 в P3SEL можно только на время передачи. Иначе у вас получается конфликт, когда два выхода TXD одновременно пытаются управлять общей линией передачи.

И нафига такие заморочки? Не проще ли было обычный дуплекс реализовать? Вам еще одну "лишнюю" дорожку на плате нарисовать было влом?

[maxim_P 0]

Вот же блин! :twak: В таком случае вам нужно после передачи обязательно выключать функцию пина TXD, сбрасывая соответствующие биты в регистрах P3SEL и P3DIR. А устанавливать бит 4 в P3SEL можно только на время передачи. Иначе у вас получается конфликт, когда два выхода TXD одновременно пытаются управлять общей линией передачи.

И нафига такие заморочки? Не проще ли было обычный дуплекс реализовать? Вам еще одну "лишнюю" дорожку на плате нарисовать было влом?

Мне было бы не влом, а только в радость. Возникла необходимость замены устройства, на аналог, и это устройство "общается" с базовой платой через полудуплекс. Чтобы не менять базовую плату и программное обеспечение придется делать так.

Вообще я пробовал такой вариант чуть раньше, как только 1611 передал команду, я переключаю его на прием с помощью P3SEL, 5419 после того как принял последний байт переключается на передачу. Картина та же. Я, конечно, еще раз попробую. Получится только в понедельник. RXD можно не трогать? Кстати, в 5419 есть такой бит USLISTEN, который закорачивает RXD и TXD внутри процессора, его случайно не нужно использовать?

[rezident 0]

Вообще я пробовал такой вариант чуть раньше, как только 1611 передал команду, я переключаю его на прием с помощью P3SEL, 5419 после того как принял последний байт переключается на передачу. Картина та же.

У вас классическая картина конфликта двух логических выходов. Правда это выяснилось только после "допроса" :) Вы надеюсь какие-то паузы ввели в протокол для исключения этого конфликта? Т.е. один передатчик должен выключать свой выход (сбрасывать бит в P3SEL) сразу после окончания передачи, а второй подключать выход к линии (устанавливать бит в P3SEL) только после некоторой паузы. Причем начало этой паузы должно определяться либо протоколом (символом окончания пакета), либо паузой в приеме пакета данных. Хоть это и тавтология, но смысл в том, что нужна пауза после паузы приема.

RXD можно не трогать?

Нет RXD не мешает обмену. Но желательно на линии иметь pull-up резистор, чтобы исключить ложный старт-импульс и начало приема в момент паузы, когда оба передатчика будут отключены от линии.

Кстати, в 5419 есть такой бит USLISTEN, который закорачивает RXD и TXD внутри процессора, его случайно не нужно использовать?

Нет. Этим битом можно только организовать "эхо". Зачем вам "эхо"?

[maxim_P 0]

У вас классическая картина конфликта двух логических выходов. Правда это выяснилось только после "допроса" :) Вы надеюсь какие-то паузы ввели в протокол для исключения этого конфликта? Т.е. один передатчик должен выключать свой выход (сбрасывать бит в P3SEL) сразу после окончания передачи, а второй подключать выход к линии (устанавливать бит в P3SEL) только после некоторой паузы. Причем начало этой паузы должно определяться либо протоколом (символом окончания пакета), либо паузой в приеме пакета данных. Хоть это и тавтология, но смысл в том, что нужна пауза после паузы приема.

Нет RXD не мешает обмену. Но желательно на линии иметь pull-up резистор, чтобы исключить ложный старт-импульс и начало приема в момент паузы, когда оба передатчика будут отключены от линии.

Нет. Этим битом можно только организовать "эхо". Зачем вам "эхо"?

Основной режим 1611 - передача, то есть при инициализации контроллер настраиваю на передачу, как только был отправлен последний байт, сразу же переключаю на прием (Сбрасываю флаг RXIFG, разрешаю прерывания по приему), затем делал паузу, но я ее почему-то закомментировал, восстановлю. Основной режим 5419 - прием, при инициализации настроен на прием. Как только был принят последний байт, далее переключение на передачу, затем формирование ответа, вычисление CRC ответа, передача ответа.

Как я понял, необходимо делать задержки после каждого переключения на прием/передачу?

[rezident 0]

Как я понял, необходимо делать задержки после каждого переключения на прием/передачу?

Да, тут такая же ситуация как при использовании трансиверов RS-485 и полудуплексной линии связи чеоез RS-485. После окончания передачи пакета запроса трансивер ведущего переходит в режим приема. Но ведомый не начинает передачу сразу же после приема даже, если он готов ответить через 1мкс. Выдерживается оговоренная протоколом пауза (обычно порядка 1-1,5 длительностей одного символа на используемой скорости обмена, например, для 115200, 8, n, 1 пауза должна быть порядка 1,5*(1+8+1)/115200=130мкс или больше) и только затем ведомый переключает трансивер RS485 на передачу, но пока еще не передает. Еще одна пауза, когда трансивер ведомого удерживает линию в состоянии передачи, нужная для того, чтобы линия зарядилась и закончились все переходные процессы в ней. И если переходный процесс вызвал ложный старт-бит, то приемник ведущего успел отработать ошибочно принятый байт, отсеяв его. И только по истечении второго 1,5-го интервала длительности символа ведомый начинает передачу пакета с ответом на запрос.

Вам вторая пауза в принципе и не нужна, т.к. у вас нет трансивера RS485 и длинной линии связи. Но пауза перед включением выхода UART на передачу весьма желательна. Также как и pull-up резистор на линии.

[maxim_P 0]

Спасибо за информацию, на следующей неделе попробую.