Господа есть код в CodeVision примерно такой:




Как сделать чтобы по внешнему прерыванию от пина AVR функция loop завершала свою работу? выполнялась функция afterINT(), после чего вновь запускалась функция loop(). Пишу в CodeVision, но буду рад примеру и в WinAVR.


И еще - в ATMEGA32 INT0, INT1 и INT2 чемн-ниьбудь отличаются?

При возникновении прерывания так и будет, только после прерывания функция loop() продолжит работу с прерванного места(потому это и называется прерыванием), а то что вы написали внутри функции afterINT вам надо написать прямо в обработчике прерывания, или вам надо чтобы после прерывания функция loop() начала свою работу с i=0?

Как минимум, отличаются пинами на которые они выведены.

не просто с i=0, а с самого начала.
Есть некий процесс - в идеале, по его окончанию механика должна послать синхронизирующий сигнал. Если же контроллер не успел выполнить все что в функции loop(), то поезд ушел, все что не доделано должно забыться, и функция должна вновь начать свою работу с чистого листа.
Можно конечно сделать i глобальной переменной,в обработчике прерывания ее обнулять. Но я боюсь что в функции loop перед циклом будет еще несколько строк инициализации.



А все-таки? Собираюсь прицепить 3 датчика Холла, которые будут снимать сигнал частотой максимум 200 Гц, с длительностью импульса не более 70 мкс. Будут прерываяни одинаково работать?

Можно в цикле что внутри loop() проверять некий флаг, который будет выставляться в прерывании, и по этому флагу прерывать цикл, а т.к. ваша функция стоит в главном цикле программы, то произойдет очередная итерация главного цикла и выполнятся все команды которые стоят до фунrции loop(), да и те что после.

Вы хотите заставить меня заглянуть в даташит?

Можно в прерывании подменять адрес возврата. Но это грязный хак

В plain Си функция не может перезапустить саму себя. Это должна сделать внешняя по отношению к ней функция. Напомню, что main это тоже функция.
Вам вполне подойдет вариант с семафором (флагом), который устанавливается в прерывании, а цикле функции анализируется.
Только не забудьте присвоить переменной флага квалификатор volatile, чтобы избежать уже известных граблей.

2 Зверюга

0 от 1 отличаются вроде только тем что у 0 - приоритет в прерываниях выше. А 2 от предыдущих отличается асинхронностью, приоритетом в конце таблицы и очень урезанными условиями по которым генерится прерывание.. Более подробно- смотрите в ДШ..

Так как я в разделе для начинащих и сам я ламер - имею полное морально право попросить разъяснить про грабли. Плз...

Только не "подменять" (!!!), а загрузить в стек адрес на нужную функцию, т.е. стек увеличится на 1 слово. При выходе из прерывания окажешься в нужном месте с самого начала, а уже из этого места вернешься в первоначальное состояние.

Moderator:
Вы создали свою тему НЕ в разделе для начинающих. Тему перенес.

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

Программа в примере зациклится, т.к. компилятор "видя", что значение переменной внутри цикла while не модифицируется и посчитав ее константой, преобразует условие проверки в команду типа jmp сам_на_себя. Чтобы в примере программа не попадала в вечный цикл, нужно обявление делать как

Эта строчка "от балды" или играет непонятную мне роль в переходе в начало функции?


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

Можно так сделать?

Опс! Исправил. Она не от балды. Пример иллюстрирует ситуацию, когда переменная изменяется в прерывании, а проверка идет в другой функции. Без квалификатора volatile тут ситуацию не разрулить.
Вам же уже описали как это можно сделать.

Спасибо, теперь я разобрался. Это точно для CodeVision?

грамотнее.....



А это для вопрос для самоcтоятельного изучения

О вкусах не спорят

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

Я предпочитаю явное сравнение с нулем, так нагляднее и понятнее.

break прерывает выполнение цикла for, а не всей функции. Я применил goto потому, что нужно быстро выйти из функции, а не просто прервать цикл. Неизвестно нет ли еще какого-либо кода после цикла for.

Опять же о вкусах.. Я часто вообще while(1) пишу

Меня терзают смутные сомнения. А как это continue в функции main продолжит выполнение цикла for в другой функции? К тому же согласно последнему условию

вопрошающего нужно перезапустить всю функцию loop, а не только лишь продолжить цикл for внутри ее.

Это plain C за исключением #pragma vector и __interrupt. Насчет CodeVision не знаю, я им не пользуюсь

Все мною написанное относится к совершенно конкретному коду.

