Допустим нужно записать данные только в младшие 4 бита порта, пусть это будет 3. Тогда пишем в BSRR такое число, которое бы, во-первых, сбросило эти 4 бита(0xF << 16), во вторых выставило только нужные(3), итого получает 0x000F0003. Для двух пинов единица там и там, значит будет инверсия...

Сообщение отредактировал Reflector - Apr 21 2017, 10:19

Тут было много примеров, где использовалась перманентная установка битов сброса и запись данных в биты установки. В таком варианте фактически получаем регистр ODR с маской или атомарный доступ к любой группе битов. Если ввести аппаратный тоггл, то эту полезность потеряем.

Ни кто не предлагает заменить BSRR на инверсию. Предлагают дополнить BSRR ещё и инверсией.

не понятно - что теряем. Задача - перманентно выставлять РА1 и сбрасывать в одной задаче, и переключать РА5 в другой задаче. Если добавить регистр апаратного тогл, какую полезность теряем?

Читаю тему и никак не могу вкурить где может потребоваться именно аппаратный тогл, да и вообще тогл?
Мне тоггл понадобился недавно и лишь раз - моргать лампочкой (blink-режим), т. е. случай, где "до лампочки" предыдущее состояние пина.
А во всех остальных случаях нужна явная установка битов в нужное состояние, например: софтовые интерфесы, софтовый ШИМ, софтовое управление шаговым мотором и т. п.
Просветите, кто сталкивался с нуждой тогла как таковой

Есть и непритянутый пример:
Когда-то реализовывал передачу пакетов данных (1-2 КБ) из LPC17xx по 8-битной шине (GPIO) в CY7C68013A (это чип HS USB с подключением по внешней параллельной шине 8/16 бит с протоколом обмена, который можно запрограммировать самостоятельно написав диаграмму работу внутреннему GPIF).
Главное требование там было - скорость передачи - надо было выплюнуть пакет как можно быстрее. Частота GPIO у LPC ограничена (как и у других МК), у LPC это было что-то около 10МГц. Соответственно - желательно было так построить схему обмена и протокол, чтобы выполнить передачу с минимальным числом записей в GPIO. CY7C68013A работала у меня на частоте то ли 30МГц то ли 48МГц - точно не помню, но помню, что написал диаграмму GPIF так, что она успевала принимать с LPC даже если он будет писать байт за байтом в порт непрерывно (10МГц).
Я поместил сигнал квитирования и 8 линий данных в один порт (на этом порту были также другие сигналы, которые нельзя было трогать при передаче пакета).
Как реализовать такую передачу?
На STM32 её тоже можно реализовать, но на Infineon (и на LPC) код такой передачи получается проще и быстрее.


Неверно. Писать нужно 0xC0003.

Ок, в порту было 0xF, очищаем 2 бита, становится 3, пишем 3, остается 3. А если пишем 2? Откуда ты знаешь какое число запишешь? Может оно из массива читается или генерится весьма сложным образом.

Сообщение отредактировал Reflector - Apr 21 2017, 10:36

программный вывод миандра на порт. в прерывании по таймеру дёргать переключать пин.

Ну в этом случае - да.

А зачем нужен это меандр? Тоже моргать лапочкой?

Не понял Вашу мысль....
В чём проблема-то? Что именно нельзя сделать? Если не нужно знать предыдущее состояние какого-то пина на порту, но состояние всех остальных можно установить в нужное одной операцией записи. Каким бы сложным ни был генератор.
void SetPins(uint value)
{
BSRR = (value & 255) | (~value << 16);
}


Я же привёл пример: передача по параллельной шине с квитированием инверсией пина.

есть вопрос - есть ответ. например передача параметра. параметр меняется от p0 - до p100, частота линейно должна меняться от f1 до f2. только не нужно спрашивать - "А это для чего"? или"А почему аппаратно не заюзать выход таймера?".
Или выдаем байт последовательно, как уарт, только биты кодирутся не 0 и 1, а частотой f0 и f1.

Полагаю, что это было очень давно, а в данный момент с подобной задачей вы бы справились совсем иначе. Или я не прав?



Что-то типа DTMF ?

Если с теми же исходными данные - так же. А какое ещё решение?
Если бы была возможность изменить схемотехнику - сейчас может использовал бы МК с HS USB.
В той задаче скорости FS USB не хватало поэтому и поставили CY7C68013A.

нет

Я как раз про это - примеры, приведенные тут, как минимум устарели.
В настоящее время и такую задачу найти сложно - дергать целиком порты для реализации некого интерфейса.
Порой выгоднее воткнуть в довесок к основному толстому процу какой-нить копеешный М0/M0+, чтобы тот занимался подобным ногодрыгом.