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

[veso74]

(yor, а уже не перешли на C для PIC? На C легко реализуются все простые, средние и почти все сложные проекты. Сегодня есть идея для реализации на МК, через минуты, часы, дни, иногда недели ... и проект реализуется. Легко и приятно писать код на C для MK PIC).

[BOB51]

ЧМЗ это актуально для каких то операций с содержимым порта. Если те операции делаются с содержимым буферного регистра и затем результат возвращается в порт то уже для порта простой ввод/вывод будет. Т. Е. Читаем в буфер, модифицируем буфер и выводим в порт результат.

[yor]

[uquote="veso74",url="/forum/viewtopic.php?p=4590618#p4590618"](yor, а уже не перешли на C для PIC? На C легко реализуются все простые, средние и почти все сложные проекты. Сегодня есть идея для реализации на МК, через минуты, часы, дни, иногда недели ... и проект реализуется. Легко и приятно писать код на C для MK PIC).[/uquote]Не люблю высокие языки, если не касаться других плюсов и минусов, которые всем известны. Пока обхожусь.

ЧМЗ это актуально для каких то операций с содержимым порта. Если те операции делаются с содержимым буферного регистра и затем результат возвращается в порт то уже для порта простой ввод/вывод будет. Т. Е. Читаем в буфер, модифицируем буфер и выводим в порт результат.

То есть:

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

bsf PORTA,b
-------
clrf PORTA
-------
IORWF PORTA,F

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

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

movwf PORTA

уже не ЧМЗ?

[КРАМ]

[uquote="yor",url="/forum/viewtopic.php?p=4590641#p4590641"]clrf PORTA[/uquote]
Нет, это эквивалентно записи нуля в порт. То есть не является RMW.
К RMW с рисками разрушения данных относятся битовые операции с портом (bcf/bsf), а так же любая арифметика (addwf, subwf, andwf, iorwf, xorwf, etc...) с содержимым порта, если результат сохраняется в порт.
Например:
iorwf PORTA, F

[Steppe]

[uquote="yor",url="/forum/viewtopic.php?p=4590641#p4590641"]Не люблю высокие языки[/uquote]
Любовь тут не при чем, просто не тянешь.

[BOB51]

Эта ветка форума про ассемблер.
Потребуется Си или чего ещё - есть соответствующие разделы.

[yor]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4590658#p4590658"]К RMW с рисками разрушения данных относятся битовые операции с портом (bcf/bsf), а так же любая арифметика (addwf, subwf, andwf, iorwf, xorwf, etc...) с содержимым порта, если результат сохраняется в порт.[/uquote]А не надо ли это утверждение дополнить, что ещё если среди выводов порта, к которым применяются эти операции, имеются настроенные как входы?

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

IC1<--->equ<--->5<--->; бобина 1Ц RB5
IC2<--->equ<--->6<--->; бобина 2Ц RB6
TAH<--->equ<--->0<----->; тахометр RB0
;; остальные ноги PORTB как входы для  безопасности, но не используются
ICon:<->btfsc<->Dflag,D1
<------>goto<-->IC1on
<------>bsf<--->PORTB,IC2 ; вкл бобины 2Ц для накопления
<------>bsf<--->PORTB,TAH ; импульс тахометр
<------>goto<-->setICflag
IC1on:<>bsf<--->PORTB,IC1 ; вкл бобины 1Ц для накопления
setICflag: bsf<>ICflag,IConbit
<------> return

ICoff:<>clrf PORTB ; выкл бобины, искра
<------>bcf<--->ICflag,IConbit
<------>return

В этом случае не грозит проблема ЧМЗ? Вывел единицы в порт, потом скопом сбросил. То есть по одному, конечно, но сразу на все выводы, которые не требуют, потому что ноль нолём не перепишешь.

[КРАМ]

