Много вопросов накопилось... Сильно не глумитесь, ATMega16 & etc Опции

[Screw]

Здравствуйте, господа хорошие.
Перечитал я весь форум и охватило меня дикое желание узнать что-то новое в сфере AVR у профи, а не у таких же "знатоков" как я

Итак, от слов к делу:

1) Прерывания.... Знаю, тема больная, перечитал все, что тут есть..... Но.... либо опыта маловато, либо голова моя садовая - не принимает информацию
Объясните на пальцах, что произойдет, если... (везде имеется ввиду Mega16)
Произошло прерывание Int1, в нем стоит задержка (ну или какая-то работа выполняется), во время которой происходит событие на порту INT0 (больший приоритет по документации). Далее во время этой же задержки срабатывает прерывание по таймеру-счетчику.

Распишите, если не трудно, в каком порядке это все будет отработано....

Возможно как-либо изменить приоритет прерываний ? Какие существуют решения?

2) Каким образом можно посчитать количество времени, затраченного на выполнение определенного куска кода (подпрограммы обработки прерывания допустим) в CVAVR?

3) У Атмела существует такой AppNote - Zero-Detector. Суть (если кто не видел) - соединяем ч/з 1Мом фазу и int0, а так же ноль и землю питания контроллера. Далее через прерывание идет обработка...
Дак вот - собрал сначало я со стабилитроном (на всякий пожарный) на 2,5 В. Все бы ничего - но контроллер в прерывание не уходил. На осциллографе все красиво, но видимо Меге мои красоты до..... Стабилитрон убрал - работает. Объясните, почему так оно происходит? При длительной работе без стабилитрона выход контроллера из строя как скоро произойдет?
За одно про int0 и тп.... в настройке этого прерывания можно выставлять передний и задний фронты сигналов (выставлял есс-но не я, а CVAVR). У меня есть подозрение, что что-то я делаю не так, ибо на осциллограмме смотрю фазу - ушла вниз, а прерывание на передний фронт сработало. (фазу и ноль не перепутал.... единственное - может меандр уплывает, но двухлучевика нет).

4) Граждане, привидите пример опроса клавиатуры 4x4 матрица... Самый простой, чтобы в глобальную переменную (назовем её key) выводилось значение нажатой клавиши.
Делал сам по 2-м алгоритмам.... сначало бегающим нулем с pullup, затем код клавиши вычислял через значения pinX.... Но то ли лыжи не едут.....


Надеюсь на Вашу помощь. Извините за сумбурность, писалось это все в 1-27 ночи

Сообщение отредактировал Screw - Nov 29 2006, 22:38

[Wild007]

По первому пункту:
При входе в пп обработки прерывания снимается флаг I регистра SREG (глобальное разрешение прерываний) и, естественно, если во время обработки прерывания произойдет любое другое прерывание его обработка начнется только после команды RETI в соответстви с его приорететом. В прерывании конечно можно программно разрешить обработку других прерываний (SEI), но вы запутаетесь в разрешениях и нарушится баланс стека, что не есть хорошо. Корректней в пп обработке прерывания надо просто устанавливать какой-то флаг прошедшего преравания и обрабатывать его в главном цикле. Тогда не запутаетесь со стеком и приоретет обработки прерываний вас не будет волновать. Приоритет прерываний установлен жестко логикой работы мс и изменить его програмно не возможно.

По второму пункту:
Я пишу програмы на ASM в AVR Studio и она позволяет измерить время выполнения любого куска програмы и не было случая что бы время выполнения реальной програмы на реальном железе отличалось от измеренного в STUDIO.

[SasaVitebsk]

По первому пункту:
При входе в пп обработки прерывания снимается флаг I регистра SREG (глобальное разрешение прерываний) и, естественно, если во время обработки прерывания произойдет любое другое прерывание его обработка начнется только после команды RETI в соответстви с его приорететом. В прерывании конечно можно программно разрешить обработку других прерываний (SEI), но вы запутаетесь в разрешениях и нарушится баланс стека, что не есть хорошо. Корректней в пп обработке прерывания надо просто устанавливать какой-то флаг прошедшего преравания и обрабатывать его в главном цикле. Тогда не запутаетесь со стеком и приоретет обработки прерываний вас не будет волновать. Приоритет прерываний установлен жестко логикой работы мс и изменить его програмно не возможно.

Вы своим ответом вводите в заблуждение. "Но вы запутаетесь в разрешениях и нарушится баланс стека" - это непереводимая игра слов. Если всё рассчитано правильно, то ничего страшного произойти не может. Вы не запутаетесь потому что Вы не обрабатываете прерывания, а МК не запутается потому что он МК. Его запутать сложно. Если у Вас придёт разрешённое прерывание ещё раз, то это нехорошо но это недопустимо при любой обработке. Теоритически, наверное, обработать можно если учитывать такую вероятность. Но если такое происходит регулярно, то такая прога не будет работать как при разрешённых, так и при запрещённых прерываниях. То есть здесь надо следовать Dog Pawlowa и чётко расчитывать производительность контроллера.

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

Для двух уровней - да. Для трёх - перечитайте - там нет примера, но разжёвано. Как понимать фразу "Т.е. получится, такая же цепочка из допустимых прерываний"? И что Вас пугает? Кстати двух уровней достаточно для 99% случаев. Это же не IBM.

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

Естественно. Оно (или они) будет обработано сразу же после завершения обработки высокоуровневого прерывания, в порядке аппаратных приоритетов. М/у этими прерываниями будет выполнятся по одной операции головы. Глубина стека при этом должна быть увеличена и предусматривать возможность вложенных прерываний.
Рассмотрим например вариант когда у Вас три прерывания. Int1, UART, OCR0. Int1 - высокоприоритетное, остальные равные. Тогда в OCR0 и UART необходимо разрешить прерывание. Во всех трёх не должны быть использованы общие переменные или за этим необходимо следить, не должно быть использованы общие ресурсы. Например приходит прерывание от UART (не завершилось) потом Int1 (прервана UART) и во время Int1 - OCR. После завершения Int1 будет выполнена одна команда UART и вызвано OCR, по завершению - завершится UART. Поскольку возможен вариант вложенных вызовов OCR-UART-Int1, то стек должен быть увеличен на сумму стеков этих прерываний. Время реакции самого высокоприоритетного прерывания составит в худшем случае - 4+1+4 если команда sei идёт первой командой низкоприоритетного прерывания (так бывает не всегда). Это для ассемблера. Для Си надо смотреть реальный код.

[defunct]

фразу "Т.е. получится, такая же цепочка из допустимых прерываний"? И что Вас пугает? Кстати двух уровней достаточно для 99% случаев. Это же не IBM.

С тем же успехом можно заявить - одного уровня достаточно для 99% случаев. Вот и появляется вопрос:

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

этот вопрос, чуть выше Вы назвали:

это непереводимая игра слов.

[SasaVitebsk]

фразу "Т.е. получится, такая же цепочка из допустимых прерываний"? И что Вас пугает? Кстати двух уровней достаточно для 99% случаев. Это же не IBM.

С тем же успехом можно заявить - одного уровня достаточно для 99% случаев. Вот и появляется вопрос:

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

этот вопрос, чуть выше Вы назвали:

это непереводимая игра слов.

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

1) Непереводимая игра слов я ответил потому, что она там была. Поясните мне что значит фраза "запутаться" или "нарушить баланс стэка" и какие у Вас проблемы "связанные с синхронизацией данных"?
Ещё раз Вам повторяю. Я с этим работаю постоянно. Никаких проблем нет. По крайней мере у меня.
2) На счёт "второго уровня", давайте банально обратимся к оборудованию. Если бы это было не нужно, то этого нигде или почти негде небылобы. Но это есть аппаратно в x51 (2 уровня) в ARM (8) в других просто не интересовался.

Приведу простой и по моему доступный пример, - приведите своё решение. У меня идёт сигнал со станции 32 кГц(31.25мкс) (АТС С32) где "0" импульс длительностью 2мкс, "1" - длительностью 4мкс. Ч/з 2мкс от среза мне необходимо выдать ответный импульс длительностью 2мкс. Есть прерывание от таймера и USART. Частота 7.3728.

Всё это на уровне ощущений, как и везде в программировании. Я лишнее никогда не добавляю. Я сразу чуствую что можно, а что лишнее. И если получается как-то не так, то чуствую какой-то дискомфорт. Я понимаю что скорее всего уважаемый defunct чувствует что-то вроде этого. То есть ему просто не нравится данное решение. Кажется ему некрасивым. Но это не так! Надо просто попробовать. Там всё Ok. И проблем не больше чем везде. Кстати всё прекрасно работает и из под Си. Это видно из моего примера.

[defunct]

1) Непереводимая игра слов я ответил потому, что она там была. Поясните мне что значит фраза "запутаться" или "нарушить баланс стэка" и какие у Вас проблемы "связанные с синхронизацией данных"?

как минимум две очевидных проблемы:
1. Чтение частично обновленных данных.
2. повторный вход в текущий обработчик прерывания, как следствие - переполнение стека.

Ещё раз Вам повторяю. Я с этим работаю постоянно. Никаких проблем нет. По крайней мере у меня.

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

2) На счёт "второго уровня", давайте банально обратимся к оборудованию. Если бы это было не нужно, то этого нигде или почти негде небылобы. Но это есть аппаратно в x51 (2 уровня) в ARM (8) в других просто не интересовался.

Аргумент не очень убедительный, т.к. в противовес этому примеру можно поставить AVR'ы, PIC'и где уровней всего один..

Приведу простой и по моему доступный пример, - приведите своё решение. У меня идёт сигнал со станции 32 кГц(31.25мкс) (АТС С32) где "0" импульс длительностью 2мкс, "1" - длительностью 4мкс. Ч/з 2мкс от среза мне необходимо выдать ответный импульс длительностью 2мкс. Есть прерывание от таймера и USART. Частота 7.3728.

Через 2us от среза это не строго? Иначе ваша задача нерешаема и с двумя уровнями вложенности, так как просто переход на обработчик прерывания занимает около 11 тактов, что с приведенным кварцем займет примерно ~1.5 us. С учетом вложенности прерываний - "люфт" будет приблизительно равен ~3 us. Первым делом я бы поставил кварц на 14.7456, ну а дальше смотрел бы.. Возможно пришлось бы добавлять на формирование импульсов отдельный MK или внешнюю логику.

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

Есть такое ;>

Я понимаю что скорее всего уважаемый defunct чувствует что-то вроде этого. То есть ему просто не нравится данное решение. Кажется ему некрасивым. Но это не так! Надо просто попробовать. Там всё Ok.

Как по мне, то там где многоуровневость действительно нужна, лучше применить упомянутые Вами x51 или ARM в которых многоуровневость поддерживается аппаратно.

[SasaVitebsk]

как минимум две очевидных проблемы:
1. Чтение частично обновленных данных.
2. повторный вход в текущий обработчик прерывания, как следствие - переполнение стека.

Это очевидные "не проблемы". Стек может переполнится и с одним уровнем прерываний и ошибка совместного использования данных - также. Простой пример - проверка свободного остатка кольцевого буфера - а между сравнениями младшего и старшего байта указателя вызов процедуры прерывания от UART с переходом по кольцу. (Я один раз получил - долго искал)
Это не проблемы выбранного метода, - это просто недостаток опыта или знаний у программиста.

Аргумент не очень убедительный, т.к. в противовес этому примеру можно поставить AVR'ы, PIC'и где уровней всего один..

Для меня убедительный. Если для x51 я могу выполнить две команды
setb ex1
setb px1
и получу практически то же самое что я делаю здесь софтово, и там никому в голову не придёт меня "осудить" за "неправильное" использование оборудования, то непонимаю как это мне можно пришить здесь.

Как по мне, то там где многоуровневость действительно нужна, лучше применить упомянутые Вами x51 или ARM в которых многоуровневость поддерживается аппаратно.

Аппаратно - это громко сказано. Чего Вы боитесь?
Это мне напоминает момент когда я написал свою первую прогу на x48. Вижу - ошибка, найти не могу. И тут ... о ужас ... этот процессор не делает автоматического сохранения PSW (читай SREG) процессора при входе/возврате в/из прерывания.... как дальше жить ... какой бред....
С тех пор прошло много лет. Оказывается земля не рухнула, и всё я это делаю руками. Как то привык и эмоций это у меня не вызывает.

И там тоже нет никаких проблем. Я не делаю ничего крамольного. Я не обращаюсь к стеку и не модифицирую его. В x51 можно переключить банки регистров - в avr можно использовать разные регистры (это при написании на asm). Для Си вообще ничего делать не надо. Компилятор обо всём сам позаботится. Да - нельзя использовать совместные ресурсы в прерывании. Так я этого и так стараюсь не делать во избежание. Я стараюсь чтобы каждый процесс был завершён. Выходные данные одного процесса - входные для другого. А перепинговывание - это просто доп сложности.