Грубо, нормальный компилятор должен выдать предупреждение о том, что условие выполняется всегда.
Кроме того, это опять таки сравнение, которое, конечно, приличными оптимизаторами выбрасывается. А вот for( ; ; ) это как раз и есть четкое указанию компилятору циклится безусловно.

Масло маслянное... Только лишний напряг для глаз и мозга, ну и оптимизатор,конечно заоптимизитует, но зачем? Кроме того магический "0" - тогда уже хоть FALSE/TRUE, если к этому делу наглядность приплетать.

Отнюдь! Я не потомственный программист и программированию специально не учился, видимо поэтому для меня как раз "напряг для глаз и мозга" вычислять условие истинности, дополняя его мысленно !=0. Компилятор конечно заоптимизирует и будет использовать какие-нибудь комплиментарные условию jnz/jz (ну или аналогичные команды) в этом случае.
false/true это только для семафора катит, а в общем случае явное сравнение с нулем всегда (особенно когда битовые маски в условиях вычисляются) и на всех компиляторах единообразно и правильно работает. К тому же в ANSI C нет булевых типов. Давайте в очередной раз не будем спорить о вкусах, вы меня в правильности моего вкуса все равно не переубедите
Вы лучше по поводу continue из main-а поясните. Как оно работает и работает ли вообще такой возврат в цикл другой функции?

Я не о Вашем переубеждении пекусь , а о нераспространении дальше

В приведенном куске continue предлагается использовать, как и положено, во while, причем тут main???

Вообще-то в C99 есть булевы типы...

2zltigo
"Я не о Вашем переубеждении пекусь , а о нераспространении дальше"
Что у Вас за мания критиковать чужой код и проповедовать свой стиль ропграммирования? Чем к примеру Вам так не нравится проверка с нулем?

Угу. В стандарте ISO/IEC 9899:1999 aka C99 есть, а в более раннем стандарте C89 aka Standard C aka ANSI C не было.


ОК. Пекитесь дальше раз вам так хочется
Притом, что вы предложили использовать continue и break вместо двух goto в моем примере. Но break при этом попадал в одну функцию (loop), а continue в другую (main). Поэтому и возник вопрос: а как это работает? Вы бы скопипастили мой вариант примера и исправили его по своему разумению, чтобы стало понятно, что именно вы хотели там "нераспространить"?

Спасибо заразрешение

Э... Похоже Вам надо ознакомится с continue...

Как-бы я все строчки указал... Ладно, не претендуя на изменение общего подхода к делу....


Теперь без break и дублироания проверки flag



Что совершенно не мешает использовать TRUE/FALSE для четкого указания читающему, что эта переменная принимает только два значения.


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

Вот я и хотел ваших пояснений по использованию этого оператора в данном случае. Я не понимаю как continue в одной функции (main) может вернутся к прерванному циклу в другой функции (loop)? Вот и компилятор мой (IAR) тоже не понимает, выполняя по continue возврат к началу for (;;) в main, а вовсе не к прерванному for в loop. Может поясните без обиняков. Я ведь не хочу вас уличить в каком-либо незнании, чтобы унизить, а понять суть явления и свои собственные заблужения. Ну не понимаю я как может осуществиться связь между этими операторами в разных функциях. Как я понимаю, область видимости у break ограничена лишь текущим контейнером, а у continue область видимости всего лишь одним уровнем контейнера выше, но в любом случае не дальше текущей функции. А вы считаете по-другому?
Кстати, во втором вашем примере вы изменили тип функции loop только для того, чтобы воспользоваться return для быстрого выхода из нее. В моем же примере использование goto вызывает тот же самый эффект, но без необходимости менять тип функции. Опять же повторюсь, что я не являюсь апологетом применения goto где-ни попадя. Мне вообще до сих пор не приходилось применять goto. Но в данном случае именно goto позволяет решить проблему без существенных коррекций исходных функций.

Так для начала прочитайте СВОЙ исходник и поведуйте миру, как Вам удалось узреть вышеизложенное в нем. Только, пожалуйста, читайте внимательно:

Где, Вы узрели "возврат к ... прерванному for в loop. " A?????
Написанное мной (в первом, буквально повторяющем варианте) полностью повторяет вышенаписанное, без абсолютно ненужного в этом случае goto и меток.

Так задача-то была прервать и перезапустить loop, насколько я могу понять:

Добавьте внутри "вечного цикла" перед вызовом loop() несколько операторов и/или вызовов других функций и попробуйте перезапустить с помощью continue только loop(). Для пояснения цитирую кусок исходного текста автора.
Многоточие, как я понимаю, обозначает один или несколько операторов до и после вызова loop().

Для начала ответьте, что за пургу тут несли с goto в черт-те-знает-куда
потом ответьте на вопрос чем код:

принципиально отличается от:

После первого прохода. Если захотите ИЗМЕНИТЬ условия задачи, то тогда как минимум стоит их публично огласить а не тихонько высасывать из пальца дополнительные условия. Повторяю, я НЕ собираюсь возражать против способа решения задачи (мне сама постановка представляется совершенно уродливой) все мной написаное относится только к корявому коду.

Не уходите от ответа. Я первый задал вопрос.
Поскольку нам неизвестно какие операции выполняют функции blabla и не влияют ли они на какие-либо общие глобальные переменные, то отвечаю - да, в общем случае порядок вызова функций имеет значение.
Вы это .... не гоните...лошадей. Я не менял условий задачи и в сообщении #13 привел пример, модифицировав исходный текст вопрошающего, под его условия. Вы же, вырвав из контекста задачи, привели исправления отдельных операторов, при подстановке которых в мой исходник работа программы меняется. Если внимательно приглядитесь, то у меня (в сообщении #13) как и у вопрошающего, имеются многоточия, обозначающие какие-либо операции до и после вызова loop в "вечном цикле" main. Тупая подстановка ваших замен изменяет функционирование программы. Поэтому я и пытаюсь от вас добиться пояснений, почему вы считаете эти замены полностью эквивалентными для функционирования программы? А вы же почему-то упираетесь в стилистику написания.

ИМХО, здесь Вы не правы: во-первых, порядок вызова функций не изменился, изменилась лишь точка входа; во-вторых, в кооперативной системе с вечным циклом в main'е порядок вызова не имеет не должен иметь принципиального значения.

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

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

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

Не для таких фокусов они придуманы, и уж точно не для прерываний.

Вы их просто готовить не умеете.
Вот как эти функции реализованы в IAR:
Нажмите для просмотра прикрепленного файла

Перочинный ножичек в руках искусного хирурга далеко лучше иного преострого ланцета. (с) Козьма Прутков. Афоризмы

Причем тут реализация к использованию для вышеупомянутых целей? Давайте я Вам со соловами "вот как реализовано" распечатаю еще чего нибудь....

Рассуждай токмо о том, о чём понятия твои тебе сие дозволяют. Так: не зная законов языка ирокезского, можешь ли ты делать такое суждение по сему предмету, которое не было бы неосновательно и глупо? (с) Козьма Прутков. Афоризмы

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

Понятия дозволяют. Я законы языка ирокез С ещё на PDP-11 изучал. И с работой setjmp/longjmp тогда же разбирался.


Чтобы из любой - это гораздо сложнее. Но Вас же не удивляет что любая (некооперативная) RTOS может передать управление другому процессу после того как текущий был прерван прерыванием?
Разбираемый сейчас случай попроще будет. Требуется поведение программы типа "всё бросить и вернуться на заранее подготовленные позиции", как раз для такого эти функции и предназначены.
В популярных учебниках тему setjmp/longjmp предпочитают не затрагивать, вот народ про них почти ничего и не знает.
Попробую рассказать что знаю, с некоторыми упрощениями.
Функция setjmp() всего лишь запоминает в специальном буфере содержимое нескольких регистров, указатель стека и счётчик команд (адрес возврата, лежащий в стеке). Эта информация потом, при исполнении longjmp(), позволяет восстановить состояние программы таким, словно только что произошел возврат из setjmp(). Отличается только возвращаемое значение, setjmp() возвращает 0, а longjmp() возвращает свой второй аргумент. Это позволяет понять откуда попало управление в этот раз.
Разумеется, восстанавливается далеко не всё, скажем если программа успела изменить глобальные переменные то эти изменения не будут откачены назад, ну так это-то уже в руках программиста, и он может это предусмотреть, если бывает нужно "прибрать за собой".

Поскольку longjmp() переставляет указатель стека на прежнее место, то существует естественное ограничение на её применение: состояние той части стека, которая существовала на момент возврата из setjmp() не должно изменяться до выполнения longjmp(). Другими словами, не должно быть выхода из функции или блока, содержащего setjmp().

А с учетом архитектуры AVR и имеющейся реализации этих функций не вижу никаких препятствий для примения longjmp() прямо из обработчика прерывания.
Реализацию в CodeVision надо проверить, но скорее всего и там будет работать. Примерно так (для IAR):

OS, в отличие от вашего "изобретения", вернет в какой-то момент времени управление назад.


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



Предположим, что из loop'а мы можем так вывалится (хотя и это сомнительно, если там производятся хоть сколько нибудь осмысленные действия), а из остальной программы, скромно обозначенной "//........"?

