Вопросы начинающих PIC ASM

[yor]

А если работают два таймера, и оба могут сработать одновременно, или почти одновременно? pic16f648 TMR1 TMR2 в режиме таймеров, то есть считают до конца (TMR1 до FFFF, TMR2 до совпадения с PR2). Оба закончили в один момент. 1) Инициируется прерывание. В обработчике всё равно определится, что один пойдёт первым.
Сброс GIE
Определение сработавшего таймера, например TMRx
ОБработка TMRx
Взвод GIE
Что будет со вторым? TMR1 продолжает от нуля, (или TMR2 дальше PR2 шпарит), флаг прерывания поднят, снова тут же прерывание? Или надо сразу в одной процедуре оба обрабатывать? А если второе чуть позже, можно ли потерять прерывание?

2) Или влетели мы в прерывание по одному таймеру, и не запрещать GIE, обработка прервётся другим, а потом вернётся к первой?

3) Или влетели мы в прерывание по одному таймеру, запрет GIE, обрабатываем, и тут сработал второй. Взвод GIE, второе прерывание, а таймер-то ушагал уже.
Так? Или что не так?
В общем, как быть, если есть риск одновременного или близкого срабатывания таймеров по прерыванию?

[КРАМ]

Кто вас научил дергать GIE в прерывании? Вы понимаете смысл этого?
Ну и в чем смысл всех этих игрищ с парой таймеров?
Лучше опишите конечную задачу, а не фантазируйте.

[BOB51]

У каждого семейства МК свои плюсы/минусы и ограничения.
У стандартных среднемладших и стек не слишком велик и работа с прерываниями довольно сложна.
Однако есть и "улучшенная среднемладшая" и 18я серии - там заметно полегче.
Да и иных семейств МК в достатке.
Выбираем то, что соответствует конкретной задаче или корректируем саму задачу под имеющийся МК.
Добавляем в сзему внешние микросхемы/МК со специфическими свойствами, дабы облегчить работу основного МК.
Это и есть ТВОРЧЕСТВО.

[yor]

КРАМ писал(а):

Кто вас научил дергать GIE в прерывании? Вы понимаете смысл этого?

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

КРАМ писал(а):

Ну и в чем смысл всех этих игрищ с парой таймеров?
Лучше опишите конечную задачу, а не фантазируйте.

Это мотор внутреннего сгорания, зажигание с индуктивным накоплением, обороты 0-6000, tзад (опережение зажигания, УОЗ) от 0 на минимальных оборотах до какого-то значения, зависит от оборотов (периода). tвкл - время накопления (включена катушка зажигания), тоже зависит от оборотов. Ну и выдержка tож=T-tвкл-tзад.
Искра по окончанию tвкл, может быть вплоть до заднего восходящего фронта импульса датчиков.

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

[КРАМ]

yor писал(а):

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

Лютый бред.
Вы вообще не понимаете как работает контроллер прерываний МК.
Абисняю.
При взведении любого флага и наличии разрешения этого флага, а так же групповых разрешений PEIE и GIE возникает генерация прерывания. Поскольку вектор прерываний в обсуждаемой архитектуре ОДИН (0х0004), программа уходит на этот единый адрес и глобальное разрешение GIE АВТОМАТИЧЕСКИ ЗАПРЕЩАЕТСЯ. То есть ваши потуги с этим битом в части его выключения абсолютно бессмысленны.
Далее на входе в обработчик должен находится код сохранения контекста ядра (WREG и STATUS, а так же опционально PCLATH), а вслед за ним (при работе с более чем одним источником прерываний) СЕМАФОР обработчика, который ПОСЛЕДОВАТЕЛЬНО опрашивает все возможные используемые флаги прерываний, а при определенных случаях еще и разрешения по этим флагам, и перенаправляет код в обработчик по конкретному флагу, где этот флаг и сбрасывается тем или иным методом. На выходе из общего обработчика контекст восстанавливается и выход в основной код ОБЯЗАН производится инструкцией retfie, которая в отличии от похожей на неё инструкции return, ОДНОВРЕМЕННО с возвратом в основной код РАЗРЕШАЕТ ГЛОБАЛЬНЫЕ ПРЕРЫВАНИЯ, то есть попросту устанавливает бит GIE в единицу.
Если бит GIE установить руками перед выходом из прерываний, то если какой то из флагов останется взведенным, немедленно будет сгенерировано ВЛОЖЕННОЕ прерывание, а поскольку стандартное сохранение контекста поддерживает лишь один уровень, то контекст будет испорчен и программа станет неработоспособна в целом.

yor писал(а):

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

Херня какая то...
Период измеряют посредством TMR1 в режиме ЗАХВАТА. То есть это аппаратный процесс и ему болт положить на прерывания и задержки, если только код успевает считывать данные захвата между этими захватами. Реальное время измерений всегда будет равно разности нового и прежнего значения захвата.
Если события прерываний будут сгенерированы одновременно от разных источников, то последовательность их обработки зависит от порядка опроса флагов в СЕМАФОРЕ обработчика. При завершении обработки текущего обрабатываемого флага код выйдет из обработчика и, поскольку необработанные флаги остались взведенными, немедленно зайдет снова в прерывание и обработает следующий флаг по порядку семафора. И так до тех пор, пока все флаги не будут обработаны.
Сократить время задержки на все это мероприятие в обсуждаемой платформе ПРИНЦИПИАЛЬНО НЕВОЗМОЖНО.
Если такая необходимость есть, нужно сменить платформу на ту, которая имеет приоритетную архитектуру контроллера прерываний МК, либо имеет нативную вложенность прерываний (например как NVIC в ARM-ах).

