|
|
|
|
|
Zandy: Я имел ввиду другое. Мы же теперь можем прекращать "бегущий огонь" в любой момент, если кнопка отпущена, не дожидаясь конца цикла сдвига. Это (+) или (-)? Точно также, не дожидаясь конца пробегания огня, при нажатии второй кнопки, можно сразу зажигать два средних светодиода. Опять же, преимущество это или нет? Предлагаю поначалу максимально придерживаться техзадания. "Бегущий огонь" доводить до конца независимо от положения кнопок. Сколько делать проверок - это на усмотрение программиста. Главное - разобраться, как решается эта задача через прерывания. Кстати, вот ссылка на книгу - Урусов, Сташин, Мологонцева "Проектирование цифровых устройств на МК" - если вдруг у кого её ещё нет.
|
|
|
|
У меня вопрос. Вот вы здесь говорите об освобождении ресурсов МК. Что это значит? Ну и что, что программа исполняется в прерывании. Все равно она занимает место в памяти программ и на ее выполнение все равно расходуется время. Какие ресурсы МК освобождаются?
Праздники, выходные, гости и т. д., никак не дают сосредоточиться на написании программы.  |
|
|
|
Zandy: Какие ресурсы МК освобождаются?
Вычислительные и энергопотребление. Если все необходимые операции делаются по прерываниям, то в основной части программы может выполняться какая-либо другая работа или просто переход в спящий режим. |
|
|
|
Zandy: Праздники, выходные, гости и т. д., никак не дают сосредоточиться Аналогично.
|
|
|
|
Zandy: Какие ресурсы МК освобождаются?
А любые. Проще говоря,-все...
Выводим, на основании проведенных опытов, теперь уже очевидное правило N1:
1. НИКОГДА не делаем длинных задержек в ВИДЕ ПОДПРОГРАММ ЗАДЕРЖКИ. Для этого и существуют прерывания.
Всегда можно спроектировать ПЕРИОД ПРЕРЫВАНИЙ таким образом, чтобы решить ЛЮБЫЕ ЗАДАЧИ создания длительных ЗАДЕРЖЕК чего-либо.
|
|
|
|
Из всякого правила возможны исключения |
|
|
|
Вот выкладываю программу по заданию №3 с применением "антидребезга" в прерываниях "от Петровича" и макросов "от picmaniacа". В симуляторе программа работает, проверял в разных режимах.
В программе установлено время прерывания 20 мсек и количечтво проверок нажатия (отпускания) кнопок равное 5. Эти параметры можно оперативно менять. Все необходимое выведено в "константы" в шапке программы. Можно выставлять любое количество проверок (Np). Время прерывания можно задавать, меняя начальную установку TMR0 (KTMR0), а также меняя 3 младших бита регистра OPTION_REG (Koption). Так что прошу высказываться.
Если здесь будет все правильно, начну делать, как советует
Vlad_Petr: 1. НИКОГДА не делаем длинных задержек в ВИДЕ ПОДПРОГРАММ ЗАДЕРЖКИ. Для этого и существуют прерывания.
Всегда можно спроектировать ПЕРИОД ПРЕРЫВАНИЙ таким образом, чтобы решить ЛЮБЫЕ ЗАДАЧИ создания длительных ЗАДЕРЖЕК чего-либо.
Или в данном случае picmaniac: Из всякого правила возможны исключения наша задача исключение?
Или вообще перейдем к другой задаче? Короче, что делать дальше? 61300.asm |
|
|
|
Щас погляжу...
Исключения возможны:
1. Если это учебная программа - для упрощения.
2. Если больше ничего контроллер делать не должен - то на усмотрение программиста.
3. Если программист считает, что в данном конкретном случае именно подпрограмму задержки лучше применить - то опять же на усмотрение программиста. |
|
|
|
Zandy, программу от 16.08 я просмотрел и в железе проверил. В целом очень даже хорошо на мой взгляд.
Есть пара замечаний.
Во-первых, разрешать прерывания лучше до меток М1, М3. А то получается, что лишний раз выполняем макрокоманду ld, что совершенно не нужно.
Во-вторых, так ли нужны переходы на метки Мет1 и Мет2 в обработчике? Там ведь по одной макрокоманде всего лишь. Не лучше ли вписать эти макрокоманды сразу "по ходу действия", чтоб от лишних переходов избавиться.
Ну и ещё несколько мелких не замечаний, а скорее пожеланий - см. в аттаче. Предлагаю следующий этап - сделать так, чтоб все действия выполнялись только в прерываниях, в т.ч. и "бегущий огонь". Ведь больших вычислительных затрат для этого не надо - зажгли первый светодиод, и ждём себе спокойно - пока определенное число прерываний произойдет. Прошло, допустим 12 прерываний по 20 мс - значит, пора следующий светодиод зажечь, и т.д.
В основной программе по идее останется только инициализация да пустой цикл-заглушка. 61304.asm |
|
|
|
picmaniac: Во-первых, разрешать прерывания лучше до меток М1, М3. А то получается, что лишний раз выполняем макрокоманду ld, что совершенно не нужно.
Во-вторых, так ли нужны переходы на метки Мет1 и Мет2 в обработчике? Там ведь по одной макрокоманде всего лишь. Не лучше ли вписать эти макрокоманды сразу "по ходу действия", чтоб от лишних переходов избавиться.
Я согласен с этими замечаниями. Дело в том, что мои умозаключения тоже были в этом же русле. Но потом решил, что вроде криминала никакого не наблюдается, а команды экономятся, вот и решил оставить эти переходы на метки. Там же еще goto разные. Что касается многократного "разрешения прерывания" в кольце, тоже думал на этот счет, но решил, что "криминала" особого нет, в смысле "кашу маслом не испортишь".
Буду теперь думать, как засунуть всю программу в прерывания. Еще подумал, что такая структура наверное была бы весьма выгодна при выводе на 7-сегментные индикаторы с динамической индикацией. Т. е. всю динамическую индикацию - в прерываниях делать.
|
|
|
|
|