Регистр FSR и команды с обращением к INDF...
Классика основ...

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

И кстати, там в "творчестве" ты вроде как 16 бит делишь на 256 (через 8 сдвигов) ... просто, скопируй старший в младший ... А вообще, довольно странно, что приходится делить на 256 ...

BOB51 уже сказал, но добавлю, что это называется работой с указателями. То есть с косвенной адресацией. Изменяя адрес - изменяешь переменную. А сама математика остается прежней.
И еще. АСМ - это канешна хорошо, но дело в том, что для понимания смысла инструкций (почему они именно такие, а не другие), требуется познакомится с языками более высокого уровня. Например с Си. Патамшта систему команд МК ориентируют для работы с компиляторами языков высокого уровня. И принципы программирования нужно осваивать не на уровне АСМа, а глобально, с помощью ЯВУ. Тогда даже смена платформы не вызовет судорожного поиска привычных инструкций.

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

Логично!

Потому что макс значение предделителя TMR0 такое viewtopic.php?f=58&t=125684&p=4597015#p4597015

Для предыстории
viewtopic.php?f=58&t=125684&p=4455904#p4455904
tож - toff, tвкл - ton, tзад - AA, всё это вычисляется из периода между импульсами Т, всё 16 бит
По сигналам на ножках делается куча других действий (соответствие вход-выход, запуск таймеров и т.д.), которые описывать словами повесишься. А между сигналами вычисления, на основе измерения в предыдущем периоде.

Так вот на основании предыдущего периода TH:TL надо вычислить предделитель и само значение TMR0 для ton


потом на основе опять того же предудущего TH:TL и кучи других постоянных значений вычислить УОЗ (АА)


Потом на основе опять того же предыдущего TH:TL и свежевычисленных AA && ton вычислить предделитель и само значение TMR0 для toff

Это один период, в следующем повтор

закодированный Коэф в OPTION:0:[PS2:0] - 111=256, 110=128 etc
Всё вычисляется на основе только измеренного таймером TMR1 TH:TL и табличных DPZ && RPM
Уф, 5 часов рожал этот текст... С перерывами, конечно. Всё, больше не просите))
Это алгоритм работы зажигания ДВС с индуктивным накоплением, описать его словами не возьмусь, тем более специфика PIC.

Что уже накропал, кроме вышеописанного:

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

В целом (по движку) я понимаю так - есть импульс, так или иначе синхронизированный с вмт, и есть угол, связанный (линейно?) с текущим периодом (оборотом, или двумя...) ... например, если между прошлыми вспышками прошло 100мс и это как раз полный оборот (360) или два (720), то и следующая будет через это время, а сдвиг уоз на этой частоте (при этом периоде) допустим должен быть -10 градусов ... получается, 360 это 100мс, а 10 это 1000/360 =~2.8мс ... следующую искру будем делать через 100-2.8=97.2мс, а это значит, если сразу по факту прошлой вспышки мы загрузим таймер на 97.2, то когда он досчитает до нуля мы получим момент необходимости подать импульс на катушку, ну или немного раньше, учитывая необходимость накопления ... Короче, так или иначе, чем лучше представляешь задачу, тем проще алгоритм получается.

Там ещё ты писал, что придумал некий способ сделать tmr0 16-ти битным ... вникнуть не удалось, но с другой стороны там вроде нечего придумывать - если, скажем, надо досчитать до пары миллионов, ну так добавь к tmr0 парочку своих регистров в качестве старших байтов - вот тебе и таймер на 24 бита...

насчет твоего кода - кроме тебя его все равно никто не поймет. Это не так то просто - разобраться в чужом творчестве.
к примеру, посмотри вот этот исходник:

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

У меня другой алгоритм. Так как надо высчитывать ещё время накопления энергии в бобине, это TCI, а не CDI конденсаторное, где высек искру и забыл.

Запаришься прерывания отрабатывать, а при моём способе они не чаще, чем у 16-битного.

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

Он у всех другой, в силу множества факторов. Но тем не менее для какой-то конкретной задачи существует только один вариант максимально эффективной реализации этого самого алгоритма.

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

а сначала получать откуда-то некое 16-ти битное значение, а потом урезать его до 8бит с помощью портянки сдвигов - не особо запаривает?
Сейчас кроме сохранения контекста, в ПП (подпрограмма прерывания) ничего нет. Это означает, что в твоем кода нет четкой синхронизации по времени, нет аппаратной реакции на внешние асинхронные события, которыми могут быть - спад по int, изменение на portb, изменение на выходе компаратора, по захвату на rb3 ... а это означает, что ты это всё, если и делаешь, то вручную, с помощью лишних опросов/сравнений ... - не запарился так?
Прерывания - это точно такая же подпрограмма, как и любая другая (зашел - вернулся). Участок кода (твоего кода) с фиксированным лишь начальным адресом, не более того. Главное отличие - аппаратный вызов. Именно поэтому необходимо сохранение некоторых регистров - тех, которые могут быть "испорчены" в ходе исполнения ПП.
Короче, если те или иные задачи можешь повесить на аппаратную часть - с этого и начинай. Например, настраиваешь tmr1 и модуль сср на захват ... и вот по каждому фронту(или спаду) от датчика, тебя незамедлительно доставляют по адресу 04, а в регистрах ccpr1h,ccpr1l уже лежит нужное тебе значение ... делай с ним что хочешь ...- ну красота же.