[uquote="yor",url="/forum/viewtopic.php?p=4592058#p4592058"]А не надо ли это утверждение дополнить, что ещё если среди выводов порта, к которым применяются эти операции, имеются настроенные как входы?[/uquote]
Это и так очевидно, что риски реализуются только для смешанного типа пинов в этом порту.
Кроме того, риски реализуются только в тех МК, где нет отдельной защелки для входа. Патамушта практически все более-менее новые 8-битные МК Микрочипа имеют такую защелку и работа с LATx (вместо PORTx) исключает проблему. Через LATx данные выводят в порт, а через PORTx их читают из порта.

[yor]

А как насчёт паразитных дёрганий ножками? Пусть даже очень коротких. Когда на выходах единица, или ноль, при выводе на соседние ножки не бывает ситуаций, чтобы ножка, которая ни при чём, дрогнула?

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

bsf PORTB,IC2 ; вкл бобины 2Ц для накопления
bsf PORTB,TAH ; импульс тахометр

[КРАМ]

Я же написал выше, что bcf/bsf тоже относятся к RMW и соответственно создают риски для МК с отсутствием защелок на входах портов.

[BOB51]

Предыдущие данные присутствуют в защелках (а с их выходов и на самих выводах). Поэтому смена единицы на единицу (или нуля на нуль) при байтовом выводе никаких бросков на выводах не произведёт.
Другое дело если к выводу присоединена мощная нагрузка, искажающая текущий логический уровень.
К примеру у нас 01000001 на выводах (и в защелке)
НО... К линии порта d6 прицеплен мощный потребитель, исказивший уровень сигнала до уровня, воспринимаемого как верхний предел "логического нуля"...
Тем самым даже при байтовом чтении порта в буферный регистр я получу вместо 01000001 только 00000001 !!!
Если у меня нет ранее сохраненного верного значения при любой последующей модификации буфера я получу ошибку в шестом бите и отправлю её же в защёлку.
Чтобы такой вариант не прошёл и нужно иметь буфер с текущим значением порта и дополнительные константы масок плюс буфер оперативного ввода текущего значения порта (коим чаще всего является аккумулятор).
Но лучше таки подобрать компоновку выводов порта без "перемешивания" функционала ввода с выводом в пределах одного порта.
Это не касается корректно активированных "альтернативных функций" выводов - но там порой нужно детально почитать даташит для верных настроек и учёта всех версий Еррат для кристалла.
Или подобрать более подходящий для задачи МК по компоновке раскладки выводов и аппаратной начинки. Возможно и внешней рассыпались разумно добавить.
МК не догма, чтоб всё в одну "букашку" впихивать.

[Steppe]

[uquote="BOB51",url="/forum/viewtopic.php?p=4592156#p4592156"]Другое дело если к выводу присоединена мощная нагрузка, искажающая текущий логический уровень.[/uquote]
Можно подробнее о МОЩНЫХ нагрузках и их ИСКАЖАЮЩИХ действиях, что влияют на логический уровень.
ВОт никогда не встречался с такими явлениями, все делалось исключительно по datasheet на каждый контроллер.
Применял 12, 16,18 и 33 PIC(dsPIC) и с такими явлениями никогда не встречался.

[yor]

А, я понял! Что вы тут пытаетесь втереть, а до меня никак не доходило. Искажение - это всего-навсего просадка вывода. И она актуальна в течение нескольких ближайших тактов, или больше, в зависимости от. Но мощная нагрузка обычно включается надолго, ей быстро не флип-флопают)) Ну или вблизи границы ощущения 0/1, так это уже перегруз, проблема не совсем (или не только) программная. Это не касаясь переориентации ввод/вывод на лету.

[BOB51]

