Я видел. Полистал код. На заметку взял. Спасибо!!!


Всё? Расходимся! )))))))))))

На некоторых платформах и char бывает 16-битным


И кроме M7.

Пример - в студию!

Я лично не очень жалую такую форму условия со знаком "?", просто, дело вкуса, не более того.

такая же фигня. вообще не пользовать оператор ? до недавнего времени.... меня, когда "воспитывали", то по рукам били за несколько операторов в одной строке. И отучили. В принцепе согласен.... такие конструкции как
if(isLow()) return;
ухудшают читаемость кода. стал пользовать
if (isLow())
setToHigh();
else
setToLow();

после перешел на ?. нет портянок и нет в одной строке кучи операторов

Семейство TMS320VC55xx в CCS.


Имхо наоборот: Портянки на несколько экранов вместо компактной записи - ухудшают читаемость.

+1

Господа, нужно просто делать внимательно RTFM. BSRR регистр имеет замечательное свойство:

Поэтому задача решается очень просто без проверок:


Это свойство полезно и в других задачах, обсуждаемых на последней паре страниц .


Как по мне, то если переинициализация не производится в процессе работы, то логично собрать все в одном месте. Особенно по части GPIO.

А не усугубят ли битовые сдвиги производительность этой и так тормозной операции?

Именно так, у меня вся инициализация настолько в одном месте, что я одной строкой инициализирую сам усарт вместе с портами, а рядом может быть инициализация USB или пина светодиода. Это возможно, т.к. класс пина владеет всей нужной информацией, а функция инициализации усарта знает в каком режиме эти пины нужно инициализировать. Если я не стану в нее передавать пины, то придется для каждого усарта добавить 2 строки их инициализации и тогда уже я должен думать какие-же для них нужно выбирать режимы. И это у меня 2 строки на усарт, а когда люди начинают 4 регистра gpio инициализировать вручную или когда они делают это через HAL, то получается намного больше.




Правильно, метод write так и делает:

Битовые сдвиги у ARM бесплатные нативные. Ни у кого из МК нет операндом "шифтера".

У Infineon XMC4700/4800 подобный регистр имеет ещё более замечательное свойство: при одновременной записи единички и в установку бита и в сброс бита, соответствующий бит инвертируется. Атомарно.

Это глупое свойство, не дающее никакой пользы.

Если Вы не понимаете назначение чего-то, это не повод называть это глупым.

Не соглашусь. Если над генерить "жестко" комплементарные сигналы - очень даже... Правда запихнуть такое в либу проблематично (к вопросу об издержках подхода)

Не ради спора... а чтоб расширить кругозор... искать ваши объяления/определения... классы/шаблоны..... поясните, если не сложно... или покажите сырцы GpioB<>

пусть b = 0xff;
GpioB<4>::write(b & 0x20); b & 0x20 даёт 0x20. что дальше? write() принимает bool. т.е. при передачи аргумента есть неявное преобразование uint8_t(0x20) в bool (0х01)? да и ещё и передача аргумента... т.е. копя data создается внутри write().

Установить одновременно один вывод в 0, другой в 1? На STM32 - легко. Для этого не нужно инвертировать сигнал, посылая одновременно "установить" и "сбросить".
И, да, я тоже помню про приоритет при задании состояния.


Прекрасно понимаю, что такое свойство мне [ ] не нужно.
STM согласна со мной, а не с вами.
Я и в ПЛИСке так управляю триггерами.

Вы заблуждаетесь, они с вами не согласны. )))
Иногда требуется не просто установить в 1 или в 0, а переключить. Для чего - это отдельная тема. В некоторых процессорах, если не ошибаюсь, есть отдельный регистр для toggle. В стм32 его нет. Плохо. Но st такой функционал добавили в SPL.




похоже вы не понимаете о чем речь идет. при чем тут один вывод и другой одновременно? тут всего один вывод требуется инвертировать.

Комплементарные сигналы - это всегда пара. А вы о чем?
Если мне нужно в одно время установить и сбросить несколько сигналов (в одном порту), я подготовлю нужное слово заранее и пошлю его в BSRR.
Если мне нужно инвертировать сигнал, я установлю или сброшу его в состояние, противоположное предыдущему. Что в библиотеке и сделано.

