Что у стм не знаю, извиняюсь, но не пользовался никогда. Проверка (если Вы про ? или if) не обязательна, я уже приводил пример:


Если же Вы про чтение порта, то я уже писал, что это плюс для аппаратного тоггла.


Пример несколько футуристический и вызывает много вопросов "зачем?", самый главный - зачем писать данные из двух потоков в один порт без синхронизации (порт в данном случае не GPIO порт, а Ваш "виртуальный" а-ля DDR канал)? Мне кажется такое построение это некоторая ошибка в построении всей архитектуры системы или "синтетический пример".

Если запись любого числа битов в порт через BSRR атомарна, а она именно такова, то в принципе не нужно задумываться с каким портом в данный момент работаешь.

Не, я не про то, подредактировал свой вопрос и уточнил про какой "порт" я говорил:

а это разве не проверка?
1)читаем GPIOx->IDR (только правильнее будет ODR)
2)инвертируем ~GPIOx->IDR
3)& 0x81
4)| 0x00810000
5)записываем BSRR
хотя согласен, для более одного пина, ваш вариант лучше, чем явные ? и if


с аппаратным тогл, как в XMC4700/4800
1)GPIOx->BSRR = 0x0081'0081;//одна операция!!!

Запись атомарна, но в условии задачи указано "сигнал квитирования надо инвертировать". А значит на STM одной операцией записи не обойтись.

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

Понятно, что пример синтетический. В реальной практике у меня такой задачи не было.
Но вот например у Вас есть внешняя память (SDRAM) скажем на нормальной шине. Вы же пишете в неё из разных задач/ISR не задумываясь об атомарности - это всё сделано на аппаратном уровне. Полезность такой записи из разных задач очевидна?
А теперь представьте, что в МК нет внешней шины, или что эта шина не поддерживает устройство в которое надо писать. А это устройство имеет интерфейс, подобный DDR.
И пакетные записи не нужны - каждая запись имеет значение (собственно этой записью передаётся некая команда в устройство).
Все возможные схемы представить сложно, но имхо это - вполне жизненный вариант.

У меня когда-то давно была практическая задача подобная этой, но там правда не надо было обращаться к шине из разных задач, но нужно было как можно быстрее передавать по такой шине. И при этом - на данном порту были ещё другие пины, которые трогать было нельзя.
И в таком случае с регистром BSRR STM32 можно конечно реализовать такую передачу, но реализация получается более громоздкой чем на Infineon или LPC.


Зачем добавлять??? На Infineon я прекрасно и устанавливаю и сбрасываю и инвертирую пины одной операцией записи.
BSRR = 1 << pin; //установка
BSRR = 1 << pin + 16; //сброс
BSRR = 0x10001 << pin; //инверсия

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

Почему? Не понимаю.

Да, если пакет помещается в одну операцию, то возможно, хотя и несколько "притянуто". В этом варианте аппаратный тоггл рулит.

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

Тут было много примеров, где использовалась перманентная установка битов сброса и запись данных в биты установки. В таком варианте фактически получаем регистр 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? Откуда ты знаешь какое число запишешь? Может оно из массива читается или генерится весьма сложным образом.

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

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

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

Не понял Вашу мысль....
В чём проблема-то? Что именно нельзя сделать? Если не нужно знать предыдущее состояние какого-то пина на порту, но состояние всех остальных можно установить в нужное одной операцией записи. Каким бы сложным ни был генератор.
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+, чтобы тот занимался подобным ногодрыгом.

Т.е. - взять LPC43xx? Это да...
И решение той задачи мы потом переделали взяв более жирный многоядерный проц. Ибо на LPC1758 хоть и успевало, но работало на пределе и больше почти ничего проц не успевал делать.
Но на тот момент задача стояла так: железо было уже сделано без меня (на LPC1758 + ПЛИС + CY7C68013A), был инвестор с кешем, и надо было ему показать рабочее железо, пускай выполняющее только часть функций. Так что - или сделать на том что есть, или потерять проект вообще. А через годик мы поменяли элементную базу на другой проц и всё

Да, похоже ты прав, при таком подходе можно сделать и инверсию... но это не бесплатно. Для начала нужно код доработать:

Смотрим что нагенерит компилятор. Один вызов:

Два вызова подряд:

Я же предлагал такой код:

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

Два вызова подряд:


Update: Претензия снимается, специально объявил записываемую переменную как volatile, чтобы компилятор ее не рассматривал как константу, то в твоем коде она читается 2 раза и ественно компилятор это продублировал Разница есть, но она всего 4 байта

Типа того, но по отдельности порой выходит даже дешевле, да и выбор ничем не ограничем.

Но LPC4300 уже устарел, уже есть более злобные: http://www.microchip.com/wwwproducts/en/ATSAM4C16

Инверсию за одну операцию на STM ни при каком подходе сделать нельзя.
Мой код не инвертирует, а устанавливает значение всех пинов за одну операцию записи для любого числа. Инверсии там нет.

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

Одно ПО разрабатывать/сопровождать/обновлять проще и дешевле. В этом плане многоядерный проц лучше нескольких одноядерных.
Я, когда писал прошивку для LPC1758 + параллельно для CY7C68013A, это почувствовал на себе. И документации читать больше и в отладке сложнее. А уж когда оказалось, что прошивку и того и другого надо ещё у заказчика обновить....

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

По сравнению с этим - не устарел.
LPC4370 (который у меня был) - 3 ядра на 204МГц: M4F + M0*2.
Здесь же только 2 ядра, пускай и M4 (но одно ядро - просто M4 без F как я понял), но на 120МГц.
Это ещё посмотреть кто быстрее будет
Да и ОЗУ в LPC4370 побольше почти в 2 раза - 282кБ. Правда флеши нет

Итого: 120*2=240МГц против 204*3=612МГц
А уж про АЦП LPC-ки я вообще молчу

PS: Да, кстати - для второго ядра ещё и частота не указана. Может она в 2 раза ниже?

Гы, я не знал про такие
Похоже, семейство это развивают во всю ))