Казалось бы такая простая вещь дергать ножкой...

В Примерах к китам, повсеместно для установка пинов вызывается что типа:

Как то раньше не задумывалься, пока глюку не словил, ножка "сама" прыгала в "1",
хорошо это было направления 485 и контроллер просто переставал отвечать оставаясь в передаче, тяжело было не заметить.
Проблема в том что операция не атомарная, и при наличии нескольких потоков, одновременно работающих с портом, в порт может быть выведена ерунда:
если после загрузки значения IOSET в регистр произойдет переключение потоков, в другом потоке будут сброшены битики, потом управление будет возвращено первому потоку, он установить сброшеные биты обратно в "1" (аналогично для IOCLR).

Решается проблема просто использованием

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

вот как выглядет на асме:

Тем не менее, извините, Вам удалось облажаться и эту лажу вынести на всеобщее обозрение.

Нет. Для тех, кто читал документацию, это выглядит так.


Операция атомарная , а IOSET, IOCLR и IOPIN это совсем разные регистры.

Поясните пожалуйста, чем вызвано оскарбление в мой адрес, и как это относится к теме сообщений?

Погорячился изрядно. Извините.

К теме сообщения это относится так - Вы совершенно неправильно работаете с регистами установки и очистки битов, посему Ваше прeдупреждение ложно.

Предупреждение не ложно.
Возможно ложен "наезд" на примеры к КИТам, но не само предупреждение.

Надо бы просто перефразировать:

IOSET/CLR - WriteOnly регистры и читать их бессмыслено.

операции |= и &= и любые другие "чтение-мод-запись" к WriteOnly регистрам неприменимы ни при каких условиях - будь-то один поток или несколько.

Ну чего только в "примерах" не выкладывают лучше просто не смотреть, если не достигли приличного уровня владения вопросом .

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

IOSET можно (и бывает нужно!) читать, только вот почему-то рассчитывать на атомарность нескольких подряд операций c GPIO совершенно наивно.

И правда можно , возвращает значение защелок порта. Не знал, а может знал да забыл. Не суть важно. Как для себя причислил сей регистр к WriteOnly и горя не знаю.

А напрасно. GetSmart показывал интересный пример, когда это может быть чревато неприятностями. Не буду настаивать, что вам надо менять привычки, но взять на заметку, скорее всего, не помешает.

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


Ну почему же сразу неприятностями?
Есть выход без неприятностей - просто использовать переменную, сработает для любой архитектуры.
На некоторых архитектурах в частности на ARM такое решение будет более эффективным, за счет сокращения обращений к APB.

Почему слепая? Простая нормальная инверсия. В отличие от "слепой", а точнее кривой инверсии через IOPIN.
Обращение к порту - 7 тактов максимум. Чтение и запись в дополнительную переменную в раме - 5 тактов, плюс ещё загрузка адресных регистров - тактов 10. Так что не будет эффективнее. По крайней мере в большинстве случаев.

Потому что процессору все равно что выведено в порт, цель проинвертировать.
В задачах с которыми я сталкиваюсь инвертировать (слепо - переворачивать значение порта) не нужно, нужно выводить конкетные значения.


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

Изменение пина (через любой из IOPIN, IOSET, IOCLR) уже загружает адресный регистр, поэтому дополнительное чтение IOSET ничего не требует, в отличие от переменной в раме.