Доброго вечера!
Заметил такую особенность: при "небольшом" загрязнении между контактами TX и RX (видимо электрический контакт появился), функция gets() безнадежно зависла. Подумал, что хорошо бы запустить перед началом gets() сторожевой таймер, который сбросит контроллер в случае зависания, мало ли чего. WDT запустил путем записи в его регистр сначала комбинации битов, разрешающих изменение режима WDT, а потом записал нужное значение. Через положеные 8 секунд произошол сброс контроллера. Попробовал остановить WDT путем записи в его регистр 0x00. Но эффекта не последовало, произошел сброс... Что делать?!?

А вы пытались останавить его тоже комбинацией или простой записью?
Может быть так попробовать:

WDTCSR |= (1<<WDCE);
WDTCSR = 0;

или так:

WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = 0;

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

cli();
wdt_reset();
MCUSR &= ~(1<<WDRF);
WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = 0;
sei();

Ну тут уж кажется всё предусмотрено с запасом...

Вы бы лучше подумали - а нужна ли такая "полезная" функция. Которая видимо тупо ждет прихода чего бы то ни было в UDR. Используйте нормальный драйвер работающий по прерываниям.

Так пробовал, непомогло.

А вот следующий вариант выглядит убедительно! Что-то я припоменаю про MCUSR при сбросе бита WDE... Пойду попробую!




Ну дак у меня gets() и находится в блоке обработки прерывания, вызываемого при приеме очередного символа по USART!

INTERRUPT (SIG_USART_RCV)
{
gets();
}...

Или вы имеете ввиду посимвольно считывать строку???

Даже не знаю где здесь указывать на "неправильности"... поэтому текст не сокращаю,
ВСЕ показанные варианты не применимы.... тк принципиально зависят от уровня оптимизации компилятора...
Ну нельзя пользовать |= в ситуации наличии 4 тактов для операции и все тут... ну повторим это в 125раз...

Ой! А как же тогда быть? Использовать простое приравнивание REGISTOR=0x05?

Вот, пожалуйста, результат компиляции на IAR EWAVR:



- между записями в регистр WDTCR только одна лишняя команда. Итого всего 2 такта между операциями записи.
А про оптимизацию вы не совсем правы, когда речь идет о записи в регистры, то компилятор (IAR) никогда не опускает присваивание, даже если оно повторное. И это при любом типе оптимизации - как по размеру, так и по скорости.
Однако не забывайте название темы - сказано, что WatchDog запустить удалось. А, значит, компиляция велась в условиях, когда требование 4-х тактов соблюдалось. Поэтому это условие я не стала особо оговаривать.

Один раз повезло другой нет...
так и рождаются легенды...



Лучше всего заготовьте ВСЕ константы заранее а потом их присваивайте регистрам...



я как раз и не забываю, и volatile у Вашего регистра как раз и заставляет делать много(иногда >4) операций

Длиннее просто невозможно скомпилировать, т.к. операции с константами всегда производятся еще при компиляии, а не в runtime.
Приведенная в моем прошлом посте компиляция одинакова как при отсутствии оптимизации, так и при оптимизации по скорости или размеру. Поскольку из-за примитивности примера ее невозможно оттранслировать ни длиннее, ни короче.



Константы невозможно "приготовить заранее". Если вы намереваетесь поместить их в память, то вытаскивание оттуда обойдется дороже - тогда действительно в 4 такта можно не уложиться. А если положить в регистр, то примерно так оно и получится.

P.S. Мой предыдущий пост, адресованный вам, был мною отредактирован. Ознакомьтесь с ним пожалуйста еще разик.

А что меняет выбор варианта оптимизации? В AVR Studio есть варианты: О0 - Оs. Поисковик ничего не выдал.

Спасибо! Замечание с константами я учту на будущее.

Я Вам и предлагаю положить их(константы) во временные регистры...
Вы очень настойчивая девушка... , хотя наверное это и не плохо... но очень торопитесь...
не спешите в своих суждениях...

Докажите обратное! Приведите результат компиляции этих двух сишных строк, чтобы компилятор допустил больше одной промежуточной инструкции между записями в регистр WDTCR. Условия оптимизации можете выбирать любые.

Все меняет, если хотите работу на С для таких вариантов(4такта на все) то только -Os или -O2 рулит..
Ну и подготовленные заранее константы рулят всегда...



Ксения, я Вам позволю самой воспользоваться поиском, особенно по теме записи в EEPROM, и там Вы найдете
ВСЕ ответы, в том числе и мои...

