Доброго времени суток. Уже не в первой книге по МК читаю, что сторожевой таймер при отладке желательно отключать, и включать уже только после завершения процесса отладки. А есть знакомый разработчик, который делает с точностью до наоборот, с самого начала отлаживаясь со включенным сторожевым таймером, и утверждая, что так лучше. Так как правильнее ?
WDT - это предохранитель от случайных зависаний, имеющий смысл на готовом устройстве, а не при разработке оного. В процессе написания кода и наладки, когда вставляются/удаляются строки/куски кода, время до сработки таймера может меняться и придётся сдвигать точки сброса. Тогда какой в этом смысл? Написал, отладил, а потом уже активируй и определи точки сброса. Это мое мнение.
_________________ Каждый имеет право на свое личное ошибочное мнение.
У меня было тяжелое детство - я до 14 лет смотрел черно-белый телевизор.
Непонятно о какой отладке вообще идет речь. Потому как в режиме железного дебага вачдог В ПРИНЦИПЕ не может использоваться. Ибо он работает независимо от тактирования контроллера и тупо будет его ресетить на брекпойнтах. Что до использования вачдога в окончательном релизе, то либо оный вачдог использован в алгоритме как неотъемлемая его часть (таймаут), либо он затыкает ошибки этого алгоритма. В доброкачественном коде, при отсутствии необходимости самого алгоритма в вачдоге, этот самый вачдог нахрен не нужен. Более того, попытки заткнуть дыры программы вачдогом могут привести к ДРУГИМ дырам. То есть он не является универсальной таблеткой от багов.
Очень интересно получается. Потому что товарищ тот как раз пользуется "железным" отладчиком. Как у него тогда при включенном ватчдоге контроллер не ресетится я обязательно поинтересуюсь А вообще я пока пользуюсь только отладкой в симуляторе, и в принципе только недавно начал пользоваться ватчдогом в силу простоты своих учебных проектов. И пока делаю это в точности как описал Zhuk72 - сперва пишу ВЕСЬ код, потом вставляю в нужные места сброс ватчдога. Значит пока и дальше буду так делать. Ватчдогом, помимо собственно подстраховки от зависаний, пользуюсь еще и как таймером пробуждения МК из состояния сна.
Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650.
Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель.
самый цимес именно в местах ставки сброса надеюсь, вы делаете это после проверки CRC критичных областей ОЗУ, проверки работы периферии, корректности полученных данных и сигналов на входах и выходах... а не просто в каждом цикле или, тем более, в обработчике таймера.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется... скушно, бабоньки!
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Заголовок сообщения: Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 11:19:18
Собутыльник Кота
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2687 Откуда: г. Чайковский
Рейтинг сообщения:1 Медали: 1
ARV писал(а):
надеюсь, вы делаете это после проверки CRC критичных областей ОЗУ, проверки работы периферии, корректности полученных данных и сигналов на входах и выходах...
Если программа может сама себя корректно проверить, то смысла в WDT нет совсем, разве что его использовать как источник сброса. А вот если МК завис где-то, например из-за сбоя питания или внешней помехи, то WDT может с определенной вероятностью помочь. З.Ы. В некоторых МК WDT может работать в оконном режиме. В таких МК сброс произойдет не только при переполнении счетчика, но при преждевременном сбросе WDT.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
речь ведь о том, когда и где СБРАСЫВАТЬ WDT. например, мы ждем импульса с внешней периферии, опрашивая в цикле пин. условие выхода из цикла - нужный уровень на пине. так вот, было бы грубой ошибкой сбрасывать WDT внутри этого цикла ожидания - так ведь? потому что если это делать, то при проблемах ВНЕ цикла (например, при проблеме в периферии) мы никогда не выйдем из цикла, и при этом WDT не поможет, т.к. сбрасывается нами же. аналогичная проблема со сбросом WDT тупо по прерыванию таймера - где бы и по какой причине не зависла программа, если таймер продолжает работать, мы никогда не "развиснем".
если это понимать - использование WDT становится более осмысленным, но и существенно более сложным.
более-менее правильный алгоритм сброса WDT должен быть таким: периодически следует проверять состояние критических объектов программы и сбрасывать WDT только в том случае, если состояние этих объектов не выходит из разрешенных диапазонов. например, мы рассчитываем, что какое-то прерывание должно срабатывать каждую секунду. в обработчике этого прерывания мы ставим флаг-признак срабатывания, а по таймеру каждые 1,5 секунды этот флаг сбрасываем. при опросе смотрим, меняется ли состояние этого флага? если он всегда имеет одно и то же значение - это очень нехороший признак и лучше WDT не сбрасывать - пусть система ресетнится. а если флаг периодически свое значение меняет, значит, и внешнее прерывание возникает, и таймер не завис - можно WDT и сбросить.
как-то так... пример с флагом не самый удачный, но все-таки суть отражает.
лично мой опыт говорит, что при попытке повысить надежность своей разработки путем использования WDT, многократно возрастает сложность алгоритмов в программе. и порой возникает состояние полной безнадеги, т.к. приходит параноидальное ощущение невозможности предусмотреть контроль всего...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется... скушно, бабоньки!
Заголовок сообщения: Re: Мелкие вопросы по МК и ПЛИС.
Добавлено: Вс янв 29, 2017 12:53:24
Собутыльник Кота
Карма: 29
Рейтинг сообщений: 645
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2687 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
ARV, Вы по-моему не поняли, что я имел сказать. Попробую еще раз.
1. Допустим Ваша программа с определенной периодичностью, по некоторым признакам тестирует себя. Нужен тут WDT как таковой? Нет. Программа определила сама что что-то тут не так и дальше должна повести себя в зависимости от заложенного алгоритма. Конечно в основном это сброс. Сбросить себя можно по разному, можно дернуть себя за Резет, в некоторых случаях можно запустить программу с начала без сброса (хотя я бы не стал так делать), в каких то МК наверное можно вызвать какое-то исключение приводящее к сбросу. Ну или самое простое это сброс по WDT. При том, что генератор WDT до нужного момента и не работать, например в целях энергосбережения.
2. А вот назначение самого WDT - это сброс, если МК не выполнил определенный код в определенное время, т.е. завис. Что это за определенный код, зависит от программы и конечно тут тоже стоит хорошо все обдумать. Само собой тут его генератор обязан быть включенным всегда.
Резюмирую: - п.1 и п.2 разные вещи, но ради одной цели. - п.1 и п.2 могут присутствовать в коде как одновременно, так и только один из них или совсем без них. Например, грамотное использование только WDT тоже дает вероятность восстановления работы, без усложнения и увеличения кода. Т.е. использование WDT не обязывает усложнять алгоритм и тоже может быть полезным. - совсем не обязательно проверять целостность программы перед сбросом WDT (хотя так наверное удобнее), это может проводится в разное время и в разных участках кода.
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Вообще нигде не использую WDT для защиты от зацикливания. Но иногда использую для целей алгоритма. Так в одном из устройств WDT охраняет часы работающие от внешнего часового кварца, где сами часы предназначены для отсчета времени активации устройства. Если какой нибудь злоумышленник пожелает сделать устройство своим, по завершении времени активации устройство перестанет выполнять свои функции.
В этом применении WDT сбрасывается в прерывании по часам (раз в 2 секунды).
digitalWrite слишком долгая, 2 мкС, мне нужно быстрее. на PORTB = (1 << 7); тоже ругается А переходить полностью на правильное программирование я еще не готов, но стремлюсь к этому
Нашёл, gpio_write(read)_bit(GPIOx, pin, value)
_________________ Пробиваюсь в ТОП глупых вопросов))) Всем горячих паяльников и холодных полупроводников
А подскажите новичку, правильно ли сбрасывать WDT в основном цикле. Контроллер ATmega. Устройство - регулятор температуры. Не хотелось бы чтобы при зависании температура вышла за пределы. Устройство хорошо работает и так, но хочется перестраховаться, мало ли какая помеха проскочит.
Как я понимаю, если программа зависает в каком то цикле, основной цикл не срабатывает и соответственно Watchdog не сбрасывается. Почти вся логика программы находится в обработчиках прерываний. В основном цикле только вывод на дисплей. По крайней мере, при тестах, если вставить где то вечный цикл, то происходит бесконечный рестарт МК. Значит все правильно?
А подскажите новичку, правильно ли сбрасывать WDT в основном цикле. Контроллер ATmega. Устройство - регулятор температуры. Не хотелось бы чтобы при зависании температура вышла за пределы.
рекомендованное термореле - неплохой вариант, который спасет, например, при выходе из строя датчика или управляющего нагревателем элемента (реле или тиристор-симистор, или что у вас там). соответственно с той же целью в основном цикле надо не тупо сбрасывать WDT, а сбрасывать посл того, как убедились, что температура на самом деле не ушла за пределы. и добавить аварийную сигнализацию, которая будет "сиренить", если начались сбросы по WDT.
паранойя - этовсёпожирающая страсть начав параноить однажды, уже не остановитесь.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется... скушно, бабоньки!
Кто нибудь пробовал запись в EEPROM настроек по выключению питания? Т. е. чтобы зря не тратить ресурс памяти настраиваемые пользователем параметры устройства хранятся в ОЗУ. При этом МК контролирует наличие напряжения питания. При пропадании питания МК, питаясь зарядом электролита на его ногах, скидывает эти настройки из ОЗУ в EEPROM. Таким образом, запись происходит всего 1 раз при выключении, или не происходит вообще, если ничего не менялось, в то время, как если записывать "в лоб" после каждого нажатия кнопки число записей за "сессию" может достигать десяток раз (например, если постоянно "играться" с пультом либо крутить ручку какого-нибудь регулятора громкости и т. п.). Проблема только в том, что флешка все же довольно долго шьется, а вот момент пропадания питания МК может определить довольно поздно из-за наличия электролитов в БП.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 11
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения