Скан-код POWER

[ZMIY]

Дело понемногу продвигается. Написал промежуточную (тестовую) программу распознавания факта нажатия с фильтрацией помех. Но под конец голова была уже ватная, поэтому при опробовании даже не удивился, что не заработало (скорее удивился бы если бы заработало). Лёг спать. На следующий день, начал её переосмысливать и понял, что написал я её в принципе криво, проще новую написать, чем эту до ума доводить. Ну и алгоритм несколько изменил.
И даже полностью есть понимание как её написать.
Но тут вылез один (ага тысячи их были, так что не один, а очередной) подводный камень.
Дело вот в чём. Программа на данной стадии использует два таймера, для разных целей, с разными прерываниями и разными обработчиками. Один таймер используется для алгоритма дешифрации, второй для неотносящегося к нему процесса. И нежелательно, чтобы эти таймеры как-то друг на друга влияли. Даже более того, было бы хорошо, если бы во время обработки одного прерывания, могло бы сработать прерывание от другого таймера (правда если это критично растянет время обработки, то может выйти косяк).
Теперь кусок кода:

ldi r16,0b00000001;Заносим в регистр маску
in r17,TIMSK ;считываем в другой регистр текущие настройки таймеров
or r17,r16 ;ставим нужный бит не изменяя остальных
out TIMSK,r17 ;разрешаем прерывание при переполнении таймера
;(сбрасываем таймер)

Так вот, разрешая прерывание, тем самым сбрасываю таймер. При этом делаю это так чтобы другие биты (в данном случае нужен 0-й и только он) не изменились. А всё потому, что 6-й бит отвечает за другой таймер ! И вроде бы всё нормально... однако терзают меня смутные сомненья. Да конечно, значение бита в конечном итоге не изменится, но ! Но его туда всё равно записываю (хоть и то-же самое). Так вот, вопрос, просто по самому факту записи, другой таймер не сбросится ли ?

PS Речь о ATmega16

PPS Да... простой вопрос, а нафлудил...

[LeonT]

Из моей недавней переписки по аналогичному поводу (ну прям, рояль в кустах):
"Проблемка в том, что работа с таймером внутри прерывания, потребует вложенных прерываний. В данном случае - прерываний от события OCR или от переполнения.
Для этого нужно, чтобы флаг глобального разрешения прерываний (I) был установлен. А ведь он у нас аппаратно сбрасывается при входе в любое прерывание, а восстанавливается только при выходе из него командой RETI.
(кстати, команда RETI отличается от команды RET только воздействием на флаг I, это иногда можно использовать, например если при выходе из прерывания нужно, чтобы в дальнейшем прерывания оставались запрещены)
Так вот, чтобы сделать возможным вложенное прерывание, необходимо после входа в основное прерывание, сначала запретить все остальные прерывания, в их числе и основное, затем восстановить флаг глобального прерывания командой SEI. Соответственно, перед выходом из основного, нужно опять восстановить прежние настройки прерываний.
Это достаточно хлопотно и ПМСМ проще внутри прерываний, вместо таймера использовать простой программный счётчик. Ведь поскольку других прерываний нет (флаг I сброшен) то и нарушить работу счётчика ничто не сможет. Т.е. его стабильность ничем не будет отличаться от стабильности ТС."

По факту записи в TIMSK ничего вроде бы не должно происходить - сброс таймера производится записью нулей в TCNT. А прерывание может возникнуть, если на момент его разрешения через TIMSK, имеем установленным флаг события этого прерывания, и глобального разрешения прерываний.

PS:
ПМСМ приведенный код можно укоротить на одну команду:
in r17,timsk
sbr r17,1
out timsk,r17

PS:
Позвольте уточнить - в процитированном фрагменте, неудачное выражение "программный счётчик" следует понимать как "счётчик, организованный программно". Извиняйте за косноязычие...

[Zorge]

Запись того же значения бита в управляющий регистр, что там и было - никак не влияет ни на одну периферийную железяку AVR-ки.
А вот вложенные прерывания - на архитектуре AVR 8-bit лучше не делать - полностью согласен с LeonT.
Внутри прерываний - только циклы задержки и ничего больше - все равно никто не прервет. Но делать нужно все быстро и коротенько - чтобы ни на кого другого сильно не влиять.

