"Читаво" решение в НИКАКЪВ случай не може да съдържа в процедура за обработване на прекъсване задръжка от 2 секунди!

Самия факт че пишеш това изглежда като да не си много на ясно как се реализира обработка в прексъване или просто си правиш вятър.

Що бе, прав си е човекът. Идеята на всяко прекъсване да си свърши работата "на бегом" и да освободи терена. Ако ти си решил да правиш задръжка с някаква стейт-машина, то тя не може да се върти конкретно в това прекъсване, защото то може и да не дойде повече.

Посоката на вятъра като начало е към размислите относно 18F2550 и САМО 31 нива на стека за прекъсване и подпрограми, както и стек фул ресет, а също така как се отразява на WDT ресет в комбинация с фюса WDT1023 при delay_ms(2000).
Не е лошо и да се прочете стр.164 от PCW C мануала относно как компилатора обработва флага на прекъсванията.
Но за тези очевидни проблеми има "извратени решения", които очевидно са в тази част на кода, която не само не е показана, дори е с фюс PROTECT.
А иначе единственото прекъсване за което съм "много наясно" е свързано с контрацепцията.

Бате никой не е казал да се стои в прекъсването, ако той не може да се сети как ще реализира проверката и си предтсавя да чака целия дебонсинг в самото прекъсване явно има съвсем различен проблем, дали дебонсинга ще ми е 20 мС или 20 сек е все тая, пише се по един и същ начин, позлва си с епрекъсване и в прекъсване си макс 2-3 инструкции от смисления код, другото е обработката на самото прекъсване.
Тези 31 нива на стека с доста много, ако успееш да ги запълниш пак не говори много добре за начина на писане и за преценката дали този контролер е за твоето приложение. Как компилатора обработва прекъсването слабо ме вълнува защото има друг фюс който явно или не позлваш или не знаеш, инче на практика е съвсме ясно какво се изпълнява от компилатора при прекъсване, само че освен този фюз за който споменах, има и още един който пък казва какво друго да прави в прекъсването ....ама айде ако искаш попрочети малко CCS и така, да не даваме уроци на хора които очевидно не ги искат.

Ами всъщност потърпевшият вече не се обажда. Най-вероятно възложителят се е отказал от това решение. Защото всъщност въпросът не е "защо прекъсването се садейства само", а "какво трябва да направя, че да не утрепа или осакатя човек". Машина, която тръгва сама е същински кошмар. То и иначе стават сакатлъци, та и това остава - да тръгва двигател по случаен начин. И когато се постави правилният въпрос, се търсят решения на всякакво ниво - организационно, системно, софтуерно, хардуерно. Работата по фронт (прекъсване) е един вид диференцираща верига и тя е шумоподатлива. Трябва да се избягва. Вредна е. Ако правите мигалки, сметалки и тям подобни - може. Ако от устройството зависи човешкото здраве и живот - замислете се как организирате всичко. Няма абсолютна защита от смущения, защото няма граница на смущенията. Ако някой е напротив , нека си отговори на въпроса какво става при електромагнитния импулс от атомна бомба. Може устройството да работи 15 години, на 16-та да се включат 5 контактора едновременно, или в съседство да сложат табло с комутация на 100кVA двигател и прекъсването да сработи своеволно. Натискането на бутон не е събитие, което да изисква бързо от гледна точка на процесора действие. А щом е така, решението с прекъсване е погрешно и вредно.
Знам какво говоря. Сменял съм управление на машини на колеги, които са тръгвали сами. Знам и за хора останали без крайници на машини от познати предприятия, включително и на машини с мое управление - не защото са тръгвали сами, а защото работниците са направили невъзможното , за да се осакатят. Въпреки това след случая , съм измислил, как бих могъл да предотвратя "гениалното" действие на работника и ми е съвестно.

Видно от дадения код е "цикленето" в прекъсване "само" 2 секунди, тъй като не е забранено и в това "кратко" време дойде ново прекъсване ще си влезе за нови 2 сек., като и остатъка от "предишните"... "и так 7 раз" както казал грузинеца.
През това време "господ" ще му нулира WDT.
Не никой, а самият той се е вързал да виси в прекъсването 2000mS.
Аз уроци не смея на никого да давам. Други да водят "дисциплина на програмирането".

п.п С малко четене не става!

Последно по темата:
Какъв дебонс, какви 5 лева?!?
Човека по ПЪРВИЯ фронт смъква в 0 изходите и ВИСВА да чака 2 секунди.
Няма значение на какъв език го е писал, ако ще на ръка да е кодирал двоичен код или да е ползвал който и да е език или компилатор, ако иска и интерпретатор да ползва в паметта алгоритъма не е "читав". Също така няма никакво значение за какъв процесор е компилирано.

Кой изобщо говори за кода на човека, доколкото се сещам аз споменах че прекъсването е читавия начин за обработка на този сигнал, не си спомянм да съм убеждавал някого да чака 2 с в прекъсването,това много пъти е дискутирано. Това че човека чака по 2 сек в прекъсването е софтуерен проблем, който не прави прекъсванетонеподходящ начин за обработка на съответното събитие.
п.с. ако беше прочел поста на човека с проблема щеше да видиш че тия 2 секги е сложил съвсем умишлено за да е сигурен че е влязъл в прексъване,аз предполагам че по принцип там няма никакъв delay когато не дебъгва. Освен това ако си чел поста щеше да разбереш че не става въпрос за постоянно влизане, такова каквото и аз си го представях в началото, а за очевидно переодично влизане,което пък очевидно е хардуерен проблем. Т.е.ак си реши хардуерния проблем и махне тоя delay с дебъг функции не виждам какъв му е проблема.

