AVR USART+прерывания=потеря данных

[kison]

USART AVR
буферизуется 1 байт. Причём в первых и этого не было

Что значит - не было? Первым появился 90S1200, в нем самого модуля UART не было. Вторым 2313, а в нем уже была буферизация. И так и пошло - UART особо и не менялся.

[picavr]

а в нем уже была буферизация. И так и пошло - UART особо и не менялся.

у PIC сразу 2 байта буфер.

Не длиннее. Проверял. Немного впритык, но не длиннее.

Либо неправильно распределены ресурсы МК либо этих ресурсов действительно не хватает. Чаще неправильно распределяют...

В прерывании длинее чем приём 1 байта УСАРТ, разрешить (примерно посредине по времени) прерывание приёма УСАРТ в буфер, либо разбить это прерывание на ветки и выполнять за неск проходов, либо оставить внутри регистрацию события а обработку события вынести из прерывания.

[ilya_sh]

В прерывании длинее чем приём 1 байта УСАРТ, разрешить (примерно посредине по времени) прерывание приёма УСАРТ в буфер

Плохой подход - глоб. флаг установил - неизвестно какое прерывание сработает... Тем более, что усарт последний

либо разбить это прерывание на ветки и выполнять за неск проходов, либо оставить внутри регистрацию события а обработку события вынести из прерывания.

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

[SasaVitebsk]

Что значит - не было? Первым появился 90S1200, в нем самого модуля UART не было. Вторым 2313, а в нем уже была буферизация. И так и пошло - UART особо и не менялся.

В atmega8515 есть фуз "AT90S4414/8515 compatibility" почитайте что он делает.

[SasaVitebsk]

у PIC сразу 2 байта буфер.

У AVR тоже 2 фактически, у LPC21xx - 16, у х51 - 1 байт. Что это меняет? работать можно с любым. Просто надо учитывать особенности аппаратного построения и соответственно писать программы.

[kison]

В atmega8515 есть фуз "AT90S4414/8515 compatibility" почитайте что он делает.

Отключает буфер на ВТОРОЙ принятый байт. Т.е. буферизация все равно остается. И АВР-ов без нее не было вообще. Буфер на 1 байт был и в 90S8515 и в 4414. Это SPI может существовать без буфера или I2C, а вот асинхронный интерфейс без этой фичи неработоспособен в принципе.
Кстати и в 51 буфер тоже ЕМНИП был. Его просто не могло не быть

[picavr]

Плохой подход - глоб. флаг установил - неизвестно какое прерывание сработает.

Почему же НЕИЗВЕСТНО? Те которые не нужны ВЫКЛЮЧИЛ на время обработки, а после обработки перед выходом - ВКЛЮЧИЛ.

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

Это самое важное правильно распределить время процессора до написания программы )))))
а не рассчитывать написанное...

[SasaVitebsk]

Отключает буфер на ВТОРОЙ принятый байт. Т.е. буферизация все равно остается. И АВР-ов без нее не было вообще. Буфер на 1 байт был и в 90S8515 и в 4414. Это SPI может существовать без буфера или I2C, а вот асинхронный интерфейс без этой фичи неработоспособен в принципе.
Кстати и в 51 буфер тоже ЕМНИП был. Его просто не могло не быть

Слушайте, при всём моём к вам уважении, давайте не будем вырывать слов из контекста и наводить тень на плетень. И вы и я понимаем о чём шла речь. В моём ответе для picavr я пишу "У AVR тоже 2 фактически". Но реально, буферезуется 1 байт, второй просто принимается в сдвиговый регистр. В момент когда он будет принят, он перепишется в "буферный", а тот будет потерян. С точки зрения обработчика это эквивалентно 2 символам в буфере. В первых - был просто сдвиговый регистр, равно как и в х51. Именно об этом я и написал.
Ежу понятно, что такой же регистр есть скажем и в ARM7 + фифо на 16. Но они же не пишут 16+1.

Вы же понимаете, что я не просто это вычитал в даташите. Я с этим работал. Я работал с AVR ещё тогда, когда макс. частота была 8 и в службе техподдержки мне отвечали: повышение не планируется. Тогда, когда у них были реальные хомуты с той же eeprom и флэш. И когда вышла новая версия USART я её тестировал на серийном изделии. И в моём варианте этот фуз был не нужен. Моя прога работала что так, что этак. А вы пишете "особо и не менялся".

[kison]

В первых - был просто сдвиговый регистр, равно как и в х51. Именно об этом я и написал.

Однако. А даташит утверждает иное. Смотрю на давно умерший 90s8515 и вижу сдвиговый регистр + регистр UDR. По Вашей логике этого регистра там нет, и чтение идет сразу из сдвигового? Зачем тогда бит переполнения в статусном регистре?
Ну и логика работы -

Whether or not a valid stop bit is detected at the end of a character-reception cycle, the data is transferred to UDR and the RXC flag in USR is set.

Т.е. происходит передача из сдвигового в.. в никуда??? Вот ведь чудеса
Вот ровно то же самое и в MCS51 - сдвиговый регистр + регистр результата.
Привести блок-схемы?

[picavr]

А даташит утверждает иное

А по логике вещей должен быть ещё хотя бы 1 регистр - буфер. Между сдвиговым и UDR.

Но реально, буферезуется 1 байт, второй просто принимается в сдвиговый регистр.

ИМЕННО !!! с такой граблей я и сталкивался. Пишут 2 а есть 1 ))))) После PIC был удивлён, в PIC можно было взять 2 байта из UDR пока принимается ещё один в сдвиговый.