(кстати, команда RETI отличается от команды RET только воздействием на флаг I, это иногда можно использовать, например если при выходе из прерывания нужно, чтобы в дальнейшем прерывания оставались запрещены)

А не наоборот? RETI разрешает прерывания, а RET - флаг прерываний не трогает вообще. Или это и имелось в виду?

[ZMIY]

Всем спасибо. Всё понятно.

ПМСМ приведенный код можно укоротить на одну команду:
in r17,timsk
sbr r17,1
out timsk,r17

Точно. Можно. Это я что-то протупил.
Или так:
in r17,timsk
ori r17,1 ;что кстати одно и тоже, что и sbr
out timsk,r17

Но это вроде только написание короче, по времени выполнения выигрыша не будет.
Или я пихаю эталон в регистр, а затем or или проц, вроде бы сразу or-ит константой, но константа то суть ячейка памяти, т.е. сначала читает память а потом or. Так что в итоге тоже самое получается. Если я конечно всё правильно понимаю

UPD: А не, вру. Будет выигрыш. В регистр то я предварительно тоже константу пихаю ! Т.е. как не крути лишняя операция была.

[LeonT]

лишняя операция была

И лишний регистр использовался.

А не наоборот? RETI разрешает прерывания, а RET - флаг прерываний не трогает вообще. Или это и имелось в виду?

Ну да, это и имелось в виду. Я ж перед этим писал: "флаг глобального разрешения прерываний (I) ... восстанавливается только при выходе ... командой RETI"

[ZMIY]

Кстати. Регистров в Атмеге дофига. Если в какой-то один, не используемый, заранее в этапе инициализации, до старта основной программы положить нужную маску, то потом можно or-ить этим регистром сразу и таким образом экономить один такт процессора

[LeonT]

А так и делается. Например, часто используемые константы удобно хранить в рабочих регистрах (когда в них нет острого дефицита).
Например, если часто приходится останавливать/запускать ТС, я организую в регистрах константы ZERO (0) и TCSTRT (то, что должно содержаться в TCCR для запуска ТС). Тогда остановка или запуск ТС делается единственной командой
OUT TCCR,ZERO или OUT TCCR,TCSTRT
Вообще константа ZERO зело полезна и удобна, ибо позволяет одной командой за один такт, обнулить любой io-регистр (в том числе и таймеры).
Естественно, для констант лучше использовать регистры младшей группы (0-15), поскольку они менее универсальны.

[ZMIY]

Понятно. Примерно так я себе всё это и представлял.
А сколько ещё Америк предстоит открыть, а велосипедов изобрести...

[Zorge]

А еще в младших регистрах хорошо хранить всяческие индексы циклов и адреса массивов (как начальные, так и текущие), когда работаешь с чем-нибудь структурированным.

Я когда в институте AVR-ку изучал - вообще загонял в младшие 16 регистров массив с данными, и работал с ними не через rXX, а через адресацию (благо архитектура такое позволяет) - маленькая ОЗУшка у 90S2313 была уже вся забита другим "нужным" барахлом.

[jamper]

А вот вложенные прерывания - на архитектуре AVR 8-bit лучше не делать - полностью согласен с LeonT.
Внутри прерываний - только циклы задержки и ничего больше - все равно никто не прервет. Но делать нужно все быстро и коротенько - чтобы ни на кого другого сильно не влиять.

Вот это очень спорное высказывание.
Вызов прерываний из другого прерывания допускается в случае крайней необходимости, например в одном прерывании вы выводите значение на индикатор и в это же время приходит импульс формирующий измерительный интервал... Что важнее вывести все цифири до последней или запустить/остановить процесс значение которого потом будем выводить на дисплей?
А вот делать задержки внутри обработчика прерывания есть наипервейшее зло, само название - "прерывание" говорит о том что прерывается основной (читай самый важный) процесс, а вы в нем задержку...
для Змея
1. если буржуйские мануалы плохо курятся купи/скачай книжку А.В.Евстифеева "Микроконтроллеры AVR семейства mega/tiny/classik Руководсво пользователя" это выжатые мануала по разным семействам только на русском
читаешь-уточняешь(на конкретный камень, в буржуйском мануале)-применяешь
2. есть такая прога VMLab 3.15 заточена как раз под АВРки, проста как 7 коп. и позволяет моделировать вх.сигналы.
ИМХО протеус слишком перегружен для любителей.
3. если желаешь и дальше программировать - тогда меняй стиль, использование абсолютных значений и имен регистров по умолчанию прямой путь к запутыванию себя и тех кто потом будет пытаться помогать запустить софтину.

