Цитата(aivs @ Apr 7 2013, 01:15)

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