В завершение скажу, что допускаю возможность повторного входа в прерывание (если оно грамотно написано). Ну например ситуация: идут нерегулярные прерывания от Int0 со средним временем не более одного прерывания в 200мкс. Обработка его занимает 60мкс. При этом оно может придти в конце интервала или в начале, таким образом минимальный разрыв м/у ними может составлять 10мкс.
Ничего нет сложного в написании данного прерывания без применения дополнительных внешних аппаратных средств. И процедура будеть выглядеть обычно.

Кстати изделие с протоколом описанным в моём топике выше выпускалось серийно с момента появления 4414 (максимальная тактовая частота 8000 поэтому о 14745600 речи не шло). К слову скажу что аналогичное изделие выпускалось в Днепропетровске. И было оно основано на PIC и тоже частота кварца была невысока.


Дальнейший спор на эту тему считаю бессмысленным, так как он просто отражает "пристрастия" авторов. А свои пристрастия, по моему убеждению, каждый должен выбирать себе сам. Так что выбор за Вами.

[defunct]

Аппаратно - это громко сказано. Чего Вы боитесь?

Гм.. Аппаратно - это не громко, а точно сказано, т.к. имеются средства аппаратуры, которые автоматически блокируют возможность вызова прерываний того же уровня. Чтобы повторить это на AVR, Вам потребуется на входе в прерывание вручную блокировать все прерывания того же уровня, и лишь после этого устанавливать флаг I. Т.о. накладные расходы получатся весьма значительными, а выигрышь от всего этого - практически никаким.

Это мне напоминает момент когда я написал свою первую прогу на x48. Вижу - ошибка, найти не могу. И тут ... о ужас ... этот процессор не делает автоматического сохранения PSW (читай SREG) процессора при входе/возврате в/из прерывания.... как дальше жить ... какой бред....
С тех пор прошло много лет. Оказывается земля не рухнула, и всё я это делаю руками. Как то привык и эмоций это у меня не вызывает.

И не надо его сохранять т.к. в x48 одноуровневый КП. Вот интересно, что бы Вы сказали если бы у x51-го PSW не сохранялся.. такой проц можно было бы сразу "фтопку".

И там тоже нет никаких проблем. Я не делаю ничего крамольного. Я не обращаюсь к стеку и не модифицирую его.

Разрешая прерывания глобально, вне зависимости от Вас, идет работа со стеком. (вызовы других обработчиков прерываний).

Для Си вообще ничего делать не надо. Компилятор обо всём сам позаботится.

Ну-ну..
Компилятор ни о чем не позаботится, ему все равно какие строки переводить в код. Заботиться обо всем нужно разработчику.

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

Вот это и есть та самая забота - по устранению проблем связанных с синхронизацией, которую компилятор за Вас не сделает.

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

Ключевое слово "если"

Ну например ситуация: идут нерегулярные прерывания от Int0 со средним временем не более одного прерывания в 200мкс. Обработка его занимает 60мкс. При этом оно может придти в конце интервала или в начале, таким образом минимальный разрыв м/у ними может составлять 10мкс.

Вопрос, зачем это надо? Ведь после завершения обработки первого прерывания можно спокойно обработать и второе.

Кстати изделие с протоколом описанным в моём топике выше выпускалось серийно с момента появления 4414 (максимальная тактовая частота 8000 поэтому о 14745600 речи не шло). К слову скажу что аналогичное изделие выпускалось в Днепропетровске. И было оно основано на PIC и тоже частота кварца была невысока.

Видимо это изделие решает не такую задачу как Вы описали.
На PIC'е подозреваю ребятам тяжко пришлось поизвращаться на асме, причем без прерываний, т.к. ваша задача (в том виде в каком Вы ее поставили) на PIC с 200ns циклом @20Mhz с прерываниями нерешаема вообще.

[SasaVitebsk]

Гм.. Аппаратно - это не громко, а точно сказано, т.к. имеются средства аппаратуры, которые автоматически блокируют возможность вызова прерываний того же уровня. Чтобы повторить это на AVR, Вам потребуется на входе в прерывание вручную блокировать все прерывания того же уровня, и лишь после этого устанавливать флаг I. Т.о. накладные расходы получатся весьма значительными, а выигрышь от всего этого - практически никаким.

Как правило, прерываний не десятки а 2-5 и, даже если есть необходимость запрещать прерывания равного уровня накладные расходы не так уж и велики, - 2 такта на каждый запрещённый вектор. Но этого, как правило при 2-ух уровневой системе не требуется. Потому что ничего, фактически не произойдёт, а просто может поменятся порядок обработки событий (см. мой топик выше). А Выигрыш легко виден на осциллограмме в моём примере.