ну почему, кое-какие пометки все равно делаю ... но так чтоб на каждой строчке - это уже лютый перебор

Сколько раз уже говорено:
начинать надо с хорошо расписанного простыми словами алгоритма...
А уже под то описание можно и МК с удобной аппаратной начинкой и раскладкой выводов подобрать и программу в любом компиляторе написать.

Хорошо искрить ещё лучше)) ®

От оборотов стола? Это уже столоверчение)) Стол, двигатель, бобина, искра... Не, стол тут лишний)) А если честно, совсем не понял...

Ну что делать, если нет свободного 16бит таймера, а имеющиеся в наличии PIC-и надо утилизировать.

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

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


Да это я в курсе.

Добавлено after 5 minutes 45 seconds:
Алгоритм в голове, слов не хватает)) У меня этих "коммутаторов" 3 штуки, у народа на другом сайте тоже имеется, все должны переделывать? Следующая версия будет на другом железе.

Пустопорожнее убивание времени.
Нужно МК выбирать под задачу, а не наоборот.

Когда слов для описания хватит, тогда и с программой дела намного быстрее пойдут.

Любой таймер можно создать программно.
Вопрос только в минимальном размере обработки прерывания от системного генератора интервалов и самого счётчика (зависит от математики и количества разрядов счётчика).
DDS кстати тоже на программных счётчика и математике делается.
Насчёт "утилизации имеющегося" - тут вопрос заметно сложнее.
Не слишком удачный выбор МК гарантирует кучу проблем (порой не решаемых для данного кристалла).

а каков, кстати диапазон временных интервалов, которые требуется отсчитывать?
Где-то выше вроде было про 6000об/мин ... значит 10мс - длительность одного оборота. Вот и узнали минимальный интервал ... если считать с разрешением в 1мкс, то соответственно насчитаешь 10000
А что насчет минимальных оборотов? 60? - хорошо, пусть будет 60 ... =1об/сек ...1сек-длительность оборота- наш максимальный интервал (1 000 000 мкс) ... tmr0 у нас каждые 256мкс вызывает прерывание и там прибавляем единичку к нашей паре регистров ... и вот одним tmr0 мы считаем весь диапазон с разрешением в микросекунду ...

Это надо обдумать...

Добавлено after 36 minutes 40 seconds:
6000об/мин * 2цилиндра = 5мс период полуоборота


При дёрге верёвкой за маховик или пинке по кику 300об/мин считается, на ХХ 800-1000. То есть ты намекаешь, что можно обойтись 8 битными значениями?

вчера ещё подумал, что речь похоже про какой-то "юпитер"...

Сколько цилиндров особо значения не имеет ... коленвал то один, и мы говорим о его оборотах ...

какой ещё намек, какие 8 бит ...? ты считаешь секундный интервал тиками по одной микросекунде ... до скольки досчитаешь, сколько в секунде микросекунд? -очевидно же что - миллион ... Миллион -это 24 бита

можно обойтись и одним битом, максимальное значение чего-то измеряемого притом не имеет значения.

Почти угадал, Юпитер в планах, а вот мой насущный агрегат, последние снимки, и лодка это именно мои. На нём даже первый вариант процессорного зажигания, сбоку на открытой печатке))
https://motorka.org/motory/podvesnie_lo ... et-25.html


Ну можно говорить и о циклах зажигания, кои по пол-оборота. В кои я собираюсь уложиться.


Зачем секундный интервал, я так и не понял. Если 65мс полупериода - это где-то 500 оборотов, а тем более ниже 1000 вычислять УОЗ не надо, он фиксированный около нуля.

Добавлено after 2 hours 8 minutes 26 seconds:
А mpasm, когда сыплет напоминаниями насчёт смены банков, может реально отслеживать необходимость их смены?

mpasm внутри мплаба контролирует соответствие регистра текущему банку.
Да и по карте в документации на МК эта информация всегда представлена.

Если перед каждым обращением к ОЗУ и периферии ставить banksel, то варнинги пропадут.
Но их можно отключить радикально директивой errorlevel -302 в начале листинга.
Естественно. что варнинг это не ошибка. И mpasm не контролирует текущее значение RP0...RP1, поскольку он ничего не знает про рантайм. Он тупо генерирует варнинги, если НЕПОСРЕДСТВЕННО ПЕРЕД обращением нет директивы banksel.

То есть в этом случае, пример из доки:

компилятор перед MOVWF сам проставит биты выбора нужного банка? Где объявлена Var1?
То есть просто знай напихивай её в сомнительных местах, эффект будет тот же, что и вручную ставить биты банков?