продолжить прерывание, atmega128 winavr Опции

[Mikron]

Добрый день

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

Код

void funс(void){
    cli();
    ...
    sei();
}
ISR(INT0_vect){
    ...}
ISR(USART1_RX_vect){
    ...}
ISR(USART1_TX_vect){
   ...
   func();
   ...}
ISR(USART1_UDRE_vect){
...  }
...

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

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

[_Pasha]

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

Код

#include <util/atomic.h>
void func(void)
{
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
  {
   <Function's body&soul>
  }
}

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

Так например при обработке DS18B20 лучше не использовать UDRE.

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

[ILYAUL]

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

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

ReAl Так это же отлично! ......

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

Кстати , этот флаг имеет "неприятную" особенность он практически "всегда установлен".

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

[demiurg_spb]

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

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

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

[ILYAUL]

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

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

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

[Палыч]

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

Ну, вроде ясно сказано:

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

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

[demiurg_spb]

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

[ILYAUL]

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

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

Код

USART1_UDRE:
                      push ....... не комментирую
                      ________  сам обработчик
                      dec   count; вычитаем счётчик количества передаваемых байт ( наш мвассив данных )
                      brne  END; проверяем всё передали, если нет всё уходим из обработчика
; Всё передали ---------------------------
                       ldi     temp,1<<RXCIE1|0<<UDRIE1|1<<RXEN1|1<<TXEN1; 0 - в UDRIE написал для наглядности-на самом деле его можно и не писать
                       sts    UCSR1B,temp  ; Изменили  режим работы USART
END:                pop  ......
                       reti

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

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

Код

USART1_UDRE:
                      push ....... не комментирую
                      ________  сам обработчик
                      dec   count; вычитаем счётчик количества передаваемых байт ( наш мвассив данных )
                      brne  END; проверяем всё передали, если нет всё уходим из обработчика
; Всё передали ---------------------------
                       ldi     temp,0<<UDRIE1|1<<RXEN1|1<<TXEN1; 0 - в UDRIE написал для наглядности-на самом деле его можно и не писать
                       sts    UCSR1B,temp  ; Изменили  режим работы USART
END:                pop  ......
                       reti

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

Код

USART1_TXC:
                      push  ...........
; Естественно SREG - а куда же без него , туда же
                       ldi     temp,1<<RXCIE1|0<<UDRIE1|1<<RXEN1|1<<TXEN1
                       sts    UCSR1B,temp  ; Опять изменили  режим работы USART
                       pop ..............
                       reti

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

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

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

[Палыч]

Итог: Всё мы готовы принимать данные.

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

[ILYAUL]

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

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

[_Pasha]

Но это всё абстракция

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