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

[BOB51]

Но тогда нужно где то хранить маску для данных.

[yor]

Я спросил:
Если разряды портов PORT[A,B] частично настроены как входы, частично как выходы, запись скопом в порт байта, а не побитно только по выходам, ничем не грозит?
Теперь уточню, так как слишком обще:
Во входной разряд порта, мы пишем изнутри противоположное значение в составе этого самого байта. Он как вход не изменит своё состояние? Вроде по схемам из д-шита всё ровно, это игнорируется, но вдруг есть тонкости или особенные порты (MCLR и ещё какие-то имеют отличия). Или железно по всем портам и ситуациям?

ЧМЗ-RMW, это, как я понял, при чтении порта, пока он в проце крутится, а на входах изменение. И причём меняется - то он вход, то он выход. Потому что выводить на вход смысла нет. Так?

[BOB51]

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

[Martian]

LAT и не мучаться сомнениями.

[BOB51]

Это или в улучшенной среднемладшей или у 18й серий LAT имеется.
У стандартных среднемладших его нету.

[yor]

[uquote="BOB51",url="/forum/viewtopic.php?p=4590577#p4590577"]Если изменяем весь байт сразу - проблем нет.
Но в таком случае где-то должна быть маска исходного состояния (или буфер предобработки) в котором те изменения делаются, чтобы не изменять исходное состояние других бит в байте. А уж затем оттуда данные в порт выводить[/uquote]Это и есть проблема ЧМЗ-RMW?

[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 летней давности не отменялась.