Много вопросов накопилось... Сильно не глумитесь, 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. И проблем не больше чем везде. Кстати всё прекрасно работает и из под Си. Это видно из моего примера.