Ну нельзя использовать longjmp из прерывания. Одно дело, когда случилась ошибка, и нужно вернуть управление, а другое, когда эта "ошибка" генерируется снаружи.

Ну насчет все грубо бросить в непонятном состоянии И ЗАБЫТЬ НА ВСЕГДА, это еще большой вопрос о допустимости такого.

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

..И при прерывании/восстановлении в

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

Ага, самая примтивная архитектура и железо - скомпенсировали отсутствие RETI и типа все...
А на ARM слабо?

Ага, проверить, и при получении свежего компилятора проверить...

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

с которого все и началось...

не кажется что за спором вы забыли одну важную вещь, то что функция loop() конечная, т.е. она либо отработает 360 раз свой внутренний цикл, либо, по воле автора и в результате прерывания должна прервать свой цикл, что и достигается проверкой флага и оператором return. А вот что там должно произойти дальше, автор топика нам не раскрывает, т.е нужно ли после прерывания цикла в loop() выполнить следующие за ней функции(достаточно return) или нужно запустить цикл main сначала(return + continue) или перезапустить цикл в loop()(обнулить счетчик цикла).

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

Прежде всего, спасибо всем за возможность освежить знания о setjmp/longjmp.
Как всегда, когда имеешь дело с чем-то выходящим за пределы контекста С,
выясняется, что от процессора к процессору и от компилятора к компилятору,
алгоримт работы таких компонент может варьироваться.

Я просмотрел три варианта setjmp/longjmp, в TI CCS для ARM и С6000, и в очень
старом компиляторе MS QuickC 2.5 для 16 бит x86. QC мспользует setjmp/longjmp
в своем примере для обработки прерывания по ошибке FPU, тогда как нарямую,
без дополнительного кода, использовать setjmp/longjmp внутри прерывания ARM
или С6000 нельзя.

Конечно, если дополнить код ISR (или setjmp/longjmp), то нет никаких препятствий
для использования setjmp/longjmp внутри прерывания. В любом случае, setjmp/longjmp
были в первую очередь созданы для обхода правил передачи управления установленных
языком С. Где не хватает возможностей высокого уровня надо использовать низкоуровневые
средства.



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

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

--
AN

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

Вы, возможно, не поняли о чем речь, или я плохо сформулировал. Счетчик тут не поможет. Речь идет не об одном и том же прерывании, а о прерывании работы другого обработчика прерываний. Например, обработчик прерывания в каком-нибудь драйвере ОС, может запрещать прерывания только в своей критической части кода. А дальше - они разрешены, хотя сама процедура обработки прерывания еще не завершена. И вот, в этот неподходящий момент, может возникнуть ваше прерывание, после которого вы не возвращаете управление. Работа драйвера будет нарушена.
P.S. На такие "грабли" лучше не наступать. Замучеетесь искать причину...

Конечно, такая вложенность вполне возможна. И в таком случае в ISR, которая выполняет, назовем
это так, "необычный" возврат, счетчик вложенности > 1, и ISR должна должна выполнить наиболее
подходящие действия. Возможно, что нужно переделать логику у всех возможных ISR - некий
аналог планировщика, который осуществляет только два вида выхода из прерывания - или обычный
возврат или "необычный" возврат на начало loop() .

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

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

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

Про ОС очень хорошее замечание. Сейчас мне кажется, что исходную задачу можно решить
с помощью двух процессов, один управляющий, который или запускает или снимает с исполнения
(фактически, перезапускает) второй процесс, который производит вычисления и управляет внешним
устройством. Я подробно о таком способе пока не думал.

--
AN

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

Почитал я всё вышеизложенное на 3 страницах и решил, что у вас у всех слишком много свободного времени. В ассемблере эта задача решается парой строк. Естественно, этой парой строк можно пользоваться только тогда, когда понимаешь, что далаешь. Но если пишешь на языке высокого уровня, такого понимания никогда не будет. Для справки: на высоком уровне тоже пишу, но меня периодически посещает мысль, что кто-то пытается "держать меня за последнего лоха".

Теперь по сути темы. В одном устройстве у меня была похожая задача. При её решении вместо прерывания я использовал RESET и флаг "горячий/холодный старт".

Это да, С очень способствует экономии времени...

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

"Остапа понесло"

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

Я суть темы понял так: при наступлении некоего события программа переходит на точку "горячего старта". Если же в мои рассуждения вкралась ошибка, то всем приношу свои гоубочайшие извинения за то, что отвлёк от плодотворнейшей дискуссии.

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

Элементарно, Ваттсон... Дедуктивный метод (развитый многолетним программированием на ассемблерах)