Прерывание в прерывании или как их правильно разложить?

[rusyvochka]

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

Дык это меняет дело. Так и зделаю, сенк.

несоблюдения рекомендованных таймингов АЦП

АЦП0 - при INT, После выборки - канал1, а разрешение следующей выборки "аж" при появлении Из (TMR1), по времени всё путём

Контекст надо сохранять один раз, сразу при входе, еще до проверок флагов.

А вот это надо обмозговать на досуге, потому как:
ORG 0x04 ; Вектор прерываний
TST_INT BTFSC INTCON,INTF ; при переходе сетевого через "0"
GOTO INT_A2
TST_PEIE BTFSS INTCON,PEIE ; проверка разрешения прерывания от TMR1
GOTO INT_T0
TST_T1 BTFSC PIR1,TMR1IF ;
GOTO INT_T1
TST_ADC BTFSC PIR1,ADIF ; проверка флага прерывания окончания АЦП
GOTO INT_ADC
TST_T0 GOTO INT_T0
и далее:
INT_A2 MOVLF 0x01,ADCON0 ; нулевой канал АЦП, левое выравнивание, тут, дабы была положенная пауза
MOVWF INT_W
MOVFF STATUS,INT_S
...
...
...
BCF INTCON,INTF
MOVFF INT_S,STATUS
SWAPF INT_W,F
SWAPF INT_W,W ; восстанавливаю контекст
RETFIE ; Возврат из обработчика
и так для каждого прерывания. Это так сейчас есть.
Вектор получен, сквозной проход в прерываниях.... переделаю, сенк.

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

Вот тут могу поделиться своими наработками:
В каком месте полуволны управляющий импульс появится, такой ток и получится.
Не торопитесь...
Были варианты измерять его (ток) сразу после импульса запуска - стабильненько, вот только чего за значение имеем? Мгновенное? Ну на зачем он? При малых токах сия величина "неудобоварима"...
Пробовал измерять впредь до следующего INT (переход через "0") - как бы да, но вот АКБ не есть резистор, на нём есть напряжение, потому если величина напряжения на АКБ больше значения напряжения в точке на ??? парабола перевернутая, что ли, тока нет. Двухлучевиком видно здорово.
Среднее есть интеграл, площадь. Вот и остановился на варианте измерять после импульса, суммировать, пока больше 0 и делить на кол-во измерений. Не совсем по формуле, но самое приемлемое. Вот юстировать проблематично: не один стрелочник / цифровик импульсный ток точно не "покажет". Потому калибровал на нагрузке, рассчитав "ожидаемый".
Повторюсь: к математике и основной задаче вопросов нет, индикация вот хромает.
Но идея озвучена, подправлю - отчитаюсь.
Здесь это обсуждалось

[vavan1983]

Ну и на будущее хотелось бы знать, как правильно обрабатывать несколько прерываний, которые не "терпят" очереди???

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

[NewWriter]

обязательно должно закончить работу

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

[vavan1983]

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

Это да поэтому и существуют флаги прерывания от периферии.

[rusyvochka]

