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

[aivs]

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

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

[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-ов не напасёшся обычно.