MSP430F149, прерывания USART., Странный порядок... Опции

[AHTOXA]

RS485. Хочу управлять направлением передачи без таймера.
План был такой: не отключать приёмник у драйвера 485, ловить эхо переданных символов, и по приёму последнего символа отключать передатчик.

Пишу:

Код

    // прерывание по приёму.
    void rx_interrupt(void)
    {
        if (is_tx_on())   // передатчик включен?
        {
            if (!tx_on_)   // передача окончена?
                tx_off();   // отключаем передатчик.
        }
        else // обычный приём.
        {
            RxBuf.put(RXBUF0);
        }
    }

    // прерывание по передаче
     void tx_interrupt(void)
    {
        if (TxBuf.is_empty())
        {
            tx_on_ = false;
        }
        else
            TXBUF0 = TxBuf.get();
    }
};

Вроде бы всё логично. Сначала опустошается TXBUF0, возникает прерывание tx_interrupt, я сбрасываю флажок tx_on_. Затем этот последний символ принимается, возникает прерывание по приёму, я отключаю передатчик.

Но. Почему-то сначала возникает прерывание по приёму, а лишь затем - по опустошению передатчика! Как такое может быть?

[MrYuran]

Ещё один эксперимент.

Код

void test_UART()
{
    U0TXBUF = 0x5a;
    P6OUT |= 1;
    for(; IFG1 & UTXIFG0 == 0;);
    P6OUT |= 4;
    for(;UART0.uart->utctl.txept == 0;);
    P6OUT &= ~5;
}

Итого:
На обеих ногах импульс длительностью 8,5 мс
То есть: TXIFG формируется сразу же, как только кинули байт в буфер.

10 мкс в прошлом разе - это время выполнения обработчика прерывания.
То есть, по всей вероятности, в момент прерывания TXEPT уже торчит.



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

Что и требовалось доказать.
TXEPT (по которому предположительно вызывается прерывание), тоже отодвинут на пол-интервала от конца стопового бита

[AHTOXA]

Итого:
На обеих ногах импульс длительностью 8,5 мс

На каких на обеих? А, понял

То есть: TXIFG формируется сразу же, как только кинули байт в буфер.

Для первого символа - да. Ибо U0TXBUF сразу же перезаписывается в сдвиговый регистр и опустошается.

10 мкс в прошлом разе - это время выполнения обработчика прерывания.
То есть, по всей вероятности, в момент прерывания TXEPT уже торчит.

Да там вроде команд не так много

Попутно ткнулся в выходной сигнал и обнаружил, что начало стартового бита запаздывает относительно момента записи в сдвиговый регистр на 400 мкс, то есть половину битового интервала.

Только всё же не в сдвиговый регистр, а в буфер передачи. Сдвиговый регистр - он унутре, и не доступен программисту

TXEPT (по которому предположительно вызывается прерывание), тоже отодвинут на пол-интервала от конца стопового бита

Я всё же сильно сомневаюсь, что TXEPT влияет на возникновение прерывания. Попробуйте писать пару символов сразу, картина изменится. (я, к сожалению не нашёл второго луча )

[MrYuran]

Попробуйте писать пару символов сразу, картина изменится. (я, к сожалению не нашёл второго луча )

Глянул.
Забавная картина.
Передаю 7 байтов подряд, в начале и конце обработчика TX_ISR машу ногой вверх/вниз.
И что же?
ровно в середине каждого стартового бита вижу тоненькую палку.
Ничего не понимаю! (с)

[AHTOXA]

ровно в середине каждого стартового бита вижу тоненькую палку.
Ничего не понимаю! (с)

Дык, это как раз нормально Стартовый бит пошёл - буфер передатчика освободился (отправлен в сдвиговый регистр) - прерывание.

У меня возникли подозрения, что я банально пропускаю прерывание. Проц очень сильно нагружен, там scmRTOS, дисплей, то, сё... На сегодня плюнул, в понедельник буду ставить более чистый эксперимент