in r17,timsk
sbr r17,1<<TOIE0 ;сразу видно что разрешаем прерывание от Т0 по переполнению
out timsk,r17

ну и R17 заменить на, скажем, temp
ну и т.д. не будем углубляться - это все-таки сайт не про мк

[ZMIY]

Вот это очень спорное высказывание.
Вызов прерываний из другого прерывания допускается в случае крайней необходимости, например в одном прерывании вы выводите значение на индикатор и в это же время приходит импульс формирующий измерительный интервал... Что важнее вывести все цифири до последней или запустить/остановить процесс значение которого потом будем выводить на дисплей?
А вот делать задержки внутри обработчика прерывания есть наипервейшее зло, само название - "прерывание" говорит о том что прерывается основной (читай самый важный) процесс, а вы в нем задержку...

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

для Змея

Для ЗмИя

1. если буржуйские мануалы плохо курятся купи/скачай книжку А.В.Евстифеева "Микроконтроллеры AVR семейства mega/tiny/classik Руководсво пользователя" это выжатые мануала по разным семействам только на русском
читаешь-уточняешь(на конкретный камень, в буржуйском мануале)-применяешь

Эх. Да сколько ж я уже этих книжек скачал, сколько сайтов перерыл...
Где-то одно понятно (для моего разума) написано, где-то другое...
А один фиг уточнять и сверяться приходится с родным буржуйским даташитом (ладно, может хоть на этом поприще английский выучу, давно мечтал в принципе)

есть такая прога...

Есть. И ещё миллион других прог есть. Все не изучишь, мне бы для начала все мнемоники ассемблера назубок запомнить а то постоянно со справочниками сверяться приходится. Я так решил, что пока эту прогу не допишу, никаких Визуал Бейсиков , т.е. программ автоматизирующих работу и т.д. Цель - именно мозг раскачать. А уже потом с просветлённым разумом можно подбирать более удобную программу.

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

in r17,timsk
sbr r17,1<<TOIE0 ;сразу видно что разрешаем прерывание от Т0 по переполнению
out timsk,r17

ну и R17 заменить на, скажем, temp
ну и т.д.

Да я и сам уже это понял. Вчера добрых несколько часов убил, всё переименовывал, упорядочивал, заворачивал в макросы...

не будем углубляться - это все-таки сайт не про мк

Сайт не про МК, а тема про МК, так что по правилам сайта, это не оффтоп, поэтому можно и углубиться

PS Это Ваше первое сообщение на данном форуме, причём в такой специфической теме... Нет, это не упрёк или что-то ещё, просто необычно как-то

[jamper]

Все очень просто
AVR это мое основное хобби, причем пишу исключительно на АСМе , поэтому не смог промолчать про прерывания.
а дополнительное, но не менее любимое ИЛ-2 ЗС , и вот после смерти очередного джоя решил забодяжить что-нибудь этакое, поиск привел меня на этот сайт, а тут "столько вкусного" , уже собрал контроллеры HJFree, MJ16, сейчас мастрячу механику под рус/руд, а дальше видно будет...

[Zorge]

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

За индикацию по прерыванию нас в институте цитирую:
"Увижу - буду бить. Сильно, но аккуратно" (с) один хороший майор.

Пользователь с временем реакции 0.2 секунды не помрет, если получит индикацию на 10-50 миллисекунд позже. А чтобы символ не потерялся - нужно программировать так, чтобы после возврата из прерывания все сохранилось. Например хранить индекс сканируемого символа и выводимое значение индикатора целиком в памяти.

Прерывание, в отличие от основной программы, строится в расчете на непрерываемость - потому что памяти у нас мало, процессор слабенький - не до жиру.

Задержка без использования стека (тоже, кстати, надо по-минимуму в прерывании применять, как и любое другое обращение в ОЗУ - считал данные в начале работы, записал данные по окончании и хватит) и дополнительных извращений - это 255 тактов максимум. От нее сильно никому не поплохеет. Обычно, я задержки вставляю в прерываниях, чтобы внешний регистр успел перещелкнуться, или чтобы выдать синхронизацию строго после того, как данные на шине устаканились.

