Time_ms - не ти е обвързано със запалването на светодиода. След ресет на 5сек светодиодът ще угасне, даже и да не е запален
Ако на 6 секунда натиснеш бутон той ще светне и няма кой да го угаси.
Нулирането на тая променлива трябва да ти е обвързано със запалването на светодиода.
Натискането на бутона....се детектва с някакъв брояч , например ако 3 пъти поред портът дава натискане - това се приема за натиснат бутон, тогава палиш и нулираш time_ms. Ако броячът расте - поддържаш го на стойност да речем равна на 4.
Светкането и нулирането стават при стойност 3. За отпускането на бутона има 2 тактики - тоя брояч да го нулираш всеки път, когато Readbutton покаже ненатиснат бутон. Другата тактика е да имаш брояч за отпускане - когато 3 пъти поред ти върне ненатиснат бутон - да приемеш че наистина е отпуснат.

Още - 1000херца е излишно за текущата задача,спокойно меже да работи и на 100херца.
time_ms е с излишна разрядност .

Ако трябва да говорим за ефективен код, за конкретната задача на 100 hz ще се събере в char/int ако е да е по-универсално 1 ms и long, някакъв компромис би било 1 ms и short.
Само дето наличието на един long или long long, ти позволява да нямаш никакви други, и всичко да го смяташ с относителни тайм щамп. Да яде повечко ресурс, но е по-универсално.

Леко съм пипна алгоритъма. В прекъсването броячът за включен светодиод намялява. Общо взето е все тая, но при тоя вариант, кодът визуално изглежда по-семпъл. Проверката е

а не

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

да добавя и аз това

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

Това го бях оставил за по-натам - проверка за минимални и максимални стойности.

Да. Иначе ти пишеш като мен , аз много обичам #define щото сега както го е написъл той това PAOUT &= ~(1 << 1); не е никак прегледна програмата ама нека за по-нататък...

За обичане, не го обичам, но прави кодът по-четим. Под четим, имам предвид да си погледнеш кода след няколко месеца, когато детайлите вече са са изпарили от главата, и с умерени усилия да можеш да разбереш какво си правил.
Отделно, a = 1, b = 22 не е много информативно. За момента, при тоя елементарен код става, но като набъбне или след време, ще има едно почесване и скролиране в сорса.
В някои отношения е по-лесно и за корекции. Вместо да променяш някоя константа на "Х" места, я променяш в дефиницията. И т.н. Да не пълним темата с банални и известни неща, че профитата ще се отегчат.

Хубаво е, че Славчо и Ицо показаха поредната лоша практика.
Добре е да запомниш, че тая променлива Time_ms, никой и никъде освен в прекъсването не трябва да я пипа.
Именно от тая проста променлива зависи работоспособността на цялата система, а в някои случаи може да зависи и жовота ти - ако примерно правиш управление за гилотина .

Та, скатаваш нейде на дълбоко т'ва чудо Time_ms (да речем в отделен файл и static) и за достъп до него използваш проста READONLY публична функция, примерно:



... без никога да те интересува, каква точна е стойността, дали е била инициализирана с 0, 15, 20 или 5000.....

След което си разписваш една функция, която връща беззнаково разликата между две числа:



... и една, която малко да ти улеснява да ти улеснява живот и прегледността на кода:



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

Ето и прост пример за филтриране на бутон:



Сега вече трябва да си готов за следващото домашно - имплементация на описаното и използване както за бутона, така и за светодиода.

Тук точността на времето се определя от периода 1ms. Колкото по-голяма точност се търси толкова по-малък период трябва. Това е свързано с повече проверки и повече процесроно време. Грубо 200 пъти по-малко се товари процесора ако периода е 200ms. Ако с един таймер се управляват много процеси е оправдано, но ако имам само една мигалка, може да назнача специално за нея отделен таймер и да освободя ресурс на процесора. Зависи от задачата.
Ако се търси абсолютна точност, светодиода трябва да се светва в прекъсването и там да се нулира таймера. Също и да се гаси диода там. В твоите работи които ти си правил е подходящо да е по твоя начин, но това не важи съвсем за навсякъде.

Да но обратното не е задължително, т.е.ако не ти трябва точност няма да проверяваш начесто, остава само прекъсването като овърхед.
Наличието на системен таймер какъвтонсе явява този брояч е много полезно в много случаи. Да за 8 битовите системи работата с лонг и ресурсоемка, но в много случаи имаш нужните ресурси.

Ами да речем, че ми трябва за някакво дистанционно управление, точност 100 или 10us. Няма да слагам STM32Fнещо си да прави 100 000 проверки/сек, ами ще сложа някой PIC и ще му пожертвам таймера. Те някои с 8 крака имат и по 6 таймера. Ако чудото прави и други неща има още 5 таймера. Процесора може да се пусне на ниска честота, щото няма работа и да не арчи много ток.

Да, така е, за някои специфични задачи ти трябва и отделен таймер или периферия, но това не обезмисля системния таймер. Тук не се опитваме да намерим случаи в които този подход е неработещ, а обратното, имаме случай в който е приложим, с едапроменлива в таймера си решаваш и дебоунса, и времето на светодиоди и още куп времена които обикновено се появяват, вкл.и таймоути на така популярния while...

Славчо, те таймерите не са жертви, те са за да се ползват. Аз далеч не ползвам само един таймер и само едно прекъсване, също така пиша и по 10-20 реда в прекъсвания. Но ако не можеш да вкараш нещата, които Тони посочи в един, и не по първоначално описания начин, значи има много жертви и най-вероятно жертва ще е цялото устройство.
Естествено, когатов дивайса имаш ... фазово управление, енкодер или пък термален принтер, ще има още няколко таймера и прекъсвания в действие. Само трябва да се подхожда към нещата с уважение и мисъл.

Иначе стигаме до следните ситуации:

Преди десетина години, в една най-големите БГ фирми с ембедед ми дадоха върху устройство на колега да добавя външен модул на софтуерно I2C. Друг колега каза, че имал написан модул и ми го даде. Сложих го аз, устройството се обади. Реших да тествам поведението като го откача и целия дивайс заби. Гледам.... I2C-то изцяло блокинг, цикли в един while() и толкоз.... Викам, колега, що така? А той: ААА, то мен Whatchdog-а ме изкарва, не се бърка....

Или пък.... GPS тракер, който трябваше пак да поправям... Сигналът от заплаването се чете в прекъсване от таймер на 10мс. После стойността се проверява на няколко места в основния цикъл и се изпълнява каквото трябва. В крайна сметка се получава, че когато прекъсването дойде между 2 проверки, част от нещата се пресмятат със 0, другите с 1.... Всеки би трябвало да се сети какво настъпва след това....

Поне за мен, няма нищо учудващо в това. Занимавам се с тия неща повече като хоби, при това относително отскоро. Донякъде се занимавам и от принуда де, че ми писна да се моля на тоя и ония да ми драсне някоя мигалка. Печените са заети, и не им се занимава. С другите пък на ме не ми се занимава.

Известно време се въздържах да се включа в темата с конкретика, тъй като и аз имам да уча още много. Но тъй като и профитата не се включиха, сметнах че по-добре питащият да дръпне леко напред, макар и решението да не е перфектно, отколкото да тъпче на едно място.

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

Хич да не ти пука.
Мен така ме скастриха веднъж...още ми държи.
Ама по-подреден май не можах да стана, опитвам се де.