Добрый день

есть некоторый код

Функцию я вызываю из прерывания, во время её выполнения прерывания нужно запретить.
Когда я их снова разрешу, то могут возникнуть любые прерывания, а не продолжалось USART1_TX, так ведь?
Вопрос, как сделать так, что бы после разрешения прерываний разрешалось только USART1_TX

Спасибо за помощь

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

Ничего в функциях обработки прерываний запрещать и разрешать не надо, т.к. это происходит полностью автоматически. Т.е. при возникновении ситуации прерывания с последующим перескоком из произвольного места программы на процедуру его обработки, прерывания автоматически запрещаются. И никакой cli дополнительно тут не нужен. Точно так же, прерывания восстановятся сами после выхода из той процедуры по iret.

А вот то, что в процедуре прерывания надо делать обязательно, то это сохранить содержимое регистра флагов (0x3F), а также исходные значения всех регистров, которые в той процедуре используете. Для этого и то, и другое, следует загнать в стек, а перед выходом восстановить из стека.

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

А вы в обработчике USART1_TX - запретите , сделайте сброс разрешений прерываний в контрольном регисте USART1, тех что Вам не нужны. Вывалитесь из обработчика , у Вас останется только USART1_TX.
Но Вам надо продумать , как потом включить их снова.
Да и вот ещё , TX у Вас "младшее" по приоритету прерывание , смотря как написан код , Вы рискуете туда и не добраться

Всем огромное спасибо за помощь)
Что-то я реально затупил, просто, как Палыч написал, функция вызывалась так же из другого места, где прерывания должны были запрещаться

Если тело функции обязательно не должно прерываться, то в этом случае сохраняют/восстанавливают флаг прерывания

Возник вопрос, почему могу туда не добраться
Просто в документации на контроллер про прерывания написано

There are basically two types of interrupts. The first type is triggered by an event that
sets the interrupt flag. For these interrupts, the Program Counter is vectored to the
actual interrupt vector in order to execute the interrupt handling routine, and hardware
clears the corresponding interrupt flag. Interrupt flags can also be cleared by writing a
logic one to the flag bit position(s) to be cleared. If an interrupt condition occurs while the
corresponding interrupt enable bit is cleared, the interrupt flag will be set and remembered
until the interrupt is enabled, or the flag is cleared by software. Similarly, if one or
more interrupt conditions occur while the global interrupt enable bit is cleared, the corresponding
interrupt flag(s) will be set and remembered until the global interrupt enable bit
is set, and will then be executed by order of priority.

То есть произошел как бы запрос на прерывание, установился флаг, и рано или поздно оно все равно произойдет, а почему нет?

Разве при переходе на вектор прерывания флаг I не сбрасывается?
Тогда CLI(); - лишняя.

Мной приведена функция, которую вызывают из обработчика прерывания (в этом случае - флаг I сброшен) и из другого места программы (например, из бесконечного цикла - флаг I установлен), т.е. примерно такая, как у автора вопроса. Код функции таков, что вся функция или её отдельный участок должен работать не прерываясь. Чтобы выполнение кода не прервалось, прерывания нужно запретить (конечно, если вызвана функция из прерывания - флаг I и так сброшен, и делать это не обязательно, но "лишний" раз - не повредит), но вот в конце функции (или её участка) разрешать прерывания нужно не всегда, а только в том случае, если при входе в функцию прерывания были разрешены. Imho, сделать это удобно сохраняя при входе в функцию регистр SREG (из него нам интересен флаг I), а в конце функции(участка кода) - восстановить SREG вместе с флагом I.

Всё достаточно просто, TX1 имеет низший приоритет . А вот INT0_vect высший, затем идут USART1_RX_vect и USART1_UDRE_vect и только потом Ваш. Вам надо посчитать насколько часто будут появлятся эти три прерывания, успеете Вы в паузах между ними обработать TX, ведь надо успеть принять символ, загрузить символ и ещё обработать INT0 и на все три уходит время . Смотря как Вы напишете код , у Вас просто может не хватить времени обработать TX . Его "забьют" старшие. Надо бы сказать , что USART1_TX_vect это дублёр USART1_UDRE - этот имеет тенденцию забросил и забыл. Первый (USART1_TX_vect) передачу закончил. В зависимости от требуемых функций ( не путать с функциями Си) можно использовать или UDRE или TX. Так например при обработке DS18B20 лучше не использовать UDRE. Кстати , этот флаг имеет "неприятную" особенность он практически "всегда установлен". С момента сброса и до выключения питания. Увидеть его в ноль можно посылая сразу большой массив данных. И так как он старше TX.....

Ето винавр, проснитесь!

ЗЫ в опциях обязательно включить -std=gnu99


Стало быть, Вы не умеете его готовить в условиях многозадачности?

Так это же отлично! И я этим радостно пользуюсь. Даже если другие прерывания задержат обработку UDRE и уже поднимется TXC, при освобождении процессора будет выполнен таки обработчик UDRE. Там я сброшу флаг TXC. И в самом же обрабочтике UDRE сниму его разрешение UDRIE при отправке последнего байта пакета. Таким образом, если до обработчика TXC вообще дошло, то это конец пакета.
Постоянное взведение UDRE тоже очень удобно, не нужно никаких танцев с тем, что первый байт пакета надо вручную затолкать в UDR, а уже остальные по прерываниям. Сформировал пакет и поднял UDRIE - данные пошли единообразным способом.

