Форум РадиоКот

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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