LPC11xx и обработка прерываний Опции

[deplen]

Код

volatile uint32_t count = 1;
void PIOINT1_IRQHandler(void)
{
    GPIOIntClear( 1, 9 );
    if( count != 7 )
    {
        count++;
    }
    else
    {
        LPC_GPIO0->MASKED_ACCESS[( 1 << 7 )] = ( 0 << 7 );
        count = 1;
    }
}

int main(void) {
    LPC_SYSCON->SYSAHBCLKCTRL |= ( 1 << 6 );
    NVIC_EnableIRQ( EINT1_IRQn );
    LPC_GPIO0->DIR |= ( 1 << 7 );               // настраиваем PIO0.7 на вывод (светодиод LPCXpresso)
    GPIOSetDir( 1, 9, 0 );

    GPIOSetInterrupt( 1, 9, 0, 0, 0 );
    GPIOIntEnable( 1, 9 );
}

Есть вот такой код обработки прерывания. Суть его такая: при запуске горит светодоид, но при 7 разовом нажатии на кнопку светодиод должен погаснуть. Но работает как то странно. То 7 раз нажать на кнопку и гаснет, то 6, то 4, то 3. Вобщем разные цифры.
В чем я ошибся при кодировании прерывания?

[Golikov A.]

надо разделить сложности проектирования и текущую реализацию.


имеем
кнопка подключена к ножке процессора, которая умеет генерить прерывание на изменение фронта этой ножки. Вешаем на эту ножку кнопку, применяем все меры по устранению дребезга на схемотехническом уровне. Теперь вопрос, почему в данной ситуации не использовать прерывание? Чем оно хуже полинга? Зачем в этой ситуации нужен полинг? Какой выигрыш от периодического опроса?

Когда я пишу потенциально - это значит потенциально, а не всегда. пишешь приложение с главным циклом

опрос кнопок
измерение
вывод на экран

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

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

[_Артём_]

Какой выигрыш от периодического опроса?

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

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

Проверяйте состояние входа в функции прерывания таймера.

[Golikov A.]

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


Проверяйте состояние входа в функции прерывания таймера.

про таймер написал чуть ниже, тоже прерывание, только еще и таймер заюзали.

Про то что будет работать для любого входа, аргумент, но есть ли смысл? Если есть устройство, в нем есть прерывание и кнопка, зачем писать так чтобы работало и без этого? На будущее?
Мы решаем эти вопросы во время проектирования, если прерывания выделить невозможно, решается так, если есть порты с прерываниями - сяк. Конкретный прибор - конкретная реализация, переносимость кода и его изменяемость решается на более высоком уровне, на том где уже состояние кнопок получено, а как получается состояние кнопок - это уже конкретный прибор == конкретный способ.