где тут пара?

jcxz говорит, что в Infineon XMC4700/4800 для инверсии вывода, одного вывода, нужно в BSRR регистр записать одновременно SetBit и ResetBit. При этом, вне зависимости от состояния вывода, он инвертируется. Эта операция атомарная и можно из разных потоков, даже из прерываний безопасно это делать. например для вывода РА0 это выглядит так
GPIOA->BSRR = GPIO_BSRR_BS0 | GPIO_BSRR_BR

2ViKo а про Комплементарные сигналы - тут я соглашусь, можно без тогла 2 вывода одновременно дёрнуть.

Посмотрите сообщение, на которое я отвечал.
Я прекрасно понимаю, о чем говорится. Повторить - такое свойство [ ] не нужно.
Toggle - это Т-триггер. Поднимите руку, кто применял микросхемы таких триггеров.

я понял... просмотрел, уже отписал. тут я согласен
а вот тут не понятно.... вы говорите, что если вам надо переключить бит, вы - установлю или сброшу его в состояние, противоположное предыдущему. Что в библиотеке и сделано. т.е. программно его инвертируете. Но аппаратное атомарное инвертирование - это для вас глупое свойство, не дающее никакой пользы. По мойму сами себе противоречите.
Польза в том, что инвертирование вывода будет за 1 машинный такт, атомарное, вот и всё!

Заранее подготовлю слово для установки и слово для сброса. Когда нужно, пошлю.
За так(т) ничего не делается.

Предпочитаю конкретное поведение, не зависящее от того, в каком состоянии был до того.

Если нужно периодически (и быстро) тоглить комплементарные пины, и для этого надо ОДИН раз установить их состояние, а потом просто, не анализируя текущее состояние, писать в регистр КОНСТАНТУ...



А на транзисторах слабо?

Так оказывается это Вы в согласии с STM убрали из её периферии кучу полезного упростив её до неприличия, как то:
FIFO в различной периферии, dual- и quad-SPI, передачи "свЯзным списком" из DMA и т.п.
Вот оказывается кто виноват!


Человек не понимает понятие "атомарность". Что поделать.
Для одновременной установки и сброса (а это нужно например для формирования парафазных сигналов, но не только - есть другие применения, где очень сложно без такой опции)
если нет возможности инверсии пина, то ViKo придётся:
1. запретить прерывания;
2. считать слово из порта текущих значений пинов;
3. установить в нём бит;
4. сбросить в нём бит;
5. записать слово в порт текущих значений пинов;
6. разрешить прерывания.
Всего-то 6 операций вместо одной.
ViKo, Вы: а) понятия не имеет об атомарности операций и её необходимости? или б) троллите всех тут?

В твоем кода, кстати, то же самое. В MODER и еще двух регистрах режим задается выставлением двух битов, но при использовании bitband они выставляются по отдельности...

Как вариант такого применения (я использовал это на практике):
Реализация передачи для soft-UART через таймер+DMA+GPIO - при наличии возможности инверсии пинов это делается очень легко простой DMA-транзакцией (без использования передачи "свЯзных списков") заранее подготовленного массива по одному адресу, без влияния на соседние пины и всего с одним прерыванием на байт по окончании передачи всего блока.
На МК где нет инверсии пина, это решается более громоздкой передачей "свЯзным списком" в перемежающие адреса регистров установки или сброса.
Либо (если в GPIO МК есть регистр маски пинов) - маскированием (но операция может быть конфликтной с другими подобными).
На STM32 это не решается никак из-за отсутствия инверсии пина и отсутствии передачи "свЯзным списком". Только дёргаться в прерывания на каждый бит, переключая адреса в "double buffer" DMA режиме.

Какой суровый ногодрыг получается...

Как раз для проца - совсем несуровый - его загрузка почти как с аппаратным UART получается - всего одно прерывание в конце блока. А если не жалко памяти, то можно и tx.FIFO эмулировать

