шар настроения

VoviK110494

Может кто поможет? Собрал шар настроения на mega48, но по истечению 5 часов работы он зависает на фиолетовом цвете, что может это быть?

Реклама

vem566

Телепатов на форуме нет. Схему, исходник.

Реклама

VoviK110494

НО Я СОБРАЛ БЕЗ ТРАНЗИСТОРОВ, НЕ ВИЖУ СМЫСЛА СТАВИТЬ

ахренолог

Как то шар не прибавил настроения , 5 часов для какой либо циклической прогаммы срок огромный , питание проверьте - думаю в нём беда .

Реклама

vem566

ахренолог писал(а):5 часов для какой либо циклической прогаммы срок огромный

Это как? А как месяцами и годами работают часы? А почему у меня две недели к ряду работала такая же мутота, только в ленте, по окну, в новый год? А вот про питание - в точку.

Реклама

Alkul

ахренолог писал(а):5 часов для какой либо циклической прогаммы срок огромный

Да Вы шутник, как я погляжу

Реклама

Николай_С

Как вариант, при зависании программы делайте аппаратный ресет.

Alkul

vem566 писал(а):А вот про питание - в точку.

Конечно. Во-первых, схема кастрирована "по самое не балуйся".
Про питание вообще ничего не ясно. Есть ли там стабилизатор, есть ли блокировочные конденсаторы.
И еще очень важно - вывод AVCC обязательно нужно подключать к плюсу питания. Вне зависимости от того, используется ли встроенный АЦП. Разница только в том, что если АЦП не используется, то AVCC просто подключают к +5В, а если АЦП используется - то с применением LC-цепи, как показано в даташите.

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

Автор, Вам уже сказали, что телепатов тут нет. Или давайте полную схему и исходник, или пробуйте решить свои проблемы самостоятельно.

Николай_С писал(а):Как вариант, при зависании программы делайте аппаратный ресет.

Такие "костыли" требуются только неграмотно написанной программе. Корректно написанная программа обязана сама "уметь" выходить из "зависаний" без всяких ресетов. А самое лучшее - это даже не "уметь выходить", самое лучшее, когда программа так спроектирована, что физически не способна зависать. А на крайний случай есть Watchdog.

ахренолог

Alkul писал(а):
ахренолог писал(а):5 часов для какой либо циклической прогаммы срок огромный
Да Вы шутник, как я погляжу

Не без того , но когда мне говорят что котёл работает днём без проблем , а в 3 часа ночи блокируется - я ищу внешнее воздействие , а не ковыряюсь в схеме , логичность поломки ищу .... есть такой котелок Сеньор Дювал , так он нехороший такой через оптопару считает частоту сети , и ему не нравятся короткие выбросы добавляющие ещё 50 Гц к существующим , и только осциллографом и именно в это время удалось зафиксировать косяк .

Alkul

ахренолог писал(а):он нехороший такой через оптопару считает частоту сети , и ему не нравятся короткие выбросы добавляющие ещё 50 Гц к существующим

То есть, дело не в долгой работе цикличной программы (кстати, все реальные, а не учебно-тестовые программы именно цикличные), а в том, что:
1. программа не умеет корректно выходить из нестандартной ситуации (то есть, криво написана)
2. схемотехника автоматики котла тоже "не блещет" надежностью

Вот Вам и причины. Сама идея долгой работы цикличной программы тут совершенно не причем. Как говорится, делайте правильно схему и корректно пишите программу

da-nie

Такие "костыли" требуются только неграмотно написанной программе. Корректно написанная программа обязана сама "уметь" выходить из "зависаний" без всяких ресетов.

