по просьбе в личке, для разбора в регистрах, AvrStudio 4.19 + AVR GCC 4.9.2:

Спойлер

Код:

#include <avr/io.h>
#include <avr/interrupt.h>

volatile unsigned char stage = 0;

ISR(TIMER0_COMPA_vect) 
{
   switch(stage)
   {
      case 0:
      PORTB |= (1<<PORTB0);
        break;
      case 1:
        PORTB &= ~(1<<PORTB0);
        break;
      case 2:
      PORTB |= (1<<PORTB1); 
      break;
      case 3:
      PORTB &= ~(1<<PORTB1);
      break;
      default:
       break;
   }
   if(++stage == 4)
      stage = 0;
}

int main(void)
{
   CLKPR = 0x80;
   CLKPR = 0;
   DDRB |= ((1<<DDB1) | (1<<DDB0));
   //10us
    //Tt0 = 1/(Fcpu/k) = 1/(8000000/1) = 0,000000125s = 0,000125ms
    //n = t/Tto - 1 = 0,010/0,000125 - 1 = 79
   // Set the Timer Mode to CTC
   TCCR0A |= (1<<WGM01);
   TCCR0B |= (1<<CS00);
   OCR0A = 79;
   TIMSK0 |= (1<<OCIE0A);
   //comp. disable
   ACSR |= (1<<ACD);
   sei();
   for(;;)
   {
   }
}

Нужен код вашей программы.

Товарищи, подскажите как вы относитесь к конструкциям вида:


если по какой-то причине флаг не поднимется, то вся программа повиснет навсегда.
стоит ли вводить выход после некой задержки?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

а по какой причине он может не подняться? я так предполагаю, что не подняться он может при аппаратной неисправности I2C. вопрос: если ваше устройство завязано на эту шину, надо ли волноваться, что все зависло, если шина не работоспособна? ведь нет никакой разницы, по какой причине ваше устройство перестало работать: зависла программа в бесконечном цикле, ударила в устройство молния или упал на него кирпич... не работает - и точка. согласитесь, что предусматривать все варианты неисправностей для их обхода - это паранойя.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

В данном случае не паранойя. Если работа не на прерываниях, а по опросу флага, нужно защищаться в таких случаях.
Если прибор не критичен, то можно и забить. Тем более, если на I2C шине одно устройство висит. Если программа зависла, то понятно почему.

если в программе единственное место, где она может зависнуть - да, понятно. а если не одно - не понятно.
можно сделать устройство, которое, как герой-подводник до последней минуты собственной жизни будет сообщать пользователю о том, какие пробоины получены и что еще отказало... но я просто не могу представить себе, когда такое поведение самодельного бытового устройства было бы полезно. вот винда, например, иной раз выдает окошко с сообщением типа "программа такая-то выполнила недопустимую операцию и закрыта" и даже предлагает какие-то подробности. вопрос: когда и кому это помогло? или BSOD - есть ли хоть один простой смертный, который извлек из него какую-то для себя пользу? вроде из благих побуждений сделали все это, а толку - ноль.
так и в этой и других программах: можно предусмотреть всякие варианты, но какая от этого польза? пока устройство в отладке - вы, как разработчик, все равно разберетесь и устраните проблему, а потом, при эксплуатации - какой прок от этого? даже если на шине и2ц не одно устройство - какой толк знать пользователю, какое именно не выставляет бит ACK или NACK (или как их там)? для него это означает только одно "девайс - в топку".

максимум, что я бы посоветовал, это WDT завести. и в случае сброса от WDT выводить (если есть куда) текст "отнесите девайс разработчику для ремонта".

в данном случае просто читаю время с ds1307 и, иногда зависает, я так понимаю, просто висит бесконечно. Иногда может час проработать, иногда 5 сек

Я у себя так сделал.

то есть вы считаете, что избавившись от зависания "программно" (т.е. не устраните причину, а просто научитесь её обходить), вы сделаете лучше? тот факт, что доверять "показаниям" таких часов нельзя, вас не смущает, как я понимаю?

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

например, вы сделали своей бабушке электронную прялку - что она будет делать, увидев "ошибка E8FF" на дисплее?
я ж говорю - максимум, что следует сделать, это завести WDT и при его срабатывании выводить (если есть куда) сообщение "пора в ремонт". все остальное - паранойя

Наверное, прялка бабушке - это самое сложное что вы делали... Речь о пром приборе. Если выскочила ошибка "ERRORx", что означает, что пропала связь с клавиатурой, то сразу понятно, что с прибором. Это может быть единичная ошибка, перезапустили прибор, поехали дальше. Микросхема может окончательно сдохнуть. Хотя бы уже сразу понятно, что прибор сломан, причина такая-то, прибор на ремонт.
Вы не смотрите однобоко...

