Size: a a a

2021 August 31

SK

Stas Koynov in Embedded Group
можно конечно, но если будет 10 кнопок?. для этого вполне хватает софтварного таймера. можно смело считать дребезг в мэйне, а прерывание таймера оставить, на скоростные штуки. у меня 80Мгц пик. я делаю SW таймеры от 10мс и выше. диодиками там мигать или дребезг считать...
источник

l

linxuil in Embedded Group
Почему без прерываний?
Смысл кнопку все время опрашиватт?
источник

ED

Electronics Designer in Embedded Group
При семидесяти двух тысячах команд на прерывание можно опрашивать хоть сто кнопок.
источник

l

linxuil in Embedded Group
Можно, но зачем?
источник

ED

Electronics Designer in Embedded Group
Так гораздо удобнее

а) реализовывать антидребезг
б) реализовывать разделение длительности нажатий.
источник

IN

ISAK Neuman in Embedded Group
источник

SK

Stas Koynov in Embedded Group
да можно конечно, но я за минимальный код в прерываниях. а так да, когда жесткий реалтайм и есть сертификация, то там вообще 90% кода только в прерываниях. и рулим приоритетом задачи...
источник

ED

Electronics Designer in Embedded Group
Инкремент и два if'а - это много? :)
источник

SK

Stas Koynov in Embedded Group
ну у нас один товарищ весь протокол модбаса в таймер запихал, для него ваш код фигня... у меня просто cnt++. мыж про то к чему нужно стремиться, а наговнякать всегда успеем.
источник

IN

ISAK Neuman in Embedded Group
Каждые 72 000, прерывание увеличивает глобальный тик на 1 рассчитывая ровно 1мс.

Но если я добавлю внутри этого же прерывания, после 72 000 команд +1 инкримент +опрос состояние всех кнопок, немного же сдвинет точные 72 000 на скажем 72 020 или зависимо что я там делаю.

Стоит ли париться и в LOAD загрузить точное колво тика, компенсируя командами внутри прерывания. Примерно скажем 71 980, чтоб остальные 20 проходили в самом прерввании и получилось ровно 72к
источник

SK

Stas Koynov in Embedded Group
если ресурсы есть, можно хоть как писать, тем более если чуваку на разобраться, то вообще пофиг
источник

l

linxuil in Embedded Group
+
Вот и я о том же. С таким подходом нужно будет определить границу, что для вас много - 10 команд в прерывании левых не много, тысяча вроде тоже не много из 72000, даже 30000 вроде даже не половина...
источник

SK

Stas Koynov in Embedded Group
таймер будет продолжать считать не переживай.. если у тебя камень, который будет ждать сброс флага прерывания, то сбрось его в начале... и не нужно заниматься этой фигней как подсчет команд и т.п...
источник

ED

Electronics Designer in Embedded Group
volatile uint8_t my_button_state;

...

void TIMx_InterruptHandler(void)
{
   static uint32_t my_button_counter=0;

   TIMx->SR = ...;

   if (GPIOx->IDR & MY_BUTTON_BITMASK)
   {
       my_button_counter++;
   }
   else
   {
       if (my_button_counter > SHORT_PRESS_DURATION)
       {
           my_button_state=MY_BUTTON_SHORT_PRESS;
           my_button_counter = 0;
       }

       if (my_button_counter > LONG_PRESS_DURATION)
       {
           my_button_state = MY_BUTTON_LONG_PRESS;
           my_button_counter = 0;
       }
   }
}
источник

IN

ISAK Neuman in Embedded Group
но тогда изначальные 1 мс которые должны были за 72к команд, будет чуть больше 72к команд да? это чисто для теории
источник

ED

Electronics Designer in Embedded Group
Если в прерывании написать больше 72000 команд, то да, будут проблемы.
источник

IN

ISAK Neuman in Embedded Group
команды внутри прерывания же тоже увеличивают общий TCNT ?
источник

ED

Electronics Designer in Embedded Group
Нет.
источник

ED

Electronics Designer in Embedded Group
Таймер считает полностью независимо.
источник

IN

ISAK Neuman in Embedded Group
серьезно? то есть внутри прерывания счетчик останавливается?
источник