Последний раз редактировалось КРАМ Ср авг 02, 2023 13:06:13, всего редактировалось 1 раз.

[yor]

КРАМ писал(а):

Вы вообще не понимаете как работает контроллер прерываний МК.
Абисняю.

Абиснили. Спасибо. Но факт сброса GIE подтвердился, и когда я начну писать непосредственно код, я эти тонкости просеку. Надеюсь.

КРАМ писал(а):

Период измеряют посредством TMR1 в режиме ЗАХВАТА.

Почему только TMR1? Почему не TMR2?

КРАМ писал(а):

Если события прерываний будут сгенерированы одновременно от разных источников, то последовательность их обработки зависит от порядка опроса флагов в СЕМАФОРЕ обработчика. При завершении обработки текущего обрабатываемого флага код выйдет из обработчика и, поскольку необработанные флаги остались взведенными, немедленно зайдет снова в прерывание и обработает следующий флаг по порядку семафора. И так до тех пор, пока все флаги не будут обработаны.

Вот это и есть ответ на изначально заданный вопрос про потерю прерываний. Ещё раз спасибо. Только непонятно, зачем Вам понадобились подробности задачи?

[КРАМ]

yor писал(а):

Почему только TMR1? Почему не TMR2?

Патамушта захват (он 16-битный) есть только на базе TMR1. А на базе TMR2 есть только 10-битный ШИМ.
Откройте наконец даташит на МК и ознакомьтесь с его содержимым.

yor писал(а):

зачем Вам понадобились подробности задачи?

Затем, чтобы вы задали мне вопрос про TMR2...
Следите за логикой разговора...

[BOB51]

Говорят же - задачи можно решать разными способами.
Можно на аппаратные средства нажимать, а можно и на программные - зависит от параметров времени исполнения и прочего.
Как вариант - на таймере "тикалка", а контроль значений (состояния ввода/вывода) программный через интервал "тикалки".
Да много чего еще...

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

[КРАМ]

BOB51 писал(а):

Теоретически

Вот именно поэтому НЕВОЗМОЖНО ПРИНЦИПИАЛЬНО. Ибо то, что бессмысленно, можно считать невозможным.

[BOB51]

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

[yor]

КРАМ писал(а):

yor писал(а):

Почему только TMR1? Почему не TMR2?

Патамушта захват (он 16-битный) есть только на базе TMR1. А на базе TMR2 есть только 10-битный ШИМ.

Я неполностью описал задачу. Много гитик. Опрос фронтов программный, вроде в этом МК один внешний вход прерываний, а датчика два, да и разводка уже сделана не так. Да и 8 бит достаточно, с пред- и постделителями.

КРАМ писал(а):

Откройте наконец даташит на МК и ознакомьтесь с его содержимым.

Знакомлюсь помаленьку, всё сразу не упомнишь.

[BOB51]

Датчики в виде мехконтактов с "дребезгом"?

[yor]

Дребезг вполне программно давится. Тем более что тут входы вроде с триггерами Шмитта. Но у меня оптодатчики))

[BOB51]

ну тогда вообще никаких вопросов.

[yor]

А можно ли из простой подпрограммы вместо return возвращаться по retfie, чтоб заранее сброшенный GIE автоматом взводился? Вроде не вижу препятствий.

[КРАМ]

yor писал(а):

А можно ли

Зачем?
Вы хотите сэкономить одну инструкцию?
Весь смысл retfie в одновременности возврата и установки флага, чтобы обеспечить корректность обработчика прерываний.
А так, да можете писать все что угодно в коде.

[yor]

КРАМ писал(а):

Вы хотите сэкономить одну инструкцию?

А почему бы и нет? Копейка рупь бережёт.

[КРАМ]

yor писал(а):

Копейка рупь бережёт.

Даже не буду учитывать, что выключение прерываний в коде основного цикла - это крайне редкое мероприятие, экономить ОДИН машинный цикл на выходе из такой функции просто гомерически смешно. Вы сначала научитель писать адекватный алгоритм, в котором нет избыточного кода, а потом будете экономить 100 нс непонятно на чем.
Ваши планы пока выглядят как клоунада.

[yor]

Повеселить людей тоже неплохо. Совмещая с образованием. Но кроме Вас, вроде, никто не смеётся. Надо прибавить усилий))

[КРАМ]

Остальные просто не успели прочесть...

Однако по существу добавлю.
Дело в том, что прерывания в МК применяют для реализации задач реального времени. А это значит, что следить нужно за минимальным временем РЕАКЦИИ НА ПРЕРЫВАНИЯ (СОБЫТИЯ). Запрет прерываний с основном цикле увеличивает это самое время. Но иногда необходим для обеспечения атомарности некоторых операций.
В этом смысле замена двух инструкций на одну выглядит как УХУДШЕНИЕ ситуации. Патамушта отдельное разрешение прерываний будет БЫСТРЕЕ на один машинный цикл возвращать коду возможность реагировать на события. Ибо retfie выполняется ДВА машинных цикла.
Экономить на основном цикле бессмысленно, потому как он и так никогда не загружен на 100%. Более того, он, как правило, не загружен даже на треть.
Такшта ваши глупости - они такие глупости...