sthx струва ми се има някаква голяма разлика м-у това за което двамта говорим. работата по фронт няма нищо общо с надеждността и валидностат на сигнала, това е просто вариант да хванеш сигнала. В това отношение най-добра работа върши прекъсване on change, но и с нормалното става когато му мениш фронта на задействане.
Идеята е следната, имаш сигнал, за да си сигурен че е истински искаш да е поне 200 мс. Таймер Х ти прави прекъсване всеки 10 мс. Там освен всичко друго имаш променлива да речем pulse_time, която я инкрементираш с 1 на всяко влизане в прекъсването на таймер X.
Отделно имаш прекъсване по port change, влизаш вътре и проверяваш дали е от пина който следиш, ако е и ако нивото е правилното, т.е. активно ниво ти е високо, и фронта е бил преден нулираш тази променлива pulse_time и сетваш еидн бит button pressed да речем. Ако имаш следващо влизане в прекъсването то ще е по падащ фронт, т.е. или преди да са минали тия 200 ms или след. Ти винаги правиш само едно, щом е е фронта който ти е нужен нулираш puls time и чистиш флага за button pressed.
Сега проверката дали тия 200 ms са минали може да с енаправи на две места. В основния цикъл или в прекъсването на таймера, и в двата случая е няколко инструкции, не отнема много време и може да с еизпълни според нуждата, в прекъсването е по сигурно, ако имаш твърде много .. ама колко много да имаш, вместо 20 да стане 21 ... едва ли ще с еуспиш в подпрограма 10 ms, но ако има таква опасност го правиш в прекъсването, минало ли е времето, и сетнат ли е флага си сетваш флаг за валиден входен сигнал и от там нататък по него правиш каквото искаш.
Ето как изпозлвайки прекъсване на един таймер, който така или иначе сигурно го имаш, и на един вход си проверяваш продължителността на входния импулс, т.е. може да разкараш всякакви смущения идващи случайно, без при това да имаш wail или да полираш вход. Чисто, бързо, лесно ефективно.
Та изобщо не става въпрос да направиш 1 като дойде фронт, просто това е начина по който обработваш събитията за да не се моташ и чакаш напразно.
изписах сигурно 300 думи да обясня 5 реда код ...

.. това пък как и къде се постна ако разбрах ...

Ами с две думи, читав debounce на външни сигнали може да се направи и с прекъсване включително и такова по фронт.
Щото ако това точно(прекъсване по фронт) само определя надеждността и безопасността на устройството то при проектирането му нещо е сбъркано.

Посочената от автора схема - без коментар!

Ами именно, дори бих казал че точно в такива случаи, в които е възможно да се получават смущения, фронта е едно от най-надежните решения, защото в другия случай или влизаш в един цикъл и чакаш или полираш переодично, ама какво е станало между две полирания никой не знае.
А надеждността на едно устройство не се решава нито само със софтуер нито само със хардуер. Голяма част от смущенията ако не и всички могта да бъдат елеминирани хардуерно. Самия дебонсинг в неговия оригинален смисъл е ОК да е софтуерено, но в крайна сметка това не е филтриране на смущение, целта на дебонсинга е да елиминираш трептенето в контакта дали на бутон или реле няма значение. Там дори много повече е възможно да не се използва прекъсване, тъй като събитието е ясно както и възможния проблем, и дори ибез прекъсване при читаво написана програма може да се напише сравнително ефективен /от към изпозлван ресурс/ дебонсинг. Лично според мен ако на мястото на процесора сложиш ТТЛ логика и в този си вид схемата не работи щото видиш ли имало смущения е неработеща схема с и без процесор, и си иска оптимизация.
Това което забелязвам е че все повече и повече хората разчитат на софтуерни филтри и изобщо на софтуерно решение на хардуерни проблеми, няма линейност, няма проблем, ще го оправим, С/Ш било ниско, няма проблем ще го вдигнем и какво ли не ... да има случаи в които прилагането на софтуерен алгоритъм е не само желателно но и задължително, но това не се прави за закърпване на калпав хардуер.

RC филтър с времеконстанта 20ms, след него тригер на Шмит, оттам в GPIO. В основния си цикъл ( дано не ми се наложи да обяснявам що е то ) програмата полира сигнала през 10ms и ако открие 5 последователни състояния "натиснато", приема, че е натиснато. Ако след това открие 5 последователни "отпуснато", приема, че е отпуснато. При всички останали случаи не променя състоянието. Начална стойност "отпуснато".
Много ли е трудно ???

Ами този въпрос може да се зададе за всеки от близо дузината начина за дебоунсване - "Много ли е трудно?".
Тука последно ставаше въпрос за това дали може да се направи надеждно дебоунсване с прекъсване по фронт. Не толкова как точно да се направи дебоунсване въобще.

Aми всъщност това дето Тони го предлага не е точно сработване по фронт. Прекъсването само задействува процедурата, а решение се взема след определено време и при условие, че сигналът все още е наличен. Щом има вмъкнато време по някакъв начин в анализа - става.
Само че аз не бих ползвал този метод. Вижда ми се сложно, обработката за един бутон е на няколко места и най-важното - похабява се ресурс (прекъсване) на процесора излишно. Така за истинските важни неща, за които трябва да се реагира бързо, може да се случи така, че обработката да се забави с неопределено време.
Все пак е въпрос на вкус и на разбиране на проблемите...