Ама там има хардуерен буфер за UART-a ?????!!!!!!

...

Е тогава е нормално да ти се препълва буфера. Пика няма как да знае че данните са валидни или не. Но това не му дава право да се успива и да не може да възобнови комуникацията след това. Аз поне до сега не съм успял да lock-на UART -a досега по тоя начин.

За това с прекъсванията, живо ме интересува. Ако е има наистина такъв бъг, то той трябва да е описан. Иначе има бъгове по контролера за прекъсванията, на определени пикове, на определени модули, при обределени условия. Но генерален проблем от типа който описваш (при всички пикове) досега не съм виждал.

Не няма. Т.е има два байта буфер и приема трети. Не е без хич, но си е нищо.

Да, пак е нещо. AVR-а си има само 1 регистър - изпуснеш ли момента, целия пакет заминава.

То и в пикльовците е един, ама е FIFO...пълни се като пълнител на пистолет (много ми харесва това обяснение ) Та проблема с прекъсванията го имах при използване на UART, I2C, писане/четене на флаша и след събуждане на процесора...Не го казвам просто така, доста време загубих там, като го написах с do-while се оправи работата...

Цецо:
Как го правите това, да не се нулира коректно? Бита със сигурност мърда коректно според мен.

Изглежда не съм се изразил ясно.
Разбира се,че бита се нулира след bcf INTCON,GIE . Но не може да блокира прекъсване активирано по време на изпълнение на самата инструкция. БЛОКИРАТ СЕ САМО ПРЕКЪСВАНИЯ ПОСТЪПИЛИ СЛЕД УСТАНОВЯВАНЕТО НА GIE В 0. Когато постъпи прекъсване по време на изпълнение на bcf INTCON,GIE ( GIE е все още 1) прекъсването се активира. При самото активиране на прекъсването GIE става 0. Cледва изход oт прекъсване с инструкция RETFIE. ТАЗИ ИНСТРУКЦИЯ ВДИГА БИТ GIE В 1.
Резултата в тази ситуация е: GIF=1 за инструкцията следваща
bcf INTCON,GIE. Неблокираното прекъсване установява GIE В 1 чрез RETFIE.
Ясно е, че колкото по-вече са прекъсванията толкова по вероятно е да се получи тази ситуация.

Цецо:
Но тогава и вашия while цикъл не е 100% решение.

Това е 100% решение. Този цикъл не прави нищо друго освен
изчакване на момента когато при изпълнението на някоя от инструкциите bcf INTCON,GIE няма заявка за прекъсване и съответно GIE се установява в 0 за следващата инструкция( няма RETFIE от неблокирано прекъсване да обърне GIE в 1 и той остава в 0).

Това не е BUG, a начин на работа (независимо дали ни харесва или не)!
Имаше някакъв PDF c диаграми от които се виждаше целия процес но нe си спомням вече...

Може да изглежда тъпичко, но аз си слагах винаги една след друга 2 инструкции bcf INTCON,GIE
Ако възникне IRQ на първата, то при излизането ще се изпълни поне една инструкция преди да се обработят другите заявки. Не съм имал проблем с нежелани прекъсвания

Дайте да го видя тоя документ де. Всичко друго е наизуст.

Опс намерих го. AN576.

...

Абе ако е БЪГ трябва да го пише в ератата, а не в дата шеета.
По принцип говориш малко наизуст (не се обиждай). Забраната на прекъсванията не става за време 0. На никой процесор. Теоретически погледнато всеки процесор който забранява прекъсванията е уязвим в момента на изпълнение на инструкцията за забрана. Винаги може да пристигне прекъсване в средата на инструкцията. Прекъсването ще се изпълни. Това не е страшното. Друг е въпроса защо след излизане от прекъсването флага не става 0 (което прави прекъсната инструкция), а автоматически разрешава прекъсването. Вероятно е защото инструкцията се изпълнява преди да се влезе в прекъсването. Но това значи че просто след излизане от прекъсването не трябва да се вдига в флага автоматично в "1", а просто да не се пипа. Според мен това си е недоизмислица в ядрото, а не бъг. Както и да е, сега проучвам проблема, но ако е вярно наистина е тъпо.

...

Що в началото на INT вектора да изпълняваш GIE=0? Това пък за какво? То си се прави само. Веднъж намъкнал се в прекъсването, няма кой да те прекъсне. Затова и проблема според мен не е вътре в прекъсването. Проблема ще дойде после когато се окаже че инструкцията GIE = 0, всъщност не е свършила нищо, и програмата прекъсне някъде където това е опасно.

...

Прекъсваш - прекъсване? На PIC? Не бих посмял. Това е PIC? Най многото което си позволявам е да използвам приоритети при PIC18. Ама да прекъсвам прекъсвания от еднакъв преоритет - звучи ми опасно. Май е време да смениш ядрото. Микрочип не е за теб.