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

[BOB51]

ну... ну... ну тогда я не знаю, как быть

Читать учебники по навыкам сбора, систематизации и анализу информации.

Steppe
В каждом МК всегда будут неиспользуемые в конкретной конструкции режимы работы и аппаратные модули.
Перечитывать ВСЁ в таком случае весьма избыточно.
Насчёт смены поколений МК и семейств (даже с учётом некоторой преемственности) то минимум раз в год новинки в серию запускаются. Функции начальной конфигурации давненько уже вручную мало кто делает - пользуются готовым софтом не вникая в подробности (т.е. не вычитывая документацию МК). И только при возникновении проблем к букам обращаются. И плюсы в том и минусы.

[КРАМ]

[uquote="Steppe",url="/forum/viewtopic.php?p=4592236#p4592236"]Позвольте мне не согласиться с таким утверждением.
....... ничего путного никогда не создать.[/uquote]

"Не ищи дурее себя..." (с)
В очередной раз повторяю поговорку моего тестя...
Ваш опыт канешна бесценен, но недостаточен, чтобы нравоучить.
Классический случай проблемы связанной с отсутствием входной защелки В СТАРЫХ МК Микрочипа - программная эмуляция 1Wire и I2C.
Не нужно просаживать выходы, достаточно применить open drain. Рассказать вам как это происходит?
Абисняю.
Ноль пишут в выходную защелку порта PORTx, а вывод осуществляют с помощью TRISx.
Надеюсь вы догадались как быстро в порт будет перезаписана единица вместо нуля?

Ну и в догон напомню вашему бесценному опыту, что в 18-х пиках и, тем более, в дспиках всегда имеется отдельная защелка у выхода и отдельная у входа. Поэтому там такого конфликта не может быть по определению.
[uquote="yor",url="/forum/viewtopic.php?p=4592171#p4592171"]А, я понял![/uquote]
Нет, вы ничего не поняли.

[Steppe]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4592242#p4592242"]"Не ищи дурее себя..." (с)
В очередной раз повторяю поговорку моего тестя...[/uquote]
Вот на этой сладкой парочке и остановимся...

[BOB51]

Разновидность (вариации на тему) DDS?...

[yor]

Это прямой цифровой синтез? Я и слов таких не знаю))
Человек изобрести может всё, но кто ж виноват, что всё изобретено до нас))

[BOB51]

Ну вроде того...
таймер 8 разрядный счетные тики дает, а программный обработчик заданную частоту высчитывает.

[yor]

Есть ли какие тонкости с WDT, или просто настроить его и сбрасывать по ходу программы, пока не истекло время?

[Steppe]

[uquote="yor",url="/forum/viewtopic.php?p=4594214#p4594214"]Есть ли какие тонкости с WDT, или просто настроить его и сбрасывать по ходу программы, пока не истекло время?[/uquote]
Есть. Все они описаны в datasheet

[yor]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4436367#p4436367"]избегайте блокирующего кода. То есть такого кода, который занимает много времени на свое исполнение. Любой код должен вызываться из пустого цикла, исполняться и возвращать управление в пустой цикл. Пустой цикл - это основной внешний цикл работы МК из которого вызываются все функции.
На ассемблере PIC-ов это выглядит так:

Код: Выделить всё

Superloop:
        call    Func1
        call    Func2
        call    Func3
..
        call    FuncN
        goto  Superloop

Func1:
......
       return

Func2:
......
       return

Func3:
......
       return

...................
...................
...................

FuncN:
......
       return

На фоне работы этого кода могут генерироваться и вызываться прерывания, обработчики которых являются отдельным кодом.[/uquote]Это пример идеальной программы? В смысле сферической в вакууме? В мало-мальски сложной программе скорей всего (и даже точно) надо будет по результатам выполнения FuncN прыгать в разные места, крутиться и вертеться как волчок. Мне кажется, что очень трудно, если вообще возможно, оформить чисто в таком виде. Без вставок проверок условий и т.д. рутины.
Вопрос вызван вот чем:

Код: Выделить всё

; RA2 изменил уровень, как? Спад или подъём? Факт смены уровня подразумавает инверсию D1 in Dlvl
; Просто инвертируем его, если был 0 -> 1 && call RearFront, 1 -> 0 && call FwdFront
<------>movlw<->0x4<---><------>; вес D1
<------>xorwf<->Dlvl,f<><------>; инверсия D1
<------>btfss<->Dlvl,D1
<------>call<-->FwdFront
[<----->goto<-->scanD]
<------>call<-->RearFront

Не могу сообразить, как после проверки btfss пройти на два последовательных вызова ПП? После первой не надо вызывать вторую. Но если вставить goto, то на него сразу уйдёт вместо второго call. Подскажите пож-ста, какая тут есть хитрость.

[yor]

Оба подряд никак нельзя. От условия btfss<->Dlvl,D1 зависит, какую вызывать. Или первую, или вторую. Возможно в первой перед return прибавить единицу к РС, чтобы возврат произошёл за вторым вызовом? Пока ничего другого не придумал.

[yor]

Ах ты ж, хлопаю себя по лбу, сто раз так делал)) А всё-таки разобраться для порядку, возможно ли в первой call перед return прибавить единицу к РС (косвенно), чтобы возврат произошёл за вторым вызовом? Выигрыша тут никакого, что там лишняя команда (а может и не одна), что тут, но всё-таки?

Добавлено after 1 hour 7 minutes 48 seconds:
А по размышлению, лучше сделать вызовы обеих процедур не по call, а по goto. Вызываются они всегда из одного этого места, уходят тоже всегда только в одно другое. Так смысл CALL? Правильно?
Это всё вы меня тут сбили с панатлыку))

[BOB51]

Не мешает посмотреть поведение PCLATH<4:3>...

[КРАМ]

[uquote="yor",url="/forum/viewtopic.php?p=4595879#p4595879"]лучше сделать вызовы обеих процедур не по call, а по goto. Вызываются они всегда из одного этого места, уходят тоже всегда только в одно другое. Так смысл CALL? Правильно?[/uquote]
Нет, не правильно.
Алгоритм должен быть написан так, чтобы функция была максимально изолирована.
Это принцип языков высокого уровня и его так же надо реализовывать в АСМе.
Включите моск и думайте. Подсказывать не буду.

[BOB51]

Прямой доступ к счетчику команд у ПИКовых очень мощная штука.

Только вот работа с PCL требует тщательного анализа и планирования размещения подпрограмм, учитывающего работу связки PCLATH и PCH

[yor]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4595965#p4595965"]Алгоритм должен быть написан так, чтобы функция была максимально изолирована.[/uquote]Можно объяснить принцип изоляции? Изоляции от чего? Что так, что так они в одной и той же памяти.

[КРАМ]

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

[BOB51]

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

Когда и этого становится маловато переходим уже к ЯВУ (в моем случае к Си/С++ под ардуиноIDE легче получилось)

[КРАМ]

[uquote="BOB51",url="/forum/viewtopic.php?p=4596022#p4596022"]Для ассемблера с небольшими проектами не столь существенно заметно.[/uquote]
Именно для ассемблера это более всего заметно. На Си все эти попытки пресечены инструментами и всеобщим презрением к использующим goto.
Именно в ассемблере код становится спагетти-кодом очень быстро. Патамушта новичок ленится включить моск и создать легко администрируемый код, заменяя его на свои мечущиеся "мысли".

[BOB51]

Вот тут и не согласен.
Ассемблер требует таки весьма большого внимания (и подсказок от компилятора/ среды разработки заметно меньше).
Плюс "свобода творчества" для ЯВУ недоступная.

[yor]

[uquote="BOB51",url="/forum/viewtopic.php?p=4596022#p4596022"]ардуиноIDE[/uquote]Если не путаю, мне встречались сведения, что оно и PIC поддерживает, или путаю-таки? Ассемблер PIC?