PS: Чой-то я ошибся - прогнал напраслину на STM32
Сейчас глянул - у него же установка/сброс через один регистр делаются, значит такой soft-UART можно и на нём сделать. Что-то у меня в мыслях было, что это два разных регистра....

Суровый в смысле отладки и тестирования. Такое, наверно, приходится применять, когда камень заменить нереально, т. к. уже понаделана куча плат. У вас тот случай?

Write всегда инлайнится, никакой копии data там не будет. Вот дизассм:

А это для для варианта с проверкой:

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

ps.
Только я тут опечатался, не GpioB, он работает с маской группы битов, тогда как минимум нужно 4 заменить на 0x10, а PinB...

Да, есть такое. Но это лучше, чем испортить MODER при RMW из нескольких потоков.
Прерывания запрещать в настройке пина я не решился.

А у тебя как это сделано?

Не совсем. Где Вы возьмёте МК с 6 UART-ами например? При этом чтобы не экзотика какая и остальная периферия нормальная была.
Вот и выбрали LPC1778 заранее зная, что надо будет один из UART-ов программно эмулировать.

Я и задачу-то такую не найду, где нужно стока uart ...
если позволяет бюджет изделия, в таком случае я бы поставил плис

Инвертирование за один такт пожалуй единственная реальная польза. Атомарность инвертированию одного пина не особо нужна, или у Вас есть пример, где она реально может понадобиться?


Что-то я не совсем понимаю, а в чем проблема при наличии BSRR регистра проделать то же самое? Подготовили в памяти массив слов и шлем в BSRR, в конце блока прерывание.


У того stmа, что сейчас лежит передо мной 8 UARTов, не уверен получится ли все их задействовать одновременно (в смысле распределения по ногам), но у меня не самый многоногий корпус

Бюджет не позволяет однозначно. Во-первых - стоимость самого устройства, во-вторых - стоимость разработки (нужно ещё ПЛИС программировать); в-третьих - стоимость сопровождения (как быть если обнаружится баг в прошивке ПЛИС? необходимо удалённое обновление её прошивки значит).
Да и зачем??? ПЛИС для доп. UART-а - это из пушки по воробьям.


Да, вот именно у STM32 есть проблема с одновременным задействованием всех этих UART. Даже если по ногам хватит, то не хватит по ресурсам - на все не хватит DMA, а работать без DMA и без FIFO в UART-е с кучей портов одновременно, когда есть и ещё более приоритетные прерывания - будет приводить к сбоям и потерям.

PS: Да, я имел в виду на тот момент не было подходящих МК (эта разработка была лет 7 назад). В более поздней подобной разработке использовали уже Tiva - там тоже есть 8 UART-ов причём полноценных - каждый с FIFO - можно работать с ними и без DMA.


Я уже написал, что тут ошибся, не посмотрел что у STM это один регистр установки/сброса - см. пост выше.


В смысле? Какую атомарность имеете в виду? Атомарность операции внутри процессора или атомарность для внешнего устройства (правильный парафазный сигнал, фронт/спад в один момент)?

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


На кой менять прошивку, где работают только несколько одинаковых uart? Для такой тривиальной задачи имеет смысл сразу ее отладить и оттестировать.
Впрочем, если в плис будет еще что-то, кроме uart, то прошивку можно делать прямо от проца - сменили прошивку проца и он сменил прошивку плис. Но это уже совсем другая история.

Плис бывают разные )))


Как вариант без плис: MAX14830

Ну да... Гладко было на бумаге да забыли про овраги. Как показывает практика, даже в самой отлаженной и тривиальной задаче могут быть баги.
Наступали на эти грабли и очень больно. У Вас видно нет заказчиков с несколькими тысячами Ваших изделий раскиданных на тысячи км по глухой тайге. Да ещё когда устройство работает на объекте в режиме 24/7 и отключить его - огромная проблема. Стоимость ошибки в ПО и обновления ПО с приездом на объект тут получается просто фантастической. Я сам когда-то летал на вертолёте по этим объектам и обновлял прошивки. Рассказать про стоимость часа аренды вертолёта?
С тех пор взяли за правило: если в изделии используются некие компоненты с прошивкой, то должна быть возможность удалённого обновления этой прошивки по протоколу работы устройства без его остановки в обязательном порядке. И это правило нас потом неоднократно выручало.