Разрешая прерывания глобально, вне зависимости от Вас, идет работа со стеком. (вызовы других обработчиков прерываний).

И что тут страшного? Ну идёт, и что???? На то он и стэк! Это даже замечательно! Проблема может возникнуть как раз если работа идёт не через стек, а обходным путём. Ну например, для экономии в двух равных прерываниях использованы вместо push SREG, mov save_sreg,sreg.

Ну-ну..
Компилятор ни о чем не позаботится, ему все равно какие строки переводить в код. Заботиться обо всем нужно разработчику.
...
Вот это и есть та самая забота - по устранению проблем связанных с синхронизацией, которую компилятор за Вас не сделает.
...
Ключевое слово "если"

Мы говорили уже на эту тему. В том плане, что "это не проблема реализации, а проблема опытности разработчика". И говоря что "компилятор" обо всём позаботится я имел ввиду начинающих программистов. Проблемы начнуться тогда когда они станут "профи" и начнут запрещать компилятору использовать регистры и использовать вручную, начнутся тогда, когда они начнут вставлять свои куски ассеблерного кода или начнут переписывать обработчики прерываний, начнутся тогда, когда попытаются в прерывание воткнуть пол-головы и начнут м/у прерываниями передавать сложные данные. Иначе ничего не будет. Обычно прерывания логически слабо связаны м/у собой, так как они обрабатывают РАЗНЫЕ события. И, как правило, ничего страшного не происходит если из прерывания, которое формирует временные метки будет вызвано прерывание от USART а из него прерывание от Int0.

На самом деле это что-то сродни обсуждаемому вопросу: "зачем нужна OS". Лучше возможно и не станет, но красивее - точно. Каждый процесс логически закончен! А здесь ещё и выигрыш для конкретного обработчика (проигрыш для остальных).

У меня сейчас - светодиодное панно. Прерывания от USART - 3 (rs485), от таймера (таймаут для rs485), от таймера - регенерация экрана, от таймера (софтовое - каждое девятое прерывание регенерации) - обработка команд и голова приём команд. Высокоуровневое - регенерация. Графика и анимированная графика, полутона и цвет. Никаких специальных приёмов - нет. С максимальной оптимизацией по времени. IAR C. Кстати малейшие девиации при отображении картинки - видны на глаз.

Можно ли написать без этого? Да безусловно! В этом особая прелесть программирования, - творчество и совершенная свобода выбора. Будет ли красивее? Вполне возможно, но уже не мной. К тому же красота - субъективное понятие.
Но главное - у меня всё работает тоже. И я оцениваю своё решение как красивое. Значит моё решение тоже имеет право на жизнь. И я думаю, многие програмисты используют мой подход, так как я ни в коей мере не считаю его "своим изобретением". Возможно он родился раньше меня.

PS: А.Г.Алексенко,А.А.Галицын,А.Д.Иванников "Проектирование радио-электронной аппаратуры на микро-процессорах", Москва "Радио и связь" 1984г. (Когда-то была бестселером по i8080) стр. 51 "Для задания простого приоритетного режима не требуется никаких дополнительных команд, кроме команд инициализации. ... Поэтому для организации многоуровневой системы прерываний необходимо выполнить програмную установку этого тригера командой EI (РАЗРЕШИТЬ ПРЕРЫВАНИЯ) МП. ... Для реализации многоуровневой системы прерываний каждая из п/программ обслуживания должна иметь определённую структуру (рис.1.26)"
(1.26) Начало -- сохр. в стеке исп. регистров -- EI -- тело -- DI -- Сброс разряда регистра прер. (для avr не надо) -- EI -- RET

[defunct]

Можно ли написать без этого? Да безусловно! В этом особая прелесть программирования, - творчество и совершенная свобода выбора. Будет ли красивее? Вполне возможно, но уже не мной. К тому же красота - субъективное понятие.

Спасибо за потраченное Вами время!
Было интересно читать Ваши ответы.
К сожалению или к счастью мне нечем возразить на Ваш последний пост.

[SasaVitebsk]

Можно ли написать без этого? Да безусловно! В этом особая прелесть программирования, - творчество и совершенная свобода выбора. Будет ли красивее? Вполне возможно, но уже не мной. К тому же красота - субъективное понятие.

Спасибо за потраченное Вами время!
Было интересно читать Ваши ответы.
К сожалению или к счастью мне нечем возразить на Ваш последний пост.

Взаимно!