ну насчет правильно неправильно тут я судить не буду

но код

U0IER |= IER_THREIE;

куда быстрее выполняется чем код

if( !(status_word & STW_THR_BUSY) )
{ status_word |= STW_THR_BUSY;
U0THR = *string++;
}

и места меньше потребляет и линейный полностью и конвейер проца не сбрасывает (зависит от компилятора). И флагов дополнительных не надо, одни минусы, так вчем прикол ? я реализовал обмен через разрешение прерываний во многих процах(ATMEGA, ST16C1550+8051, TMS320VC5502 ... ) и намой взгляд это наиболее быстрый и экономический вариант если проц без ДМА, и нигде небыло проблем.



Он оптимизированный , просто тогда об этом недогадывались наверное ....

Ну раз речь пошла о быстродействии
1.Знаете сколько наносекунд выполняется у LPC обращение к периферии? Cоветую поинтересоваться на досуге.
2.Приведенная Вам строка совершенно не заменяет приведенный мною код.
В своем варианте Вы кроме разрешения прерывания сделаете
- лишнее занесение первого байта в буфер в функции передачи
- лишнее извлечение первого байта из буфера в обработчике (все это естественно работа с байтами и возня с указателями)
- ну и само собой еще одно обращение в обработчике к медленной периферии для запрещения прерывания.

Вместо всех этих телодвижений - анализ/сброс бита и прямое без промежуточной буферизации занесение в THR.

Да. Сколько там FLASH у LPC2124 не напомните? Сколько написали кода?

один бит в слове где используется дюжина флагов из 32. Кроме того можете работать и по железному флагу TEMT - выиграите 5-6 команд (в сумме с обработчиком прерывния).

Прикол в том, что в Ваших рассуждениях ошибка на ошибке

Ну и что? Из этого следует что всегда и везде надо поступать по этому шаблону?

Их нет и в LPC, если чуть-чуть подумать.

ИМХО отключение FIFO насовсем не есть гут (накладных расходов на кучу прерываний может быть больше чем выйгрыш, да и шансов создания нежелательных пауз между передаваемыми словами побольше).
А вот отправка последнего символа отдельно от всего пакета, тут можно подумать.

Меня и заинтересовало - пользовался ли кто этим для 485 в частности?


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

Дело не в проигрыше/выигрыше а _необходимости_ выполнить какие-либо действия после передачи, например, байта. Если физический протокол так спроектировал кто-то, то это перечеркивает использование FIFO.

Угу. А реализовать эту _необходимость_ можно всякими способами. Вот тут и рассматриваются варианты с плюсами/минусами пройгрышами/выйгрышами.
Ну да ладно, думаю мы друг-друга поняли.

да нет никаких проблем в работе, броблема в том что надо переписывать драйвер под этот проц что даже не планировалось.

по поводу времени выполнения тут спорный момент.

тест 1


врямя замеряю осцилом ~387нс

тест 2

врямя замеряю осцилом ~218нс

а у вас 2 вызова идет это примено 218*2 что больше 387

Вывод: бесполезный спор который никому не нужен, на этом тему лучше закрыть.

Вы говорите о двух принципиально разных подходах в реализации железа UART. AVR и LPC имеют разные реализации и управлять ими придется по-разному. Для LPC, имхо, zltigo показал более правильный способ. У Вас в функции print, якобы, меньше действий, но в прерывании первый байт вычитывается из буфера и помещается в регистр для отправки. Об этом забываете???

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



тест неправильный. ARM - 32-битная архитектура, которой тяжело работать с байтами. zltigo говорил про 32 флага, а Вы char тестируете. Ради интереса сделайте тест с int и сравните полученный код

результат такой же , и АRM имеет команды которые адресуют байты, так что ему пофиг

а я очем !!! это и есть кривизна что он не такой как у других.

Шлангом прикидываемся? Глупо

Из того, что Вы использовали какое-то железо через заднепроходное отверстие, а другое железо, как вдруг оказалось, не "пролезает", не следует, что одно железо кривее другого.

На самом деле у него и в print больше, ибо он этот самый байт в буфер еще сначала помещает.
Про сведение задачи почему-то к одной строчке кода (да то пришлось зачем-то время на два умножать для "доказательства" чего? ) вообще нет слов

Извините за тупизну и поднятие старой темы, у меня есть вопросы касающийся кода функци приведнной в сообщении zltigo.
Как реализовано "выгребание" буфера tbuf.buf? В прерываниях? Как реализована установка флага STW_THR_BUSY? Интересует конечно не конкретный код а алгоритм.
Достаточно долго пытаюсь понять предложенное решение но что-то мозжечка не хватает, если не трудно, поясните пожалуйста.
Заранее спасибо.