В данном случае варианты компиляции выражения
WDTCR |= (1<<WDCE) | (1<<WDE);
несущественны, поскольку запись в регистр WDTCR всегда будет ПОСЛЕДНЕЙ инструкцией. А, стало быть, протяжка перед следующей строкой
WDTCR = 0;
зависит исключительно от сложности обнуления регистра. Дольше двух тактов это не затянется при любых способах оптимизации или отсутствия оной.

Давайте Вы уже избавитесь от илюзий и попробуете это сделать совсем без оптимизации..

Именно посимвольно. Данные пришли - только тогда читаем. Ничего не ждем. Ваш же метод - просто ужас. Если строка не придет, а это НОРМАЛЬНАЯ ситуация при работе в реальных условиях, а не у Вас на столе, то контроллер просто повиснет. Предусматривать выход из нормальной ситуаци через сброс по собаке не надо. Плохо это и неправильно. И еще момент - Вы представляете время выполнения этой функции? К примеру при 9600бод и строке символов в 30? А она у Вас внутри обработчика - значит на это время все другие события(прерывания) будут отброшены.
Вот - почитайте - http://ru.wikipedia.org/wiki/Gets

Тут в шапке форума тема - Исходники программ и библиотек. Наверняка там есть нормальный драйвер с кольцевым буфером. Или напишите свой, там работы на пару часов. И не надо отключать ватчдог.

Да, соглашусь со всем! gets() "убъет" кучу времени, да и надежность никакая. Спасибо за рекомендации! А драйвер для считывания строки по одному символу я попробую свой сделать. Хочется разобраться до конца.

Совсем запугали бедного Кулика . Делать так, как он вознамерился - можно! Только никакая gets() тут не нужна, хватай символ из UDR1 - вот и вся процедура получения байта. Обычно, байтики, схваченные в прерывании кладут друг за дружкой в строку до тех пор, пока очередным байтом не окажется "конец строки" (Enter). Этот символ можно в строку не класть, а вместо этого заняться ее анализом и исполнением того, что эта строка означает.

Принцип получения строки по одному символу достаточно прост. А gets() я хотел применить, что бы текст программы сократить. Но после обсуждения понял, что лучше таки по одному символу принимать.
А вот по поводу символа конца строки. передавать его все равно нужно, так что лучше сохранить.

Принимаемая строка - это условность (для универсальности программы). Примимается один символ и в зависимости от его значения принимается решение. А вот передавать по USART нужно строку. Передается она при помощи puts(). Возникает мысль передавать тоже по символу , но как на это среагирует копьютер? Тоже надо драйвер по прерыванию собрать, думаю справлюсь...

По одному символу, как правило, принять решение не удается. Приходится прочесть слово целиком, чтобы понять, что оно означает. И вообще, символ конца строки (Enter) это не просто символ, а символ ПОДТВЕРЖДЕНИЯ того, что бы сказано. До его появления программа не имеет права начать выполнение команды, даже если смысл ее вполне понятен. Например, компьютеру нельзя выполнять "FORMAT C:" , пока не нажат Enter. А вы вознамерились по одному символу принимать решение.



Компьютеру все равно, как было передано - отдельными символами или строкой, поскольку на физическом уровне в обоих случаях прием и передача ведутся по символьно. Точно так же и AVRка получает прерывания (если их разрешить) при поступлении очередного байта, не зная того, gets'ом или getchar'ом отправлялась посылка.

Верно подмечено по поводу enter. Подтверждение переданного байта - это как минимум грамотно. А вот символа мне вполне достаточно для принятия решения (выбрать один из 8 вариантов):

switch ©
{
case 48: mig_led1(); break; //0
case 49: mig_led2(); break; //1
... и т.д.
}
По крайней мере не требуется сравнивать строки! Что сэкономит Flash память.

П.С. Посимвольный прием(передачу) я освоил.

Когда команды примитивные (т.е. без параметров), и их число не превышает 256, то, несомненно, удобнее односимвольная кодировка - тут она самоя короткая. Но как только символов ASCII перестало хватать - приходится использовать слова, а тут уже потребуются какие-то разделители между ними: пробел, табулятор, символ конца строки и т.п.
В этой связи вспоминается фраза на манер японских хайку:
"Кончилось место на Z,
Что же мне делать теперь?
Ведь это последний..."

Вообще то неплохо контролировать правильность посылки. Тем более если команда в один символ. Какой нибудь CRC не помешает. Вот так по чуть чуть добавлять и... получится что то типа modbus

Ну да! Место бывает и заканчивается! Приходиться брать МК "потолще"! )))



Посмотрел про modbus в Википедии. А это интересно! Я новичек в использовании интерфейсов (да и МК тоже )и пока кроме как SPI и RS-232 ничего не использовал. А modbus - это уже что-то! Точнее это уже протокл. Надо познакомится с ним поближе.