Многопоточность на attiny2313 Опции

[aivs]

Продолжаю изучать программирование под avr.
Написал программу "Часы", добавил три кнопки для выставления времени, кнопки обрабатываются по прерыванию от Таймера каждые 0.1 сек, время тикает от того же таймера, все красиво и четко работает.
Затем я задействовал термодатчик ds18b20 с шиной 1ware и написал программу для показа температуры на дисплее hd44780, датчик опрашивается по прерыванию от таймера каждые 0.1 сек, прекрасно работает.
А затем я решил совместить эти две программы, чтобы часы в одной части дисплея работали, а температура в другой части. Получилось кривенько, при опросе датчика прерывания запрещены, соответственно на нажатия кнопок реакция заторможенная.
Подскажите, как бы реализовать подобие многопоточности?
Может тут подойдут конечные автоматы?
Приветствую список литературы по этому вопросу!
А может для attiny2313 вообще это не возможно сделать без тормозов?

Сообщение отредактировал aivs - Apr 6 2013, 21:16

[ILYAUL]

Получилось кривенько, при опросе датчика прерывания запрещены

- так разрешите. И код не помешало бы

[Xenia]

Получилось кривенько, при опросе датчика прерывания запрещены, соответственно на нажатия кнопок реакция заторможенная.
Подскажите, как бы реализовать подобие многопоточности?
А может для attiny2313 вообще это не возможно сделать без тормозов?

Полагаю, что проблема не в многопоточности, а в том, что нельзя долго сидеть в прерывании. Правило тут простое - если в самой функции обработки прерывания или вызываемых из нее подпрограмм существует хотя бы в одном месте ожидание (цикл в выходом по состоянию), то такого допускать никак нельзя. Ожиданиями в прерывании можно просадить любой процессор, каким бы он ни был быстрым. Поэтому тормоза не у ATtiny2313, а у того, кто запрограммировал паузы в прерываниях.

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

В крайнем случае, в прерывании допустимо начать процесс, если его старт требует синхроности с событием, вызывашим прерывание. А для последовательной передачи бит существует SPI, который тоже способен вызывать прерывание по завершению чтения/записи байта (8 бит). И даже в голову не должна приходить крамольная мысль, пославши первый байт, дождаться там же в прерывании окончания передачи, чтобы послать следом второй.

Сама я с интерфейсом 1ware дела никогда не имела, но полагаю, что SPI с этой задачей должен справиться. В конце концов, побитно можно выдавать сигнал по таймеру, поднимая и опуская уровень в РАЗНЫЕ (!) такты. Например, часовой таймер вызывает прерывание каждую миллисекунду. Так вот можно сделать так, что через каждую миллисекунду какой-то пин в порте будет изменять свое состояние. И не в коем случае не жмотиться, пытаясь поднять и опустить уровень за один присест с фиксированной задержкой - задержек в прерывании быть не должно, их делают периодом таймера. Однако повторю, что это самый крайний случай, а не рекомендация делать меандр посредством частых прерываний. Наконец, еще есть UART/USI, который может работать в режиме 2-wire, хотя его использвать жалко, т.к. это обычно единственная связь с внешним миром.

Стоит всякий раз обдумывать, насколько неотложно необходима реакция на прерываение. Некоторые совершают ошибку, полагая, что если АЦП выставил сигнал готовности, а прерывание от него сработало, то, мол, надо тут же в прерывании его опрашивать. Ничуть не бывало - АЦП потерпит до следующего такта, а потому пороть горячку не следует - пусть основной цикл опрашивает АЦП, ему все равно больше делать нечего. Но это в том случае, если опрос АЦП требует посылки в него управляющего байта, задержки на его переваривание и приема байтов данных - всего этого в прерывании делать нельзя. Но если АЦП таков, что дает результат в порту или регистре, то взять его прерывании можно и нужно.

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

