Форум РадиоКот

[uquote="НиколасПэЛ",url="/forum/viewtopic.php?p=3241748#p3241748"]не поможете мне разобраться в регистрах[/uquote]
по просьбе в личке, для разбора в регистрах, 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(;;)
	{
	}
}

[uquote="НиколасПэЛ",url="/forum/viewtopic.php?p=3241748#p3241748"]Добрый день, не поможете мне разобраться в регистрах. Пытаюсь сделать импульсы на atmel328. Нужно два канала, на которых будут импульсы длительностью 10 мкс и паузой между ними 30 мкс. Импульсы одинаковые, только на втором канале есть задержка от первого канала. На 5-10 мкс по заднему фронту от первого канала.[/uquote]
Нужен код вашей программы.

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

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

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

[uquote="NebelWefer",url="/forum/viewtopic.php?p=3277174#p3277174"]Товарищи, подскажите как вы относитесь к конструкциям вида: если по какой-то причине флаг не поднимется, то вся программа повиснет навсегда.
стоит ли вводить выход после некой задержки?[/uquote]
а по какой причине он может не подняться? я так предполагаю, что не подняться он может при аппаратной неисправности I2C. вопрос: если ваше устройство завязано на эту шину, надо ли волноваться, что все зависло, если шина не работоспособна? ведь нет никакой разницы, по какой причине ваше устройство перестало работать: зависла программа в бесконечном цикле, ударила в устройство молния или упал на него кирпич... не работает - и точка. согласитесь, что предусматривать все варианты неисправностей для их обхода - это паранойя.

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

Demiurg писал(а):Если прибор не критичен, то можно и забить. Тем более, если на I2C шине одно устройство висит. Если программа зависла, то понятно почему.

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

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

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

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

[uquote="NebelWefer",url="/forum/viewtopic.php?p=3277249#p3277249"]в данном случае просто читаю время с ds1307 и, иногда зависает, я так понимаю, просто висит бесконечно. Иногда может час проработать, иногда 5 сек[/uquote]
то есть вы считаете, что избавившись от зависания "программно" (т.е. не устраните причину, а просто научитесь её обходить), вы сделаете лучше? тот факт, что доверять "показаниям" таких часов нельзя, вас не смущает, как я понимаю?

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

Demiurg писал(а):у прибора на дисплей выводится соответствующая ошибка.

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

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

Demiurg писал(а):Вы не смотрите однобоко...

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

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

Demiurg писал(а):Если выскочила ошибка "ERRORx", что означает, что пропала связь с клавиатурой, то сразу понятно, что с прибором.

и что? что должен сделать потребитель вашего промприбора? вот вижу я BSOD - и толку? или вижу, что "программа выполнила недопустимую операцию и будет закрыта" - что с того, как это мне облегчает жизнь?!

Demiurg писал(а):Это может быть единичная ошибка, перезапустили прибор, поехали дальше.

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

Demiurg писал(а):Хотя бы уже сразу понятно, что прибор сломан

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

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

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

ARV писал(а):...

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

NebelWefer писал(а):я считаю, что споткнувшись в одном месте программа не должна валиться вся.

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

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

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

[uquote="ARV",url="/forum/viewtopic.php?p=3277355#p3277355"]я вам приводил пример с BSOD - никому никогда ничего он не помог понять.[/uquote]
Слово "никогда" имеет волшебное свойство привлекать множество реальных очевидцев "невероятного". Прочитать код с BSOD экрана и забить его в гугл - и, как правило, где-то когда-то кто-то уже терзал коллективный разум аналогичным вопросом.
[uquote="ARV",url="/forum/viewtopic.php?p=3277355#p3277355"]потребителю ПРОМЫШЛЕННОГО устройства достаточно знать, что прибор неисправен - этот вариант я уже рассматривал. больше ничего ему знать не надо.[/uquote]
Сервисмены будут в восторге от такого подхода. И счастливы иметь добровольного терпилу, на которого можно смело вешать все рекламации. :-D

Добавлено after 32 minutes 13 seconds:
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3277412#p3277412"]Если у Вас стабильно возникают проблемы по И2С, программный обход проблемы называется "костыль"[/uquote]
Не обход но обработка ошибок. Избыточно в конечном изделии, но желательно в процессе разработки и тестирования. На этом этапе чем больше кодов ошибок выдаёт система - тем быстрее локализуется потенциальная проблема. Изделие, способное сказать "Datchik kaputt" куда как приятнее в общении чем то, что только и может бесконечно зад известному сторожевому псу подставлять для покуса́ния (резета).

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

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