Самый первый пост:
при входе а TMR0, снимаю свой флаг и разрешаю глобальные...
"могут быть" TMR1 и ADC: в АЦП вообще не сохраняется контекст (снял свой флаг, выставил пин и возврат...
В АЦП повторное сохранение контекста в СВОИ временные, дабы не попортить "основние", если прерывание АЦП вызвано во время обработки TMR0. И чего тут страшного? 8 уровней стек... Страницы не перекрываются. Конечно, если посмотреть весь текст программы, то будет видно, что в основной только опрос нажатия энкодера, остальное все в прерываниях.
По INT (прерывания по спаду, фронт - начало следующего полупериода не контролируется) сразу заношу значение для TMR1, пущай считает, а далее "тяжелая математика / конвертирование / дешифрация. Еще и сюда же (по совету бывалых) переместил задвигание в 595 - вообще все замечательно стало. При самой "длинной" обработке (раз в 16 INT_ов) почти 0,1мс. До TMR1IF - еще уйма времени, даже для макс. тока.
На сегодня - если между INT "короткие" обработки, то и все в целом нормально, а вот "старый" вариант (прерывание в прерывании) жизнеспособен, но громоздкий. Все таки оставил 12 смен разрядов, гашение, и ожидание разрешения следующих двух проходов после INT. Не бросайте камни - ну симпатичнее так. Все таки 450 мкс в INTe на постоянной смене разрядов выглядит как пробегающий (ну на какой попадет) яркосной блик (а как еще это обозвать). В целом ответы получены, советы приняты в работу. Всем сенк! Еще есть идеи - всегда рады!

[vavan1983]

Самый первый пост:
при входе а TMR0, снимаю свой флаг и разрешаю глобальные...
"могут быть" TMR1 и ADC: в АЦП вообще не сохраняется контекст (снял свой флаг, выставил пин и возврат...
В АЦП повторное сохранение контекста в СВОИ временные, дабы не попортить "основние", если прерывание АЦП вызвано во время обработки TMR0. И чего тут страшного? 8 уровней стек... Страницы не перекрываются. Конечно, если посмотреть весь текст программы, то будет видно, что в основной только опрос нажатия энкодера, остальное все в прерываниях.
По INT (прерывания по спаду, фронт - начало следующего полупериода не контролируется) сразу заношу значение для TMR1, пущай считает, а далее "тяжелая математика / конвертирование / дешифрация. Еще и сюда же (по совету бывалых) переместил задвигание в 595 - вообще все замечательно стало. При самой "длинной" обработке (раз в 16 INT_ов) почти 0,1мс. До TMR1IF - еще уйма времени, даже для макс. тока.
На сегодня - если между INT "короткие" обработки, то и все в целом нормально, а вот "старый" вариант (прерывание в прерывании) жизнеспособен, но громоздкий. Все таки оставил 12 смен разрядов, гашение, и ожидание разрешения следующих двух проходов после INT. Не бросайте камни - ну симпатичнее так. Все таки 450 мкс в INTe на постоянной смене разрядов выглядит как пробегающий (ну на какой попадет) яркосной блик (а как еще это обозвать). В целом ответы получены, советы приняты в работу. Всем сенк! Еще есть идеи - всегда рады!

Вам бы на язык программирования С перейти с вашими стараниями.

[rusyvochka]

Вам бы на язык программирования С перейти с вашими стараниями.

Были попытки - не осилил. У кого то б за спиной постоять, подсмотреть - может и пошло бы. По "букварям" результат =› хрень. Пробовал и графические редакторы, который с граф. алгоритма переводят в маш. код. Опять же на результат в асме посмотрел - ну кто ж так строит. Да всё очередно и работоспособно. Но... Я б такие "петли" и в страшном сне не придумал. Ежели 20 мГц кварц - еще терпимо, при внутреннем 4 - ужасно (в железе). Сие для последовательных задач классно. Старт - пост чуть о другом...
Вот только не надо сразу посылать к 18 серии - "я его лепила, из того, что было". Скажем так - заставить работать медленное и простое, быстрое само заработает...
P.S. сие занятие приравнивается к хобби, хотя и перекрещивается с основной работой. Вдруг на будущее пригодится.

[NewWriter]

Для мелких пиков со слабыми ресурсами ассемблер - самое то! Все равно Си будет все действия выполнять только в пределах ограниченного набора инструкций МК. А их всего 35 - не развернешься. Хотя Си допускает ассемблерные вставки.

заставить работать медленное и простое, быстрое само заработает...

А может хватит уже мучить эти несчастные мелкие МК? Это ж сколько времени и сил теряется на то, чтобы всё это утолкать.
Ну а если всё-таки мучить их, то надо развивать отменное алгоритмическое мышление. Потому как вся фишка - именно в умении построить оптимальный алгоритм.
Нужно абстрагироваться от команд МК и составить алгоритм работы в виде "кубиков". А для этого нужно знать тонкости работы внутри каждого "кубика".
Ну вон Flowcode так делает. Но можно и самому на бумажке.
Я заметил еще с самого первого поста, что основная беда в этом устройстве - это неправильный алгоритм. И возможно ошибка где-то еще в самом начале, в схеме, в способе съема параметров...

Вдруг на будущее пригодится

чтобы пригодилось на будущее, надо идти в ногу со временем, а не догонять его

[rusyvochka]

чтобы пригодилось на будущее, надо идти в ногу со временем, а не догонять его

А можно еще купить готовое и не парится. САМОцель - нае... обдурить, в общем.
По алгоритму - таки да, после "тыканья" пальцем, поправил, стало нравится лучше.
Как его не оптимизируй, а деление двухбайтного на однобайтное при 35 командах (хотя их пяток задействовано) всеравно время займет. Се ля ви. Имеем то, что имеет нас.
А в целом, не ждал такого участия в обсуждении. Спасибо что не "затюкали" со старта.

[STM32F0]

Были попытки - не осилил.

Это что расписаться в собственном бессилии.

сие занятие приравнивается к хобби, хотя и перекрещивается с основной работой.

Тем более! Никто не мешает вам попробовать Мегу или СТМ8. Зачем же себя так ограничивать? И вот здесь сразу и поймёте, для чего СИ придумали.

Для мелких пиков со слабыми ресурсами ассемблер - самое то! Все равно Си будет все действия выполнять только в пределах ограниченного набора инструкций МК. А их всего 35 - не развернешься. Хотя Си допускает ассемблерные вставки.

Прикольно. Можно подумать АСМ расширяет количество инструкций МК. Для древних ПИК-маломерок хорош старый Хай-Теч Стандарт. Новые уже особого смысла юзать и нет.

надо идти в ногу со временем, а не догонять его

Ну тогда СИ и увы не ПИК-Мега.