P.S. ответила развернуто только потому, что ATtiny2313 - моя любимая тинька, и я сержусь, когда ее незаслуженно обижают.

[_Артём_]

что нельзя долго сидеть в прерывании.

Можно..в разумных пределах. Если вложенные прерывания допустимы.

Сама я с интерфейсом 1ware дела никогда не имела, но полагаю, что SPI с этой задачей должен справиться.

SPI-то справится, но для 1-wire скорость слишком большой может быть(8-16МГц/128 - так быстро не надо)

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

Не хватает однократного режима таймера - выдать 0 на выход, установить через сколько надо тактов 1 и чтобы однократно. В принципе ШИМ сгодится...

Вход завести на захват по фронту. И где-нибудь разбирать захваченное...

Наконец, еще есть UART/USI, который может работать в режиме 2-wire, хотя его использвать жалко, т.к. это обычно единственная связь с внешним миром.

Стандартное решение, но на мегах UART-ов не напасёшся обычно.

[aivs]

В прерывании я опрашиваю три кнопки, и если кнопка нажата то просто инкрементирую переменную, никаких задержек, на каждое 10 прерывание прибавляется секунда.

Код

// Процедура обработки прерывания по Таймеру 1 каждую 0.1 сек. Проверяем нажатия кнопок и прибавляем секунды
ISR (TIMER1_COMPA_vect){
  // При нажатии на кнопку PD5 увеличиваем час на один
  if (bit_is_clear(PIND,5)) {   // Если кнопка PD5 нажата
    _delay_ms(25);              // Пауза на 25 мс
    if (bit_is_clear(PIND,5)) { // Если кнопка PD5 нажат
      while (bit_is_clear(PIND,5)); //Ждем отжатия клавиши
      hours++;
    }
  }

  // При нажатии на кнопку PD4 увеличиваем минуту на один
  if (bit_is_clear(PIND,4)) {   // Если кнопка PD5 нажата
    _delay_ms(25);              // Пауза на 25 мс
    if (bit_is_clear(PIND,4)) { // Если кнопка PD5 нажат
      while (bit_is_clear(PIND,4)); //Ждем отжатия клавиши
      minutes++;
    }
  }

  // При нажатии на кнопку PD3 увеличиваем секунду на один
  if (bit_is_clear(PIND,3)) {   // Если кнопка PD5 нажата
    _delay_ms(25);              // Пауза на 25 мс
    if (bit_is_clear(PIND,3)) { // Если кнопка PD5 нажат
      while (bit_is_clear(PIND,3)); //Ждем отжатия клавиши
      seconds++;
    }
  }

  // 10 прерываний в секунды, на каждое 10 прерывание прибавляем секунду
  second_timer++;
  if (second_timer == 10) {
    seconds++;
    second_timer = 0;
  }
}

Вот главный цикл:

Код

