Ксения (06.08.2005 12:41, просмотров: 1) ответил psL на вообще-то пока UART байт не примет, он его в регистр приема не запишет.
Ответ: Я имела в виду, что наличие аппаратного FIFO-буфера позволяет ДОЛЬШЕ находиться в процедуре обработчика прерывания. Дело в том, что во время выполнения этой процедуры прерывания являются блокированными (до тех пор, пока она не закончится), а потому в ней нельзя находится дольше периода поступления байтов из UART. Тот байт, запись которого в приемник вызвала это прерывание, несомненно будет обработан, т.к. он сразу же выбирается процедурой из регистра (приемник при этом опустошается). Процедура может "думать" по поводу этого байта даже до тех пор, пока в приемник не поступит следующий байт (ему есть место, поскольку приемник к этому моменту уже пуст). Но не дольше, т.к. в момент поступления еще одного байта его уже некуда будет девать. А наличие 2-байтного FIFO-буфера у Tiny2313 позволяет сохранить и последний байт тоже.
Возникает вопрос - зачем так долго находиться в прерывании? Этот может оказаться небходимым, когда МК должен проверять валидность или синтаксис команды, поступающией к нему из UART. Например, все поступившие извне символы, он может складывать в "корзинку" (стринг) до тех пор, пока не придет символ конца строки. Именно на последнем символе МК должен решить - какой смысл этой команды, нет ли в ней ошибок, и тут же, в зависимости от решения, либо инициализировать полученное задание, либо выдать сообщение об ошибке.
Ясно, что обработка символа конца строки займет гораздо большее время, чем складирование всех остальных байтов. Этим и обусловлен интерес иногда находиться в прерывании дольше положенного срока.
Есть и такой вариант, чтобы процедура перывания только складировала, а разбор смысла производился вне прерывания. Да, обычно так и поступают в больших компьютерах, которые могут себе позволить держать многострочные "корзинки" (пока первую осмысливают, байты копятся в следующую). А у данного МК памяти кот наплакал - всего 128 байт, из которых почти половина уходит на стеки.
А принимая во внимание обычно крайне ограниченный набор внешних символьных команд, часто оказывается, что вести "осмысление" не выходя из прерывания эффективнее. Тем более, когда такая операция не слишком продолжительна.