К сожалению, это верно только для простых программ. Есть ситуации очень сложного ПО, произвести полный анализ функционирования которого крайне сложно. А ещё есть условия космоса, где частица может нарушить работу программы, изменив в том числе значения переменных (такую фишку я некогда наблюдал, сопровождая в ЦУП'е спутник на довольно высоких орбитах - в ПО нашего блока никаких защит, указанных ниже, не было сделано плюс на нас пожадничали хорошего защитного кожуха - зависали регулярно и с непредсказуемыми результатами). В такое ПО и рекомендуется встраивать сброс.

Понятно, что лучше создавать правильные независающие алгоритмы и описывать их правильными независающими программами, но, к сожалению, часто даже в отлаженной и переотлаженной программе могут скрываться ошибки, которые при определенном стечении обстоятельств приведут к зависанию. Вдобавок можно сказать, что сложные программы с большим количеством состояний и параллельных процессов бывает сложно отладить и протестировать полностью. Полное тестирование таких программ может затянуться на время, превышающее экономически целесообразные сроки выпуска устройства. В таких случаях приходится идти на некий компромисс между полнотой теста и сроками выпуска, т.е. программа может выйти, грубо говоря, недоотлаженной. Это не значит, что она будет сбоить на каждом шагу и выдавать какие-то результаты, не соответствующие спецификации. Это значит, что при определенных условиях (чаще при совокупности внештатных ситуаций) возможно неадекватное поведение программы. И здесь нас может выручить сторожевой таймер, который не даст программе зависнуть наглухо. Конечно, он не является панацеей от неправильно составленного или неправильно запрограммированного алгоритма. Он всего лишь перезапустит программу, но не исправит допущенной ошибки. Тем не менее, с ним, по крайней мере, есть возможность восстановить работоспособность устройства.

"Как писать программы без ошибок" Виктор Тимофеев.

В системах с повышенными требованиями по надежности программа должна иметь механизмы контроля правильности работы. Т.е. следить за стеком, за порядком действий, временами выполнения отдельных узлов, настройками периферийных модулей и т.д. При обнаружении отклонений, которые не могут быть исправлены на лету (например, замечено, что в функцию попали не через вызов CALL, а каким-то другим путем), единственный выход – это сброс

А самое лучшее - это даже не "уметь выходить", самое лучшее, когда программа так спроектирована, что физически не способна зависать. А на крайний случай есть Watchdog.

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

pyzhman

А у меня первой мыслью - авторская пробка, намеренная или случайная.

Alkul

da-nie писал(а):К сожалению, это верно только для простых программ.

Что, по-Вашему, есть "простая" и "сложная" программа?

da-nie писал(а):Есть ситуации очень сложного ПО, произвести полный анализ функционирования которого крайне сложно.

Мы о микроконтроллере говорим? Или о чем? Мне приходилось писать на ассемблере программы, еле-еле втискивающиеся в 16 КБ флеша AVR-контроллера. Исходник программы - это десятки страниц. И анализ функционирования прекрасно делается. Не быстро, конечно.

da-nie писал(а):А ещё есть условия космоса, где частица может нарушить работу программы, изменив в том числе значения переменных

Я где-то сказал, что Watchdog вреден? Я сказал, что он "на крайний случай".
Для описанный Вами условий существуют радиационно-стойкие ИМС с приемками "5" и "9". В которых нет никакой флеш-памяти программ, только внешняя ОТР-память. Ну, и сами микросхемы более устойчивы к ионизирующим излучениям.

например, замечено, что в функцию попали не через вызов CALL, а каким-то другим путем), единственный выход – это сброс

Как же Вы в общем случае собираетесь программно же определять, что "в функцию попали не через вызов CALL, а каким-то другим путем"?
Это уже не программный, а аппаратный сбой. Как определить точку входа в подпрограмму? Стек анализировать, какой адрес туда поместили, какой оттуда сняли? Это, быть может, и возможно для простейших программ, в которых вызов конкретной подпрограммы всегда осуществляется из одного конкретного места, но когда речь заходит о программном контроле аппаратной части, которая может быть подвержена сбоям неизвестной заранее природы - извините, ни о каком контроле не может быть и речи.
Самый простой пример - контроль целостности программы при её запуске. Делается элементарно - подсчитывается CRC для программного блока целиком и сравнивается с контрольным значением. Казалось бы, все верно. Но если гипотетически возможна порча памяти программ, то где гарантия, что не произойдет порча как раз той части программы, которая отвечает за проверку? И, если уж на то пошло, то Watchdog тоже требуется инициализировать. Сбой памяти программ может возникнуть как раз в кодах инициализации сторожевого таймера. Делать проверку этой инициализации? А потом проверку проверки?
Quis custodiet ipsos custodes? - Кто устережет самих сторожей?