Конечно, если "по фен-шую", то в прерываниях должны только флаги выставляться, а по этим флагам основной цикл подпрограммы вызвать, разбираясь - кому времени побольше дать, а кому не очень. С флагами "меня после входа дольше чем на столько-то не прерывать" (чтобы протокол соблюсти например). Отправлять контроллер "спать", если ничего не делается. Чтобы истинная многозадачность была.
"Когда надо дать всем поровну, часто и помногу" (с) тот же самый майор.
Но это в больших проектах и/или на ЯВУ с поддержкой этой самой многозадачности компилятором.

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

А вот делать задержки внутри обработчика прерывания есть наипервейшее зло, само название - "прерывание" говорит о том что прерывается основной (читай самый важный) процесс, а вы в нем задержку...

У меня совершенно противоположный подход. Все самое важное и требующее непрерывности, непременно полной обработки - по прерываниям, callback ам от прерываний, дополнительным процессам (когда надо - и с повышенным приоритетом).
А основной процесс занимается обработкой ввода пользователя, индикацией. Поэтому, если получит управление чуть попозже - ничего страшного не случится.
Да и сделать только основной процесс безопасно прерываемым гораздо проще, чем городить эту самую "реентрабельность" везде и всюду. Экономит и время написания и отладки, и код и оперативную память.

2. есть такая прога VMLab 3.15 заточена как раз под АВРки, проста как 7 коп. и позволяет моделировать вх.сигналы.
ИМХО протеус слишком перегружен для любителей.

Перегружен - это P-CAD PC logs 1988-го года выпуска и Multisim начала 2000-х.
А Протеус прост как тапок. Главное накидать цифровых элементов, а не аналоговых - и вперед.
VMLab, при всей его навороченности и сложности всего-лишь отладчик.
Proteus отличается от Microcap или там EWB только тем, что контроллеры моделировать умеет. Поэтому после его освоения получится не потеряться и в них и хотя бы понимать "куда копать" в других программах подобного класса.

Хотя, может у меня такое мнение, потому что мой любимый AvrCo сам себе VMLab - есть в нем и индикатор ЖК, и семисегментные индикаторы, и эмулятор терминала для UART, и на АЦП можно подавать всякие загогулины, да много чего еще.

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

Согласен. Однако просто так самому дисциплинировать себя сложно.
Лучше написать что-нибудь зубодробительное без комментариев.
А потом при попытке разобраться в написанном в целях дополнения или модификации - плюнуть и переписать "как надо" уже заново, с правильными именами и структурой данных.
Когда наступишь на грабли сам, да еще несколько раз - набитая шишка не даст лениться.

Я так решил, что пока эту прогу не допишу, никаких Визуал Бейсиков , т.е. программ автоматизирующих работу и т.д. Цель - именно мозг раскачать. А уже потом с просветлённым разумом можно подбирать более удобную программу.

Пожелаю удачи. Наверное так и надо.
А я так и не добил свой крупный проект на астме.
Может я и ленивый. Но когда написал его же за полторы недели на Паскале, и еще за месяц отладил до состояния "комар носа не подточит", после того как полгода мурыжил его на ассемблере - был счастлив.

Я наверное нестандартные велосипеды изобретаю.
Нормальные люди "ресетят" контроллер переходом по нулевому адресу. А я, если есть watchdog - вешаю контроллер, точно зная, что watchdog все сделает сам.

[Alex Oz]

Эх, счастливые вы люди, есть время копаться в регистрах
Тут с прикладной физикой успеть бы разбираться...

...
Нормальные люди "ресетят" контроллер переходом по нулевому адресу. А я, если есть watchdog - вешаю контроллер[/url], точно зная, что watchdog все сделает сам.

While(1) ; - и я так грешным делом люблю

[jamper]

У меня совершенно противоположный подход

какие ваши годы
"я тоже был молодым и горячим" (с) "Люди и манекены" А.Райкин

"Увижу - буду бить. Сильно, но аккуратно" (с) один хороший майор.

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

PS я тоже мойор, и вроде тоже не плохой

[ZMIY]

Продолжение моей борьбы с Икс ИК лучами: http://forum.easyelectronics.ru/view...p=50414#p50414

[ZMIY]