Стоимость ПЛИС какой бы она ни была, всё равно выше 0. А это изделие предполагалось сделать бюджетным.
И ещё Вы забываете про стоимость изготовления. ПЛИС ещё прошить надо.

Наверно, у вас работает очень дорогой настройшик - 2 минуты работы которого © "стоят тысячу фунтов"

на вскидку один я уже писал в этой теме. на РА0 у вас CS, на РА5 у вас светодиод внешний вачдог. каждый пин дергается в отдельном потоке. Если использовать неатомарный тогл (GPIO_ToggleBits() ) для вачдога из SPL от STM, без критСекций/запрета прерываний/мьютексов на порта РА, то будет косяк.
Да даже без ОС: в главном while вы работаете с РB1, в прерывании PB2 - вот ещё случай.

Стоимость работы настройщика + стоимость ПЛИС (или чего там вместо) + стоимость написания ПО обновления прошивки.
Это на одной тарелке весов. На другой - стоимость написания soft-UART.
Сравните. Разница многократная.

Да - и как с этой ПЛИС взаимодействовать? Поди ещё и внешняя шина нужна? Ног в том проекте тоже не хватало.

Вполне хватит одного SPI, как это сделано в MAX14830

Вы хоть смотрели, как работают биты в регистре BSRR? Вся ваша галиматья не к месту.
Ага, вижу, посмотрели таки! Гуд! Теперь согласны насчет галиматьи?

Атомарность внутри процессора. Для внешнего устройства по идее достаточно (скажем для битов 0 и 7):
GPIOx->BSRR = (~GPIOx->IDR & 0x81) | 0x00810000;
Ну и изначально должно быть правильное состояние битов (например, GPIOx->BSRR = 0x00800001).



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

Всё равно если есть возможность - это лучше чем если её нет. А применение найдётся.


Ну почему-же.
Если нет функции инверсии бита, а нужна именно инверсия, то как быть?
Напишем что-то типа:
if (PinOutputState()) PinReset();
else PinSet();
Если это не сделать атомарным (не завернуть в критическую секцию), а в программе данный пин управляется в разных задачах/ISR, то возможны коллизии.

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

Если у бабки были бы яйца... Только я в своем примере указал GPIO_ToggleBits() от стм, а они пользуют ODR, а не BSRR. а так согласен, запись в BSRR не создаст колизии, и тем не мение, осутствие аппаратного тогла требует лишней проверки выхода.
я не имел в виду одним пином.

Ну вот например:
У Вас параллельная шина от Вашего МК к другому устройству, работает через GPIO, несколько сигналов данных и один - квитирования.
Работает как шина DDR - т.е. обновление данных на шине фиксируется не по фронту или спаду, а по перепаду сигнала квитирования. Так получается можно быстрее данные передавать.
А теперь представим, что для быстрого вывода на эту шину мы и линии данных и сигнал квитирования расположили в одном порту.
Тогда чтобы вывести данные на эту шину достаточно одной операции записи. И никакие дополнительные средства обеспечения атомарности не нужны (типа запретов прерываний).

Я сначала тоже пробовал bitband, но без структуры, как у тебя, потому выигрыш был, но не такой заметный чтобы инлайнить полную инициализацию, а в дебаге размер вырос весьма значительно, плюс потеря поддержки F0. Потому в итоге остановился на отдельно функции инита, а встраивается только ее вызов. Внутри типичный код, который используется практически везде: читаем из MODER и пишем обратно(для F0 по-другому и не получится). Но проблема никуда не делась, хотя промежуточных состояний больше нет, в прерывании или другом потоке может быть изменен сам MODER и тогда будет записано старое, не измененное значение. Если это актуально, то можно написать потокобезопасные версии функций, которые будут запрещать прерывания на время модификаций всех 4-х регистров(и ODR), лично мне они пока не были нужны, т.к. до сих пор обходился прерываниями и регистры задающие режимы gpio в них не менял.