я смотрю исключительно однобоко.
во-первых, на радиоЛЮБИТЕЛЬСКОМ ресурсе промприборами вряд ли кто занимается. во всяком случае, задавать вопросы ЛЮБИТЕЛЯМ, делая ПРФЕССИОНАЛЬНОЕ изделие - это смешно.
во-вторых, я вам приводил пример с BSOD - никому никогда ничего он не помог понять. потребителю ПРОМЫШЛЕННОГО устройства достаточно знать, что прибор неисправен - этот вариант я уже рассматривал. больше ничего ему знать не надо.

но я не пытаюсь вас обратить в свою веру... можно, я не спорю, делать туеву хучу проверок, дабы "избежать любых проблем", потратить на это всю память, ОЗУ и все быстродействие МК, но все это бессмысленно-беспощадный фанатизм.
и что? что должен сделать потребитель вашего промприбора? вот вижу я BSOD - и толку? или вижу, что "программа выполнила недопустимую операцию и будет закрыта" - что с того, как это мне облегчает жизнь?!
и такие советы вы даете тем, кто применяет ваши приборы? например, управление тормозами - ничего, поехали дальше! подумаешь - связь с педалью пропала, это же единичный (может быть!) случай!
см. выше - WDT и сообщение о том, что прибор пора в ремонт (или в помойку). вот и вся обработка "ошибок". самая надежная, самая лучшая

я считаю, что споткнувшись в одном месте программа не должна валиться вся. Если чтение времени затянулось, то его надо пропустить ( при необходимости вывести ошибку, неважно куда) и продолжить код до следующего вызовы чтения.
WiseLord, благодарю, весьма просто и красиво. Однако в моем случае не помогло, я экспериментировал даже до short и 30000. Основной цикл жив, это да, но вот чтение не восстанавливается больше.
Пока решил проблему перезапуском модуля И2Ц TWEN=0 , TWEN=1 и снова чтение. Перезапуск модуля вроде ничем не грозит?

Если педаль отвалилась - это ваши проблемы. Нечего ее ставить на I2C шину. Ггг.

А если сломался сам МК?

в смысле если сам И2Ц глючит? Тогда пропуск времени будет постоянный и это будет сигналом к проверке/замене. А если совсем весь мк, то это и так будет видно и в любом случае ничего не сделать

В смысле, что любой чип может выйти из строя и вероятность этого весьма трудно просчитать. Возможно что самое больное место окажется сам МК и смысл на нем делать анализ работоспособности всей системы? Если у Вас стабильно возникают проблемы по И2С, программный обход проблемы называется "костыль", это тоже метод, плохой, но метод и все равно "костыль".

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

Сервисмены будут в восторге от такого подхода. И счастливы иметь добровольного терпилу, на которого можно смело вешать все рекламации. :-D

Добавлено after 32 minutes 13 seconds:

Не обход но обработка ошибок. Избыточно в конечном изделии, но желательно в процессе разработки и тестирования. На этом этапе чем больше кодов ошибок выдаёт система - тем быстрее локализуется потенциальная проблема. Изделие, способное сказать "Datchik kaputt" куда как приятнее в общении чем то, что только и может бесконечно зад известному сторожевому псу подставлять для покуса́ния (резета).

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

-"«Умный» выключатель бойлера начал Новый год с того, что внезапно решил развидеть свой сервер. А без связи с сервером «умный» выключатель превращается в бездумную кнопку, теряющую своё основное преимущество: возможность управления из любой точки планеты через Интернет. Что я с ним только ни делал, — он моргает лампочкой «сеть вижу, сервер не нахожу». Вчера, наводя порядок, случайно отключил от него датчик температуры и влажности, и он за десять секунд нашёл сервер. Ещё раз: с подключённым датчиком он видит Интернет, но не видит сервер; стоит отключить датчик, сервер сразу находится. Эффект повторяемый, стабильный, проверено. Но как?!.. Я бы понял, если бы он вообще не видел сеть, — наводки от длинного провода к датчику, или какой-нибудь плохой контакт размыкается при воткнутом штекере. Но невозможность достучаться до сервера при доступном Интернете в зависимости от подключения _пассивного_ устройства — это за гранью моего понимания."
- "блок питания проверь"
- " Встроенный. Это Sonoff TH16, он переводит 220V AC в 3.3V DC сам, в своих потрошках.
И как проблемы с блоком питания могут вызвать нормальный, устойчивый пинг в Гугл, но валящийся доступ к серверу itead.cc?! Тем более что датчик температуры и влажности там на паразитном токе работает?"