Боже мой, и никто не сказал, что всего-то надо заменить адрес возврата в стеке на желаемый и выйти тем же reti.Хочется, чтобы после события начинал исполняться другой кусок программы, а не тот из которого вышли в прерывание.
Вы же не с компьютера писали, вот и не смогли опередить akl. А вот за утверждение чего-то с отправкой в гугл искать доказательства того, что вы утверждаете спасибо не говорят. А akl как раз привёл фрагмент документации, где всё чётко написано. За это я ему спасибо и сказал. 
Так функций много будет, их уже 4 и потом уверен, что придумаю новые.da-nie писал(а):А что мешает внутри каждой команды проверять кнопки и выходить наружу?то бишь каждая команда выполняется как отдельная функция и длится 10 секунд * каунтер.
Да, пример отличный, логика понятнаCOKPOWEHEU писал(а):Или сделать для каждого эффекта конечный автомат. Вот пример для более многоногого контроллера, демонстрация принципа.
Так берите их и копируйте общую часть. Или вставьте её в отдельную функцию обработки кнопок, а в рабочей функции просто анализируйте, пора выходить или нет.Так функций много будет, их уже 4 и потом уверен, что придумаю новые.
А, ну да. Вам подскажи, где копать, потом выкопай за Вас. Потом принеси, в рот положи. Логика понятна.da-nie писал(а): А вот за утверждение чего-то с отправкой в гугл искать доказательства того, что вы утверждаете спасибо не говорят.
Не отличается результат, а вот сам принцип позволяет добавлять куски кода, выполняющиеся "параллельно" с другими, правда если они будут сильно нелинейными по времени (занимать разное время при разных условиях) стоит озаботиться синхронизацией по таймеру.Miw писал(а):Да, пример отличный, логика понятна
На самом деле, это ничем не отличается от обработки нажатий в каждой функции, или я чего-то не понял?
У них столько отличий, что отсутствие аппаратного умножения выглядит не существеннее отсутствия UART'а или нескольких таймеров.ARV писал(а):На счет разницы между мегой8 и тини13 никто не сказал, что тинька не имеет аппаратного умножителя и еще ряда команд.
Подсуньте инструкции RETI нужный адрес возврата, и будет Вам счастье!Miw писал(а):Собственно вопрос - можно ли уйти из прерывания по rjmp ? Как нужно почистить стек ?
Код: Выделить всё
; Непосредственно перед RETI:
POP R16
POP R16
LDI R16, High ( Label_Where_to_Jump )
PUSH R16
LDI R16, Low (Label_Where_to_Jump)
PUSH R16
[b]RETI[/b]
; Мог перепутать порядок младшей и старшней половин адреса, но это легко проверить и поправить
Кто утверждает, тот и доказывает.А, ну да. Вам подскажи, где копать, потом выкопай за Вас. Потом принеси, в рот положи. Логика понятна.
Это первое. Вот когда самоутверждаются, тогда, обычно, не стремятся объяснять что, как и почему. Типа, сами найдёте, о чём я говорю. А вот когда хотят показать что-то, тогда приводят ссылки, документацию, объясняют что да как. А если же не могут привести эти данные, то сообщают об этом. Это правила хорошего тона.Боже, не надо этого делать!Подсуньте инструкции RETI нужный адрес возврата, и будет Вам счастье!
Я за 20 лет написания программ, большего извращения, чем прыгать из прерывания куда угодно, не видел. YS писал(а):Боже мой, и никто не сказал, что всего-то надо заменить адрес возврата в стеке на желаемый и выйти тем же reti.
А в чем преимущество перед простым прыжком?Deer писал(а):Подсуньте инструкции RETI нужный адрес возврата, и будет Вам счастье!
Когда делал модель операционной системы с вытесняющей многозадачностью так и поступал - адрес прерываемного процесса сохраняется в стеке, затем указатель стека меняется на новый процесс и загружается его адрес.da-nie писал(а):Боже, не надо этого делать!
Правильно, вы фактически контексты процессов переключали. Но вы всегда возвращались к прерванному процессу - вы просто давали им работать по-очереди. А здесь такого не будет. Здесь прерванная функция никогда более не вернётся в точку прерывания.Когда делал модель операционной системы с вытесняющей многозадачностью так и поступал - адрес прерываемного процесса сохраняется в стеке, затем указатель стека меняется на новый процесс и загружается его адрес.
Не портится стек, автоматически обрабатываются флаги статуса. При простом прыжке в стеке повиснет контекст прерванного процесса и, как следствие, станет неверным указатель стека.А в чем преимущество перед простым прыжком?
У-у-у, не факт.Здесь прерванная функция никогда более не вернётся в точку прерывания.
У-у-у, не факт.
Не, ну вероятность этого есть, но такая маленькая. Я же приводил кусок кода с очисткой стека и восстановлением флага прерываний. А чему там еще портиться?YS писал(а):Не портится стек, автоматически обрабатываются флаги статуса. При простом прыжке в стеке повиснет контекст прерванного процесса и, как следствие, станет неверным указатель стека
Придумать применений можно много, вот только насколько часто они оправданы? А то могу предложить найти применение еще одному извращению - выбору одного из нескольких вариантов одного прерыванияНо вообще да, игры с адресами возврата - запутанное дело, к которому надо подходить предельно аккуратно, чтобы не попортить память и логику программы. Если цель - просто менять логику работы в зависимости от внешних воздействий, то здесь самое милое дело - конечный автомат. Я так навскидку даже не могу сказать, где может быть нужно вот так брутально колупать стек, кроме ядра ОС.
Код: Выделить всё
.org 0x0000
rjmp RESET
.org 0x0001
ijmpКод: Выделить всё
.org 0x0000
rjmp RESET
.org 0x0001
rjmp ANY_INT
...
ANY_INT:
push r16
in r16,SREG
cpi flag,0
brne ANY_INT_1
rjmp INT_1
ANY_INT_1:
cpi flag,1
brne ANY_INT_2
rjmp INT_2
out SREG,r16
pop r16
reti
INT_1:
...
out SREG,r16
pop r16
retiНе, ну все можно поправить, конечно. Но тогда этим специально надо заниматься.Я же приводил кусок кода с очисткой стека и восстановлением флага прерываний. А чему там еще портиться?
Код: Выделить всё
Main_loop:
if Button1_Pressed - next эффект
if Button2_Pressed - запрет автоматических переключючений эффекта
if Button1_Hold - запрещаем мигание (нечетные эффекты). То бишь next эффект если надо
if Button2_Hold - rjmp Reset
if Timer на один эффект - next эффект
switch (по эффекту)
rcall эффект1
rcall эффект2
...
rjmp Main_loop
По размеру кода и скорости это не хуже, чем запись в стек и reti.YS писал(а):Не, ну все можно поправить, конечно. Но тогда этим специально надо заниматься.
Зависит от реализации эффектов. Если каждый эффект зацикливается на 5 сек - да, если выходит после каждого кадра - нет.Miw писал(а):Так, хорошо, делаем вот такой алгоритм
...
то значит по нажатию кнопки 5 секунд ничего и не будет происходить. Верно ?