Причём здесь мнонгозадачность и DS18B20. Если Вы возьмёте листок бумаги и посчитаете поведение USART при использовании UDRE в качестве прерывания для обмена с DS , то увидите что , если не изменяет память, на 9 байте начинает лезть ошибка приема ответа DS . Точне посмотрю дома в записях. Считали и не я один. А запрещать и разрешать его в таком случае смысла не имеет , если есть TX.

и т.д.
При передачи сразу массива данных , нафинг он вообще нужен TXC ? Tолько что бы "красиво" в конце передачи массива узнать , что последний байт массива передали. Смысл? Всё равно же считаете переданные байты либо в ноль либо до какого-то значения.


А это я написал , так как топикстартер ещё не определился , что он вообще будет использовать и нигде не озвучивал свой замысел. А "неприятную" - как Вы видите я поставил в кавычках

Чтобы максимально быстро перевести драйвер RS485 в на приём и освободить линию после завершения передачи последнего байта.
UART используется и для симплексных каналов связи.

Или чтобы отключить передатчик для экономии батарейки например...

У Вас счётчик уже обнулился , зачем лишний обработчик прерывания

Ну, вроде ясно сказано:Чтобы передатчик не выключить раньше, чем будут переданы данные...

Похоже Илья упускает момент буферирования регистра UDR (один байт выплёвываем, а ещё 2 ждут в очереди).
И может показаться что передача окончена - софтовый fifo опустошили, а на самом деле аппаратный fifo ещё содержит данные для передачи.
Так вот TXC скажет нам когда действительно всё отправлено.

Ничего не понимаю! Цель уарта при обмене с далласом - формировать точные времянки без отрыва МК от задачи. Причем тут вообще UDRE? Какое он отношение к времянкам имеет, если его основное назначение - помочь несчасному в обеспечении непрерывной передачи данных?

А, разве не один "выплёвываем" (из регистра сдвига), а ещё один ждёт (в регистре данных)?

Нет не упускаю, один в регистре сдвига , второй в UDR. И так ситуация , тот что в регисре сдвига - предпоследний байт. В UDR - последний, возражений нет, надеюсь.
Поехали, переходим к языку , который здесь понимают лучше чем русский . Кстати вот это "... буферирования регистра UDR ..." и мешает работать нормально с DS.



Мы изменили режим работы при передачи в UDR последнего байта массива. Он ещё "телепается" или в UDR или ,если повезло ему , в сдвиговом регистре , что очень мало вероятно.
Какое будет следующее прерывание- только прием, что там с передатчиком начхать. Пусть он себе передает дальше , но как только slave , захочет нам что-то передать , мы уже готовы.
Итог: Всё мы готовы принимать данные.

С вариантом TX: Даже страшновато писать , хоть и asm



MAIN: Торчим в Main и возможно чем-то заняты , если не в цикле rjmp main
И вот оно счастье



И итог: Всё мы готовы принимать данные.
И что , мы в той же точке т.к. пока мы не изменим режим USART, о каком приёме может идти речь. Вот оно того стоило ждать этот USART1_TXC


Времянки от нас никуда не денутся- мы байт передали (1) или (0) и тут же должны вернуть его в массив данных,если работаете с SRAM, особенно при чтении температуры , когда каждый байт (Чтение 1) - возвращает значение или 0 или 1 и "выстрел" сразу все единиц через UDRE к чему приведёт? RX-то неуспевает - там ведь где-то ещё ответ только от первого байта принимается, а TX - уже второй передает. Посчитайте ,учитывая обработку приема - сколько тактов при Вашей частоте . И очень интересный материал:

Да, USART готов принимать данные. Но, за USART'ом, обычно, стоит некая микросхема-драйвер, которая как раз может быть и не готовой для приёма, и нужно дождаться окончания передачи и переключить её на приём...

Классная получается тема, сейчас мы USART, разберём по косточкам и при возникновении тем на эту тематику будем давать ссылку.
Давайте рассуждать - эта некая микросхема состоит из двух буферов - один на прием , второй передача и имеют один управляющий вход , который в зависимости , логический 0 или 1 , переключается в передача -приём. Не ошибся? Вариантов нет - случай 2. Но это всё абстракция, в любом случае при разработке системы учитываешь и такие вещи.

Эта абстрация называется RS-485...
А вот насчет далласа на уарте - ну настолько несимпатичная реализация... На одном пине TxD- включаем уарт, отправляем 0х30 для скорости 1,875мкс/бит, по TXC отключаем уарт и читаем состояние пина(пин на ввод). Остальные элементы - не проблема.

Возможно и так, но мне что-то помнится циферка 2.
Вот глянул DS на mega128:
Не уверен отлична-ли глубина буфера регистра UDR при передаче... Но на приём сдвиговый регистр + ещё 2 уровня буфера.
Посмотрел картиночку с блок-схемой UARTa - на передачу похоже действительно лишь один уровень буферизации.
Вы похоже правы.

Вот имено такой ответ и называется- абстракция.
А моя не абстракция называется MAX232xxx ,4332....Вы что считаете я не найду буфер RS485, который не надо переключать? Давайте всё таки придерживатся предмета спора и уважать мнение друг друга. Мы не говорили об "обвязки" AVR .Мы говорили , как он работает.
P/S/ Я выложил не тот материал, есть пример работы с DS18B20 от производителя , Там собственнно есть всё - вплоть до написанных функций на Си, но я поменял комп и он в стадии разбора -куды и чё. Но я не забуду и обязательно выложу пример и протокол , как работать used USART и c DS18B20 - Application.

Я уже потерял нить...
Напомните за что мы тут спорим? :-)

Да ни о чём , так просто , что бы мозги не застаивались