Многое зависит от грамотной схемотехники внешних цепей МК.
Раньше при МК со слабыми нагрузочными характеристиками выводов это было весьма актуально (особо в "классике" MCS51 и старых "среднемладших" ПИКовых).
С увеличением нагрузочной способности выводов и модернизацией выходных каскадов, появлением раздельных регистров управления, вывода и ввода на портах проблема заметно уменьшилась.
Но правила корректного подключения таки остаются - одно из них:
активный уровень управляющий внешней нагрузкой ставим нулём;
Распределяем шину возврата для управляющих каскадов и входных сигнальных линий между GND и + питания МК для уменьшения пульсаций тока на этих выводах в результате активации ключей.
Применяем варианты ключей с высокоомным входом (эмиттерные повторители) и гальванразвязки на оптронах или импульсных трансформаторах.
Не забываем, что те выводы МК (GND и +питания) имеют ограничения по суммарному току (смотреть даташиты) и частенько являются источниками помех, проникающих по ним (из-за некорректной схемотехники) из каналов внешних ключей с ШИМ управлением.
Иногда смотрим "эффект затягивания" при начальной активации МК и внешней обвязки по reset (крайне редкое явление, но может очень дорого обойтись)...
Вобшемссс... Классика разработки внешней схемотехники 30-40 летней давности не отменялась.

[Steppe]

[uquote="BOB51",url="/forum/viewtopic.php?p=4592180#p4592180"]Многое ....[/uquote]
Я задал довольно конкретный вопрос. Вы мне написали целую обобщающую главу.
Про подключение импульсных трансформаторов к ногам МК [uquote="BOB51",url="/forum/viewtopic.php?p=4592180#p4592180"]Применяем варианты ключей с высокоомным входом (эмиттерные повторители) и гальванразвязки на оптронах или импульсных трансформаторах..[/uquote]
даже комментировать не буду.
Как впрочем и все остальное.
Применял как-то dsPIC33FJхххх (80-pin TQFP) c питанием 3,3 В. Навешивал на него много чего. Еле ног хватило. Получился такой контроллер технологического оборудования со многими функциями и т.д. Выбор пал на эту серию из-за встроенного интерфейса с квадратурным энкодером.

[BOB51]

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

[Steppe]

[uquote="Martian",url="/forum/viewtopic.php?p=4592206#p4592206"]И я согласен со Steppe, искажать логические уровни мощными нагрузками... ну это возможно только лишь в нарушение спецификаций,[/uquote]
Мы же не китайцы, которые вешают на ноги МК напрямую аноды/катоды семисегментных индикаторов, да еще и опрос клавиатурных кнопок одновременно туда же.

[BOB51]

Это уже не вопросы ассемблера и системы команд.

Абсолютным решением вопроса является применение дополнительных буферных регистров в ОЗУ - одного под исходные данные для вывода в порт другого для хранения текущих данных, считанных из линий порта. Медленно, но полностью контролируемо.
"Стандартная средне младшая" это совсем не 18я или более "старшие".
А уж если и это не помогает - тогда лезем в дебри документации и схемотехники.

[BOB51]

Документация на сегодня это несколько буков страниц за 500 да на иностранном (включая иероглифы).
Вычитывать её в обязательном порядке разве что профессионалам под силу.
Чаще читаем общую часть в обязательном порядке и уже глубоко "по прециденту" встречи с неясной ситуацией.
Иначе "мозги выкипят" (Да и при нынешней частоте смены поколений и семейств МК ресурса мозгов на ВСЁ не хватит).

[Steppe]

[uquote="BOB51",url="/forum/viewtopic.php?p=4592230#p4592230"]Документация на сегодня это несколько буков страниц за 500 да на иностранном (включая иероглифы).
Вычитывать её в обязательном порядке разве что профессионалам под силу.
Чаще читаем общую часть в обязательном порядке и уже глубоко "по прециденту" встречи с неясной ситуацией.
Иначе "мозги выкипят" (Да и при нынешней частоте смены поколений и семейств МК ресурса мозгов на ВСЁ не хватит).
[/uquote]
Позвольте мне не согласиться с таким утверждением.
МК меняются не так часто, как вам кажется. У семейств существует преемственность. Если понадобиться разобраться с определенным интерфейсом, к примеру CAN, DMA или другими, то читай соответствующие главы. Вычитывать нужно в обязательном порядке. И что такое "общая часть" в datasheet? Первые несколько страниц документа?
Не разбираясь с работой "модулей", интерфейсов, что находятся на борту любого МК, ничего путного никогда не создать.