// Основная программа
void main(void) {
  // Деление частоты системного генератора на 1. 8MHz/1 = 8MHz
  CLKPR=0x80;
  CLKPR=0x00;

  // Инициализация порта B. LCD HD44780
  // DDRB  = 0b11111111;
  // PORTB = Порты инициализируются в библиотеке

  
  // Инициализация порта D
  // DDRD.0 = ввод; DDRD.1 = ввод; DDRD.2 = ввод; DDRD.3 = ввод; DDRD.4 = ввод; DDRD.5 = ввод; DDRD.6 = ввод; DDR$
  // PORTD.0 = резистор; PORTD.1 = резистор; PORTD.2 = резистор; PORTD.3 = резистор; PORTD.4 = резистор; PORTD.5 $
    DDRD=  0b00000000;  // 0 = ввод (кнопка); 1 = вывод
    PORTD= 0b11111011;  // Если DDRD.0 == 0(ввод), то в PORTD.0 == 1 (резистор подключен) или PORTD.0 == 0 (резис$
                        // отключаем на PD2 нагрузочный резистор, там сидит термодатчик
  //PORTD= 0b76543210   // Соответствие ножек битам порта

  // Инициализация таймера/счеткика T1
  TCCR1A=0x00;
  TCCR1B=0x0D;  // коэф предделителя 1/1024 и совпадение в канале А
  OCR1A=780;    // Прерывание возникает при достижении таймером числа 780

  // Инициализация прерываний от таймера
  TIMSK=0x40;   // разрешаем прерывание от таймера по совпадению в канале А
  sei();// Разрешаем прерывания

  lcd_init();// инициализация LCD
  _delay_ms(10);
  lcd_clr();// очистить LCD
  // Вечный цикл вывод информации на дисплей
  while(1) {
    cli();                      // Запрещаем прерывания
    ticking_clock();            // Ход часов
    set_time();                 // Выставляем время
    sei();                      // Разрешаем прерывания

    // Получаем температуру ****** Получать температуру нужно так чтобы не тормозить вывод информации при опросе $
    temp = temp_18b20();
    if(temp > 1000) { //если температура <0
      temp = 4096 - temp;
      temp = -temp;
    }
    lcd_gotoxy(1, 1);           // Переходим к 0 ячейки
    lcd_string("Temp=");
    itoa(temp,ch_temp,10);      // Переводим число в символы
    lcd_string(ch_temp);        // Выводим на дисплей
  }
}

Задержки с использованием _delay_us и _delay_ms содержат функции: set_time() и temp_18b20().
set_time() выводит на экран HD44780 время (много задержек _delay_ms)
temp_18b20() запрашивает и получает температуру по 1-wire& ((много задержек _delay_us)

Как понял мне нужно все задержки _delay_us и _delay_ms сделать через прерывания?

Сообщение отредактировал aivs - Apr 7 2013, 08:00

[_Pasha]

Могу сказать, как делаю я.
1. Беру за основу идею, заключенную в Protothreads
2. Разбиваю задачу на фиксированное число потоков вида

Код

void *thread(void *pc);

3. Все эти потоки свожу в функцию вида

CODE

#define RUN(name) do{\
static void *pc=NULL;\
static char lock=0;\
if(lock==0){lock=1; pc=name(pc); lock = 0;}\
}while(0);
void system(void)
{
RUN(thread1);
RUN(thread2);
// etc.

int main()
{
while(1) system();
return 0;
}
}

4. Теперь с 1-wire
4.1.Лучше всего сделать на основе того же простого треда нормальный драйвер, с перепрограммированием таймера на все необходимые задержки. Это будет полностью прозрачная штучка.
4.2.Еще вариант- все длинные задержки делать на основе опроса сист.таймера

Код

static timer_t time;
if(get_time(time) < DELAY_460ms) system();//замерзли до окончания сброса

а все короткие - с помощью delay_us()
Оно-то у меня работает, но подход неправильный.

По поводу остального - ну нет смысла опрашивать клавиатуру, делать динамическую индикацию и прочая - в прерывании!
---
Xenia: с Новым Годом по тарабарскому календарю

Сообщение отредактировал _Pasha - Apr 7 2013, 10:00

[mempfis_]

Затем я задействовал термодатчик ds18b20 с шиной 1ware и написал программу для показа температуры на дисплее hd44780, датчик опрашивается по прерыванию от таймера каждые 0.1 сек, прекрасно работает.
А затем я решил совместить эти две программы, чтобы часы в одной части дисплея работали, а температура в другой части. Получилось кривенько, при опросе датчика прерывания запрещены, соответственно на нажатия кнопок реакция заторможенная.

