Въпрос за 1М лева...

Гледал ли си какво става по захранването с осцилоскоп?

Отговор за 100к - не е.

E , то и на снимките се вижда - помагаш на проца. Закачи захранването от програматора някъде далече от проца...за достоверен коментар

Може да е софтуерен бъг, може да се скапва осилатора на проца, а WDT си има отделен осцилатор май.

Абе, не го умувай. Остави за следващия път. Щом си го подкарал, почерпи се една бира и давай нататък.

Захранването от Пиккит е малко странно - DС -DС обаче с управление от контролера. Така че има голям шанс точно заради това да работи по някаква случайност. С осцилоскоп на захранването може и нищо да не се види.

таз платка схема има ли
и двете Vdd/Vss ли са вързани

Е , и да има схема - какво - кое е реалността? Платката или схемата?

Май проблема не беше в пик-а, а в ацп-тата. Пращам по два байта от АЦП. Винаги увисваше на четен байт, но не на един и същ. Предполагам че някое но не едно и също АЦП забиваше и не сетваше реди бита. Пик-а чете в цикъл докато види реди, после прочита стойността от дата регистъра и я праща по уарта. Като увисне АЦП-то, пик-а цикли докато не го ресетне вачдог-а. При ресет на пик-а, във фирмуера има ресет на АЦП-тата, после зареждане на регистрите и отново чакане на реди и четене.
Около ПИК не съм пипал нищо, седи си със 100nF кондензаторче и толкова.
Работи вече над 8 часа захранено с 5 волтов адаптер. Единствената промяна от началното положение са допълнителните жици между цифровата маса на АЦП-тата и точката където подавам захранването. Започва да ме гложди въпроса дали няма дефектна писта някъде по масата, но тя е дебела 2 мм, все щях да видя ако е скъсана/спукана. Не ми се играе да разпоявам едно по едно кабелчетата да тествам тази теория.

Гледах с осцилоскоп, разбира се. Няма качествена разлика между всички захранвания.

Има схема, ама за какво е, тя схемата си е вярна, кое как е опроводено е друг въпрос

И двете двойки Vdd Vss на ПИК-а са вързани, разбира се.

Ако от самото начало не работеше на никое захранване, щях да тръгна да търся причините. Ама с това държание, на едното захранване работи, на други 4 не иска направо ми разказа играта. Ако до тогава се държи стабилно, в понеделник го затварям и му връзвам датчици да видим какво ще стане.

Aaaaaa това вече звучи много логично, тая теза мога да я приема
Значи такъв код се не пише, винаги трябва да си предвиждаш начин за изход от цикъл, фор-а е ясен на while винаги слагаш таймоут. Отделно ако очакваш по-дълги цикли е добре да си нулираш кучето в цикъла, като цяло кучето не е средство да излизаш от зависнали цикли

Кода е целенасочено така. Мога да нулирам кучето в цикъла, ама не искам. Трябват ми всички 8 ацп-та във всеки момент. Ако едно ацп умре целият експеримент отива по дяволите. Всяко ацп се чете през 20 милисекунди, а кучето е с период 576 милисекунди. И тук нарочно е така, за да се види ясно че са спирали данните.

Правил съм шилд за уно с един 7730 и едно апц220. Храни се от 5-те волта на ардуино, има 3 кондензатора по 100 нФ, един на аналоговата част на ацп-то, един на цифровата и един на апц-то. Храни се от поуър банка. Няколко бройки работят с различни задачи по цехове с кранове, електрожени, неизвестно количество електродвигатели около тях и си работят без грешка. Никой не ги изключва, от време на време някой се обади че не работи и аз ги карам да заредят батерията . Там захранването със сигурност не е по-добро от на тази платка.

Както и да е, сега го погледнах че продължава да работи, явно ще го бъде