Другими словами. Изделия для экстремальных условий работы должны быть адаптированы для этих условий не только в части программных защит, но и в устойчивости (насколько это возможно) аппаратной части микросхем к этим условиям.

Вы, видимо, утеряли нить темы. Перечитайте, с чего началось обсуждение устойчивости программ. Разве с космоса? Была высказана общая фраза, что циклические программы в принципе не могут долго работать.

ахренолог

Alkul писал(а):[quote="ахренолог"
То есть, дело не в долгой работе цикличной программы (кстати, все реальные, а не учебно-тестовые программы именно цикличные), а в том, что:
1. программа не умеет корректно выходить из нестандартной ситуации (то есть, криво написана)

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

da-nie

Что, по-Вашему, есть "простая" и "сложная" программа?

Не будем лезть в демагогию.

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

Мы о микроконтроллере говорим? Или о чем? Мне приходилось писать на ассемблере программы, еле-еле втискивающиеся в 16 КБ флеша AVR-контроллера. Исходник программы - это десятки страниц. И анализ функционирования прекрасно делается. Не быстро, конечно.

Мы говорим о микроконтроллере. Они бывают не только AVR, а программы бывают сложными комплексами управления оборудованием с большим количеством состояний и условий "если А ведёт себя так, то скорректировать Б и на следующем такте провести коррекцию С, при этом А должно улучшаться, а если это не так, то изменить параметр Д." - и таких условий может быть очень много - у автомата программы очень большой граф состояний.
К примеру, сейчас для нас сделали систему на базе отечественного микроконтроллера (аналога TMS), с подключёнными к нему 512 КБайт ОЗУ и 8 МБайт флэшки. И поверьте, программа, которой вот это всё требуется простой точно не будет. И слава Богу, что вот её писать не мне.

Я где-то сказал, что Watchdog вреден? Я сказал, что он "на крайний случай".

Вы сказали "Такие "костыли" требуются только неграмотно написанной программе. ". Так вот, это не костыль, а способ снизить вероятность сбоя.

существуют радиационно-стойкие ИМС с приемками "5" и "9".

Я в курсе. Но уверяю вас, сами по себе они вас не спасут.
И приёмка 5 в космосе (и на земле на объектах в условиях возможного ионизирующего излучения) не применяется без крайней необходимости, ибо радиационно-стойкой не является.
И ещё у контроллеров есть ОЗУ (как и радиационно-стойкие флэшки тоже есть), так что повреждения информации будут.

Как же Вы в общем случае собираетесь программно же определять, что "в функцию попали не через вызов CALL, а каким-то другим путем"?

Скажем, используя взвод какого-либо флага перед вызовом любой функции и его сбросом в самой функции с проверкой, а был ли взведён флаг.

Это уже не программный, а аппаратный сбой.

Это может быть и программный сбой, если программа случайно затёрла, скажем, стек и вернулась по адресу со стека.

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

Вообще-то, речь о контроле идти может. Задача программы минимизировать сбои, и этого она достигнет в любом случае. Сбой неизвестной природы приведёт к перезапуску в любом случае (если контроллер зависнет, он будет сброшен по строжевому таймеру, если же контроллер не завис, то работает контроль данных в самой программе с выполнением сброса, если он нужен).

то где гарантия, что не произойдет порча как раз той части программы, которая отвечает за проверку?

Ещё раз повторю, задача программы минимизировать вероятность сбоя, а не работать 100% безошибочно.

Quis custodiet ipsos custodes? - Кто устережет самих сторожей?

Отучайтесь играть в демагогию. Есть чёткие цели и методы их достижений. Цель - минимизация сбоя. Метод приближения к ней описан у Тимофеева.

Вы, видимо, утеряли нить темы. Перечитайте, с чего началось обсуждение устойчивости программ. Разве с космоса? Была высказана общая фраза, что циклические программы в принципе не могут долго работать.

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

Alkul

da-nie писал(а):
существуют радиационно-стойкие ИМС с приемками "5" и "9".
И приёмка 5 в космосе (и на земле на объектах в условиях возможного ионизирующего излучения) не применяется без крайней необходимости, ибо радиационно-стойкой не является.

Что это, простите, за бред?
Бывают ИМС с приемкой "5", бывают радиационно-стойкие ИМС, а бывают радиационно-стойкие ИМС с приемкой "5" (или "9")
Вот, к примеру, радиационно-стойкие ИМС с приемкой "5". Шифр "АЕЯР" в технических условиях изделий, выпускаемых НИИЭТ'ом, присваивается только изделиям с приемкой "5".

da-nie писал(а):
Как же Вы в общем случае собираетесь программно же определять, что "в функцию попали не через вызов CALL, а каким-то другим путем"?
Скажем, используя взвод какого-либо флага перед вызовом любой функции и его сбросом в самой функции с проверкой, а был ли взведён флаг.

Флаг - это бит байта, расположенного в поле адресов ОЗУ? Которое точно также подвержено сбоям?

В каком месте подпрограммы Вы собираетесь проверять и сбрасывать этот флаг?

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

da-nie писал(а):Это может быть и программный сбой, если программа случайно затёрла, скажем, стек и вернулась по адресу со стека.

Программа случайно затерла?

Смешно. Программа не может ничего делать "случайно". Она делает только то, что написал программист.
Это не программный сбой, это криворукость программиста, неспособного контролировать то, как его программа работает с ОЗУ.

da-nie писал(а):Отучайтесь играть в демагогию. Есть чёткие цели и методы их достижений. Цель - минимизация сбоя. Метод приближения к ней описан у Тимофеева.

Я не знаю, кто из нас играет в демагогию.
Для меня лично тот отрывок из книги Тимофеева, который вы привели - как раз и есть демагогия в чистом виде. Общеизвестные фразы, как говорится, "обо всем и ни о чем".

da-nie писал(а):"Как писать программы без ошибок" Виктор Тимофеев.

Кто может писать программы, тот пишет, а кто не может - тот учит.

da-nie

Что это, простите, за бред?

Да нет, не бред. Просто изделия с 9-й приёмкой, обычно, радиационно-стойкие. А вот с пятой это редкость. Поэтому приёмку 9 часто и называют атомной или космической.

Бывают ИМС с приемкой "5", бывают радиационно-стойкие ИМС, а бывают радиационно-стойкие ИМС с приемкой "5" (или "9")

Да, напрямую не связана радиационно-стойкость с номером приёмки, это так. Редко бывают радиационно-стойкие с приёмкой 5. Всё это отражается в соответствующих ТУ. Поэтому и есть крайние случаи, когда разрешается их применять в случае ионизирующих излучений:

Приёмка «5» – изделия категории качества «ВП», для которых устанавливаемый в конструкторской и технологической документации, стандартах и ТУ уровень требований к надежности и другим эксплуатационным свойствам, а также к обеспечению и контролю качества обуславливает пригодность их применения в наземной, морской и авиационной аппаратуре, отказ которой ведёт к существенным последствиям, ремонт и замена которой ведется на уровне ячеек и блоков.

Приемка «9» – изделия категории качества «ОС» для которых устанавливаемый в конструкторской и технологической документации, стандартах и ТУ уровень требований к надежности и другим эксплуатационным свойствам, а также к обеспечению и контролю качества обуславливает пригодность их применения в аппаратуре космической и ракетной техники, специальной правительственной связи и др. отказ которой ведет к катастрофическим последствиям, ремонт и замена которых труднодоступны или не возможны.

Шифр "АЕЯР" в технических условиях изделий, выпускаемых НИИЭТ'ом, присваивается только изделиям с приемкой "5".

Шифр АЕЯР никакой приёмки не означает, а означает код предприятия-разработчика. Дальше идёт номер по классификатору ЕСКД и порядковый номер изделия. Так вот, если в НИИЭТ есть ТУ с каким-то номером, где указаны свойства изделия, то децимальный номер с АЕЯР и цифрами этого ТУ и будет означать требуемое ТУ.

Программа случайно затерла? Смешно. Программа не может ничего делать "случайно". Она делает только то, что написал программист.

А, ну понятно.

Вот такое вот передёргивание, вместе с попыткой огрызаться по типу "сам дурак" как раз и есть симптом, что оппонент неадекватен.

Такое простительно школьнику и студенту младших курсов, но в вашем возрасте следует иметь больший опыт оценочных суждений того, что именно вам говорят. Вы вот прочли, о чём я вам тут толкую? Зависание программ - это объективная реальность и не зависит от "криворукости" программиста. Современное ПО очень сложно и гарантированно имеет множество ошибок. Процессор тоже имеет ошибки - он очень сложен, и далеко не все из них выявлены и отражены в errat'е.

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

Ещё раз повторю, речь идёт о минимизации вероятности сбоя. Если уж на то пошло, в ОЗУ процессора тоже есть резервирование ячеек и схема мажорирования. И может, подчёркиваю, может быть повреждена (дать сбой) схема мажорирования. Но это не повод от неё отказываться.

Для меня лично тот отрывок из книги Тимофеева, который вы привели - как раз и есть демагогия в чистом виде. Общеизвестные фразы, как говорится, "обо всем и ни о чем".

Кто может писать программы, тот пишет, а кто не может - тот учит.

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

как писать программы без ошибок.rar: (347.79 КБ) 129 скачиваний

pyzhman

Господа! Время суббота. Может по пиву?

da-nie

Может по пиву?

Да Бога ради.

Я ж не против.

Alkul

da-nie писал(а):Шифр АЕЯР никакой приёмки не означает, а означает код предприятия-разработчика. Дальше идёт номер по классификатору ЕСКД и порядковый номер изделия.

Это Вы рассказываете мне? Я это прекрасно знаю. А вот Вы, видимо, информированы не вполне.
Вот Вам пример - каталог Воронежского завода полупроводниковых приборов. Там есть изделия, выпускаемые по старым ТУ с трехзначным цифро-буквенным индексом, а есть изделия, выпускаемые по новым ТУ с 4-х буквенным индексом. Обратите внимание, что изделия общепромышленного назначения (с приемкой "1") у них идут под кодом АДБК, а изделия специального назначения - под кодом АЕЯР. В данном случае, скорее всего, у НИИЭТ и у ВЗПП один код для "военных" разработок. Возможно, что НИИЭТ выполняет роль конструкторского бюро для ВЗПП, это неважно. Тот, кто работал с воронежцами, тот знает, что под кодом АЕЯР они выпускают только продукцию с приемкой "5". Обратите внимание, что технические описания (необязательный документ) у НИИЭТ идут под кодом КФДЛ. С чего бы это?
Так что не надо пытаться уличать меня в незнании.

da-nie писал(а):Современное ПО очень сложно и гарантированно имеет множество ошибок.

С этим кто-то спорит? Для этого люди придумали тестирование во всех режимах работы. Вы военпреду хоть раз сдавали изделие?
Попробовал бы я своему военпреду заявить эту фразу

da-nie писал(а): Огласите, пожалуйста, если пожелаете, список вашего творчества.

Боюсь, что у Вас формы допуска нет.

pyzhman писал(а):Может по пиву?

От пива, говорят, брюхо растет