Есть такая проблема при опросе DS18B20. Датчик требует точного выдерживания временных интервалов, поэтому тут без __delay_cycles(x) с запрещёнными прерываниями никак. Но если внимательно посмотреть на шину 1-wire, то в принципе точно выдерживать временные интервалы необходимо не постоянно, а только в пределах определения наличия устройства на шине и при чтении бита данных. Т.е. можно между чтениями битов на некоторое время разрешать прерывания чтобы сработали прерывания, возникшие в моменты чтения отдельных бит.
А как часто Вы оправшиваете датчик? Некоторые товарищи на форуме советуют опрашивать не чаще чем раз в 30 секунд, ибо будет саморазогрев датчика. Также нет смысла опрашивать его часто при измерении температуры воздуха.

Мне неоднократно приходилось опрашивать такие датчики и отображать температуру на дисплее + сканировать кнопки. Могу кое что посоветовать по поводу организации программы. Вам нет смысла висеть в обработчиках прерываний для сканирования кнопок и динамической индикации. Достаточно одного таймера с периодом = 10мС/(число отображаемых разрядов индикатора). Если у Вас 4 разряда, то период 10/4 = 2,5 мС. Это обеспечит частоту обновления ~100 Гц. В прерывании просто выставляйте флаг что было прерывание, а в основном цикле анализируйте этот флаг, выполняйте процедуру динамической индикации и опрос кнопок. Эти процессы не требуют сверхбыстрой реакции. Если Вы организуете чтение датчика с разрешёнными на время прерываниями между таймслотами 1-wire, то Вы даже не заметите мерцания индикации или пропуска кнопок.
А для часов заведите другой таймер, который будет генерировать прерывания раз в 0,5-1 секунду. За 500 мС процессор всегда найдёт возможность обработать этот флаг и Вы не потеряете точности хода.
В загруженных программах, где много чего обрабатывается, но прерывания разрешены более точно считать время помагает переменная timestamp, которую необх. инрементировать при входе в обработчик прерывания от таймера. Тогда при обработке флага прерывания от таймера Вы более-менее точно будете знать сколько было прерываний от данного таймера. Но Ваша задача не настолько сложна и загружена, чтобы вводить подобное ухищрение.

[Xenia]

Код

  // Вечный цикл вывод информации на дисплей
  while(1) {
    cli();            // Запрещаем прерывания
    ticking_clock();                    // Ход часов
    set_time();        // Выставляем время
    sei();            // Разрешаем прерывания

    // Получаем температуру ****** Получать температуру нужно так чтобы не тормозить вывод информации при опросе $
    temp = temp_18b20();
    if(temp > 1000) { //если температура <0
      temp = 4096 - temp;
      temp = -temp;
    }
    lcd_gotoxy(1, 1);        // Переходим к 0 ячейки
    lcd_string("Temp=");
    itoa(temp,ch_temp,10);    // Переводим число в символы
    lcd_string(ch_temp);        // Выводим на дисплей
  }
}

Возможно, это дисплей время тянет, т.к. выполнение функции lcd_string() может занимать продолжительное время (проверить своё опасение не могу, т.к. ее код мне не ведом).
Самое простое - сэкономить на дисплейном выводе, если температура остается прежней. Какой смысл обновлять на нем число, если оно не изменилось?
Например, так:

Код

if(temp != oldtemp)
{ lcd_gotoxy(1, 1);        // Переходим к 0 ячейки
   lcd_string("Temp=");
   itoa(temp,ch_temp,10);    // Переводим число в символы
   lcd_string(ch_temp);    // Выводим на дисплей

  oldtemp = temp;
}

То же можно сделать и с set_time(), которая выводит время на экран. Полагаю, что время выводится не с миллисекундной точностью, а раз так, то перед его выводом на дисплей тоже можно проверить еще в бинарном виде, стоит ли новое значение вывода (скажем, если время выводится на дисплей без десятых долей секунды).
Или начало строки "Temp=" выводить только однажды (перед вечным циклом), если оно всегда на одном месте печатается, и перескакивать с помощью lcd_gotoxy(1, 6) сразу на цифровую область.

[mempfis_]