Ами аз без да се имам за прогрмаист, чисто функционално такъв код не е ОК, рестартваш се и не знаеш защо, дали е АЦП дали не е .. защо кучето умира .. а тов акоето правиш е преднамерено убийство
Колкото и АЦП-та да имаш, слагаш си в цикъла нещо което да те вади със сигурност, баламския вариант декрементваш някаква променлива като на база честота знеш колко време ти отнема, или пък си имаш таймер който следиш, няма значение, нещо те вади по време ако стоиш твърде дълго, и те вади със съответната грешка, и вместо да забиваш, да те вади куче просто ще ти връща грешка в АЦП.
Аз като цяло съм против всякакви цикли в които чакаш нещо, да ако чакаш 2-3-5 us а една инструкция ти е 400 нс да, това може и да е оптималния вариант, но да имаш процесор на 18 Mhz, демек инструкция 222 нс, и да стоиш и да чакаш някакво АЦП което може да са милисекунди ... някак не ми се връзва с концепцията за ембедед софтуер, аз ембедед софтуера трябва да мога да си го представя реализиран с логически елементи, айде да речем елементи с памет, до там .. това в кръга на шегата ама не съвсем. А пък ако ти се наложи да чакаш нещо задължително си предвиждап някакъв изход различен от куче, кучето те пази да не умреш съвсем, може да те буди ако се приспиваш, да рачиташ че ще те извади от цикъл в който чакаш нещо независещо от теб ...

И двамата сте прави.
Тоя цикъл е недомислен, но ако кучето се нулираше и в цикъла , темата щеше да откара 15 дена. А сега проблемът се локализира в рамките на стандартните 72 часа.

Е ако няма предвиден изход естествено, можеше и 15 години да откара, аз затова първото което писах е да има предвиден изход, а кучето може и да него нулираш, в крайна сметка ако си си гарантирал че няма да стоиш в цикъла безкрайно няма нужда да нулираш куче и там ако се предполага че то няма причина да лае.
Аз принципно кучето гледам да го нулирам само на едно единствено място в кода, освен ако кучето не е много бързо а по някаква причина има моткане нейде.

Е то в общи линии кучето не е да оправя грешки в кода а да събуди контролера ако се очакват проблеми със зависване независещи от софтуера. Те АЦП-тата може и да си работят ок, ама с тия "хвърчащи" жици може и сигнала да се осира докато стигне до пик-а или по някаква причина контролера да го пропуска, ако е за кратко време. Прочети си хубаво даташита на ацп-то (@мухата да ме извинява) ама на Аналог даташитите някой път нещата са написани някъде измежду редовете чети внимателно - този ready сигнал може и да не е постоянен а само за кратко време и да ти се случва точно като четеш пина той вече да не е вдигнат. Такъв тип асинхронни сигнали се четат с прекъсване задължително. Само че тоя контролер не е много подходяш за много асинхронни прекъсвания от този тип. Не че няма толкова входове ама от тия дето ги има може и да не разбереш кой точно ти е вдигнал прекъсването в дадения момент. По спомен имаше само 3 отделени и 1 общо за целия порт Б. Евентуално с гимнастики може да си вкараш и от ЦЦП-тата и от някой друга периферия ама това трябва да се предвиди и на ниво хардуер.

има 4 по промяна б4-б7 и един за външно. АЦП-то му сваля рейди в 0 до де не изчете резултата. Забива всички рейди на външното прекъсване, плюс ги дублира на един от портовете, втория порт му е CS, 3 пина за SPI, един да ги ресети в купом. Вече ако им подава външен клок и ги синква още два пина ...това го виждам реализирано без грам циклене и чакане където и да е. Получава прекъсване, проверява порта на който са всички, записва новопристигналия в опашка, и излиза. В тялото основния цикъл върти проверка за новопристигнали и ако е изчел предходния пуска към spi новия, ако не продължава да си върти. Пак там предава данните или ги обработва ако обработва ...освен основния цикъл други няма, дори стейт машина не е нужна ако се прави само това, буквално 20 реда код.

А да те питам ако беше с акъла от преди 30 години как щеше да го направиш То ясно че това е варианта.

На Каспаров (лека му пръст че го споменавам) колко пъти се опитвах да му обясня каква е концепцията на прекъсването и как става номера и така и не ми се получи.