Ну зачем же такой "экстремальный" пример приводить? Который, кстати, алгоритм-то не дискредитирует Я же не обещал ровно до 32К тактов дополнительного прерывания. Ваш пример всего-лишь указывает, что максимальное время прерывания = 32К-хх тактов. Скажем 31К или 32000 такта 100% хватит для работоспособности проги. А в Вашей версии будет то же самое = 256-хх тактов.
Вобщем недостатка как такового в моей версии и нету. Блин

А что там уметь? Прерывание, оно и в Африке-прерывание(:-).
По делу. Выразился не так, как хотел. Мне не нравится длинное прерывание, которое вдруг стало накладываться на наши два. Откуда бы ему взяться в задаче по измерению временного интервала? Поэтому предлагаю сделать откат назад и исключить третье прерывание.

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

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

И моим оппонентам на будущее. Я говорю то, что говорю, не надо искать второго смысла, ОК? И замечайте смайлики иногда.

Ну раз так, вот вам еще экономия. Не используйте регистры r5-r4 в прерывании, храните результат непосредственно в регистрах icr1h-icr1l. Будет сохранно, как в банке ... до следующего захвата.

А как Вы в основной программе планируете узнавать что произошел второй захват ?

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

Ведро маслят... Это многое объясняет... Как-нить при случае тоже ляпну такое

Прошу прощения за оффтоп, но для самого автора темы проблема давно уже как не актуальна (1-й пост - 2-го июня)...

ну точно OFF - в топку

___________
Please, don't kill me

Конечно, гарантия непрерываемости текущего обработчика прерываний даёт возможность, например, использовать некоторые регистры или ячейки памяти в качестве общих временных для всех обработчиков прерываний без сохранения их предыдущего состояния, а также ограничивает размер стека - это удобно. С другой стороны, на ранних AVR-ках с аппаратным стеком (на 3 вложенных вызова подпрограмм и прерываний) иначе и быть не могло. А далее памяти прибавили, но основу ядра менять не стали...

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

Осмелюсь предложить следующее решение:

Здесь уже кому как повезет, куда _TOV1 попадет в TIFR, такой и будет запас
для длинных прерываний.
Да и код, ИМХО становится намного понятнее

А если серьезно, то запас для других прерываний нужно оставлять в зависимости
от конкретной задачи.
Например, вместо TIM1_OVF мы можем использовать TIM1_CAPTA со значением
OCR1A<32K и тогда запас должен быть другим, тогда будет рулить такой код:

Ну конечно на определенном диапазоне значений OCR1A

А вы у GetSmart спросите, он всё знает(:-). Спокойно, GetSmart, шютю я(:-)

Чуть посерьёзнее. Я вам про экономию регистров в прерывании говорю, "которых всегда не хватает", а вы плавно меняете тему. Какая разница, где хранить время текущего захвата, в регистрах r7-r6-r5-r4 или в r7-r6-icr1h-icr1l? Никакой разницы нет. Почти. Зато экономится два регистра!

Ну а по делу, думаю есть несколько подходов.

1) Есть две переменные, скажем, oldTime и newTime (ваши r7-r6-r5-r4). Прерывание захвата должно переписывать содержимое newTime в oldTime, и только затем обновлять newTime. Основная программа в любое удобное для себя время(:-) определяет длительность интервала, просто вычитая содержимое oldTime из newTime.

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


Неправильно. В том то и дело, что не один раз при запуске программы надо инициализироваться, а каждый раз при входе в захват(:-(. Потому что на четных захватах вы ловите переход 0-1 (начало импульса), а на нечетных захватах вы ловите 1-0 (конец импульса). Я и спрашивал, перенастраивать ICES1 каждый раз или есть другой способ, попроще?


GetSmart, хорош бурчать, это у вас так что проявляется(:-)? Не злитесь, ляпните что-нибудь или тяпните, разрядка придёт, поверьте(:-). Добавлю специально для вас. Напротив моих окон стоит бангало, под ним живет более 20 диких кроликов, смешные такие...А недавно видел как ворона ссорилась с белкой, наскакивали друг на друга, прям как вы на меня(:-).

GetSmart, жена маслята уже посолила, вот. Белые тут тоже водятся, но ехать далеко, в Нью Форист, неохота...

Это веселуха. Заметьте, над другими тоже. А вообще, люблю "поржать" над чужими глупостями. Это после длииинного отпуска у меня такой бзик. Должен пройти.
Нету.Нее, я мало знаю. На всём форуме я очень мало где появляюсь. То есть знаю совсем немного тем, но обычно очень глубоко.

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

Дык, эта, если смотреть со стороны, здесь все замечания вам по делу были сказаны, а вы все в шутку да в обидку воспринимаете..
Что ни пост - то перл:

особливо это:

Ну уж никак не в аппаратно зависимых регистрах, которые нам абсолютно неподконтрольны.
Вы что, правда не понимаете, что можно не успеть вычитать icr1h-icr1l до того как случится следующий захват? либо например наткнуться на ситуацию когда в момент вычитки L, произойдет следующий захват.

Я и не такие перлы могу выдавать(:-). Но вообще-то, в нашем случае никакой разницы на самом деле нет, посудите сами, как только произошел захват, возникло прерывание, в котором регистры icr1h-icr1l читаются и переписываются в r5-r4, т.е. и icr1h-icr1l, и r5-r4 изменяются практически одновременно (макс разница 32 мс, если есть длинное прерывание). Естественно предполагается, что вы должны успеть обработать r7-r6-r5-r4 до следующего захвата, который может случиться через секунду (по условию задачи). Ну и спрашивается, зачем тратить два регистра МК, если можно с таким же успехом хранить данные в регистрах захвата?

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

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

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

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

Что ещё? На справедливую критику не обижаюсь, с несправедливой борюсь по мере сил(:-), и посмеяться и пошутить люблю, но по-доброму.

Затем, что прерывание может произойти именно в момент вычитки значения, и мы можем прочитать недостоверные данные.

Если же рез-тат будет храниться в r7-r6-r5-r4, то мы можем запретить флаг I при обращении к этой 32х битной переменной, и тем самым обезопасить себя от последствий описанного случая.

Учить матчасть