Блин. Трассировал прогу и понял почему не работает - таймеры не запускаются ! Вроде все биты везде куда надо рассовал, а они не тикают !
Объясните плиз, как их пнуть, чтобы пошли ? А то я уже ничего не соображаю. При то, что раньше (ну ещё в первой, пробной программе), я как-то запустил ! Работало ! И листинг не сохранился посмотреть

[LeonT]

как их пнуть, чтобы пошли ?

Дык, как пнуть... биты правильно поставить. Другого пути нет. Тяжко, что их до фига, и рассыпаны они по разным регистрам.
Щас пошарю, может есть у меня где-то готовая процедура инициализации ТС для Меги8.

----------------

Ну вот фрагмент. Вроде должен быть из рабочего кода. Во избежание, привожу в неправильном наглядном виде.
;-------- настройка ТС
ldi tmp1,0x3f ;
out ocr1ah,tmp1 ;OCR по сравнению с 3FFEh
ldi tmp1,0xfe ;
out ocr1al,tmp1
ldi tmp1,0b00000000 ;режим OCR
out tccr1a,tmp1
ldi tmp1,0b00001001 ;F=CLK, режим OCR
out tccr1b,tmp1 ;

;-------- настройка прерываний
ldi tmp1,0b00010000 ;разрешить прервание от сравнения А
out timsk,tmp1 ; TC1

Обобщая свой личный опыт, замечу, что в начальном периоде, моими наиболее частыми критическими ошибками были:
1. забыл задать вектор прерываний
2. забыл задать стек
3. напутал с фузами
4. в командах CBR,SBR использовал номер бита, а не маску

[ZMIY]

Спасибо. Но поздно. Таймеры я запустил ещё вчера. Теперь другая проблема. Кусок кода, которй должен фильтровать помехи, их не фильтрует Причём прогоняю в Студии, всё работает как и задумано. А когда девайс запускаю - помехи спокойно пролазят. Второй день уже бьюсь. А не позвать ли Батюшку, чтобы святой водой окропил...

[jamper]

Может лучше книжек умных почитать, смотрел я код, без пол-литры не разобраться, так что не мудрено что не работает как надо.

[ZMIY]

Какой именно код ?
Я его уже раза три стирал и писал по новой
Книжки читал, много. Толку от них ноль, пока сам не разберёшься. Вернее не так, толк от них есть, но для тех, кто вообще не в теме. А когда основы уже знаешь, надо брать и что-то делать самому. Пока сам, руками не попробуешь, книжки можно хоть наизусть знать - толку не будет

[Zorge]

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

Расчет RC-фильтра:
w = 1/(RC)
w = 2*Pi*f
f= 1/(2*Pi*R*C)
R положим 1 кОм.
Тогда С = 1/ (2 * Pi * R * f)
Так как T = 1/f, то
C = T / (2 * Pi * R)
где
w - круговая частота, f - частота, Т - период, R - величина сопротивления в фильтре, C - величина емкости в фильтре, Pi = 3.14159, дальше не помню, число Пи короче.

Пропускаем все с периодом больше или равным 0.1 миллисекунды, все остальное вырезаем.
Тогда C = 1e-4 / (2 * Pi * 1e+3) = 1,59e-8 или 16 нанофарад.

Ну и выкладывай свой фильтрующий код - покурим вместе.

[ZMIY]

Пропускаем все с периодом больше или равным 0.1 миллисекунды, все остальное вырезаем.
...
Ну и выкладывай свой фильтрующий код - покурим вместе.

Среднее время помехи 0.13 мс, так что не поможет.
Выложу, покурим. Но позже. Просто дело в том, что я придумал как вообще фильтровать помехи не фильтруя их Ладно, сейчас пошёл прогу переделывать под новые соображения, а завтра выложу старый код на растерзание. Дай Бог чтобы эта идея заработала...

[ZMIY]

Долго трассировал и обнаружил странный баг. Выпал в осадок.
????????!!!!

[LeonT]

ЕМНИП команды BRMI, BRPL с флагом N работают, хитросделанным. (он вроде переключается при переходе не через 255/0 а через 127/128, насколько помню, может и ошибаюсь - не пинайте. Как-то давно уже с этим пересёкся, и с тех пор работать с этим флагом не возникало необходимости)
Лучше BRCC BRCS.