Если бы случилась такая фигня, то лично моя библиотека бы ничего не стала делать.
Снабженец был бы просто уволен.
Потому что это не в его компетенции - делать подобные вещи.
Я понимаю, что пример - сильно утрирован. Но - все же отделяйте мух и котлеты. Не нужно на технические вопросы накладывать проблемы организации процесса производства.

Пардон, PORTB.1 а не 0...


Гы... Короче, A.0, A.1, R.1, R.5

Предлагаю посоревноваться с автором листингами записи групп на ХМЕГА. Будем туда писать постоянные, переменные... Например, исходно имеем группу из 4...6 бит. Часть из них на виртуальном порту, часть - нет. Предлагайте варианты как расположить битовые группы и что туда загнать. Если интересно, конечно...

Да, согласен, утрировал немного (самую малость).
Но и товарищ был не прав, выдавая частный случай и свою узкозаточенную реализацию (без исходников, кстати) за истину в последней инстанции.

Исходники для XMEGA обещаны. Если посоревнуемся и они окажутся достойными авторских, конечно... А если они окажутся плохими, то зачем миру мои нелепые исходники?

Есть хорошая статья, Атомарный доступ к структурам по поводу атомарности.


Если добавить предложенный подход к предложенному методу будет вообще ...

Вот ведь, никогда не задумывался над подобной проблемой.
А ведь действительно...
В последнее время всё чаще приходится воевать с "чудесами" в структурах.
Надо будет тщательнее рассмотреть...

Боюсь для tiny/maga AVR этот матод не реализуем - нету в них атомарного xor. Для XMaga он не нужен - есть специальные регистры для атомарного И/ИЛИ. А для MSP430 не знаю, надо разбираться, может и сработает.

Строго говоря, приведённый код не является атомарным. Прерывание так-же может произойти между чтением регистра и его модификацией/записью с помощью xor. Однако побочные эффекты при этом будут другие: если в прерывании изменятся биты, которые должны быть изменены с помощью последнего xor, то их значение будет ошибочно инвертировано.
Лучше это или хуже чем терять значение записанное в прерывании не знаю, ни то не другое не есть хорошо и прерывания всё равно прийдётся запрещать.

Для Хмега тоже есть изюминки. Там SBI за 1 такт выполняется, поэтому, если порт отображен на виртуальный, && количество бит, принадлежащих этому порту порту, 1 или 2, то выгоднее по тактам обращаться побитно через SBI/CBI VPORTn_OUT, а иначе - через OUTSET/OUTCLR физического порта.

Как раз-таки нет.
Насколько я понял, на биты, которые мы отгородили для XOR-енья, оставшиеся никак влиять не будут, при условии, естественно, что они модифицируются аналогичным образом.
Всё потому, что мы накладываем на XOR-ную маску ещё маску пинов, то есть на "чужие" пины она никакого влияния не окажет.
_______
Вот какая полезная тема оказалась, я бы до такого сам бы не дошёл!
Причём совершенно параллельно, на си это написано или на плюсах...

А с проблемой атомарности там на хмеге действительно легче. Кроме одного случая: групповая конфигурация режимов пина. Там тоже надо ставить критическую секцию. Но тут еще проблема - ГДЕ ставить начало критической секции. Если в группе несколько портов с битовым доступом и всего для одной пары бит нужна критическая секция - зачем же запрещать прерывания в самом начале? Это ж на сколько лишних татктов МК "оглохнет"! Надо запрещать прерывания только перед той операцией, где это действительно требуется.


Вот видите, самипоняли важность, а то недоумевали - зачем этот пришлый выскочка поднял такую узкую тему. Атомарность это ого-го. PS.На Телесистемах перестройка - я с вашего разрешения тут пережду. Заодно поколыхаю немножко вашу тихую заводь

mov.w TRISB, W0 //TRISB == 0x0000
xor.w W0, #0x000A, W0 //W == 0x000A
and.w W0, #0x000F, W0 //W == 0x000A

//прерыване
//сохраняем W и т.д.
mov.w TRISB, W0 //TRISB == 0x0000
xor.w W0, #0x0028, W0 //W == 0x0028
and.w W0, #0x003C, W0 //W == 0x003C
xor.w TRISB //TRISB == 0x0028
//восстанавливаем W и т.д.
//конец прерывания
//W == 0x000A, TRISB == 0x0028
xor.w TRISB // TRISB = 0x0022 --> один бит потеряли, должно быть 0x002A

Так, что и тут есть подводные камни. Но только в случае, если модифицируется пересекающееся множество бит.
Если модифицируемые биты различны, то проблем нет.

У вас маски перекрываются, так не договаривались

Если правильно спроектировать код - то не будет такого бреда, как запись в порт в прерывании и в основном потоке.

Согласен, в большинстве случаев этого можно и нужно избегать, но иногда это бывает оправдано.

Это никакой не бред. Gpio - они на то и Gpio, чтобы ими можно было программно махать.
При проектировании аппаратной части устройства те сигналы, которые управляются через gpio могут использоваться много для каких целей, от простейшего управления светодиодами, до каких-то сигналов стробирования периферийных устройств(работающих по прерываниям), генерации последовательностей импульсов, напрмер управления шаговиками (это то что пришло на ум сразу из того, что я реально делал). Часть этих портов могут управляться из фоновой программы, частью - целесообразно управлять из прерываний. Если используется RTOS - то управление может производится в том числе из разных задач. И только не говорите, что это неправильно спроектированный софт и бред. Бред как раз - это обеспечивать управление всеми gpio из одной задачи в случае RTOS, или только из background при ее отсутствии.
При разводке схемы разработчик скорее руководствуются оптимальностью разводки, чем задумываются об атомарности доступа и прочих удобствах для программиста (как то, группировка gpio на соседних линиях портов). Такой подход понятен и вполне оправдан.
Поэтому при управлении gpio портами нужно либо иметь эти эффекты ввиду и организационно обеспечивать атомарное обращение к портам, либо код обращения к портам обертывать в критические секции, либо использовать атомарные команды при изменении битов портов.
Я с АВР давно уже не работаю и не отслеживаю, что там у них и как со свойствами периферии и/или системой команд.
Но, работаю с ARM7 NXP, в коих разработчики позаботились об этой проблеме, разделив регистры по установке и сбросу битов в gpio портах, таким образом обеспечив атомарность этих операций. Однако, если обращение идет к регистрам конфигурирования (направления, подтяжки), эти операции уже не являются атомарными, поскольку используют RMW. Поэтому приходится настройку портов оборачивать в критические секции. Но поскольку порты обычно настраиваются при старте системы и обычно - сразу кучей, то обертывание в критическую секцию этих операций - не такая и большая плата).