Задержки с использованием _delay_us и _delay_ms содержат функции: set_time() и temp_18b20().
set_time() выводит на экран HD44780 время (много задержек _delay_ms)

Только сейчас обратил внимание что используется жк индикатор. На жк индикатор стоит выводить данные только по необходимости. Ваша программа очень долго висит в обработчике прерываний от кнопок. Для сканирования кнопок лучше использовать периодический опрос по таймеру. Процедуры задержек стоит реализовать так, чтобы они самостоятельно не запрещали прерывания. Например при работе с индикатором можно вообще не запрещать прерывания т.к. это приведёт только к увеличению задержки что для индикатора не критично. А вод для 1wire для точного выдерживания задержек прерывания нужно запрещать.

[_Pasha]

Возможно, это дисплей время тянет

+1
Там в низкоуровневом чтении/записи обычно используется чтение статуса и ожидание, пока контроллер освободится. Вот туда я и помещаю system(), получаем

Код

while (HD44780_Busy()) system();

Культурненько и прозрачненько.

[Xenia]

Там в низкоуровневом чтении/записи обычно используется чтение статуса и ожидание, пока контроллер освободится. Вот туда я и помещаю system(), получаем

Код

while (HD44780_Busy()) system();

Культурненько и прозрачненько.

А system() это что такое?

[_Pasha]

А system() это что такое?

Это несколькими постами выше.

[_Артём_]

Есть такая проблема при опросе DS18B20. Датчик требует точного выдерживания временных интервалов,

Проблемы скорее нет, чем есть.
Разве самому можно её создать, подключив 1-wire к неподходящим для этого выводам МК.
Точности тоже никакой не требуется.

поэтому тут без __delay_cycles(x) с запрещёнными прерываниями никак.

Делать запрет прерываний на 500 мкс? Странно это.

Но если внимательно посмотреть на шину 1-wire, то в принципе точно выдерживать временные интервалы необходимо не постоянно, а только в пределах определения наличия устройства на шине и при чтении бита данных.

Все циклы обмена начинаются мастером. Остаётся только настроить захват таймера по фронту(или считывать по PIN_CHANGE, но это хуже).

[mempfis_]

Проблемы скорее нет, чем есть.
Разве самому можно её создать, подключив 1-wire к неподходящим для этого выводам МК.

Не всегда программист выбирает к какому выводу подключать датчики. И не всегда "правильные" выводы свободны.
Зато можно написать одну процедуру чтения 1-wire устройства, которая будет работать на любом пине любого порта AVR.
Для AVR у меня именно так и сделано.

Точности тоже никакой не требуется. Делать запрет прерываний на 500 мкс? Странно это.

В чём странность запрещать прерывания? Возникновение прерывания во время вызова процедуры __delay_cycles() увеличивает задержку на время входа в прерывание, его обработки и выхода из прерывания. Если прерывание тяжёлое, то и задержка может растянуться. Если посмотреть на таблицу, то практически везде требуется точность не хуже 10 uS.

[_basile]

DATASHEET 2313: "The External Interrupts are triggered by the INT0 pin, INT1 pin or any of the PCINT7..0"
Ну, и зачем кнопки по таймеру опрашивать?
Как тут уже заметили, температура - штука достаточно инерционная, поэтому ее вполне можно считывать раз в 10 секунд.
Ну, и, естественно, разрешать прерывания после каждого прочитанного БИТА.
Что касается дисплея, то я статус вообще не опрашиваю, а просто выставляю гарантированную задержку.

Ха! Дак у топикстартера что в прерывании по таймеру творится:

_delay_ms(25); // Пауза на 25 мс Ну, и ктож задержки делает в обработчике прерываний ??????
if (bit_is_clear(PIND,5)) { // Если кнопка PD5 нажат
while (bit_is_clear(PIND,5)); //Ждем отжатия клавиши Еще бы не тормозило !

Сообщение отредактировал _basile - Apr 8 2013, 08:02