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

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, то все будет прекрасно работать в двух потоках Проблема может быть только если оба потока пытаются управлять одним и тем же пином, но это без какой-либо синхронизации не правильно по своей сути.

Сообщение отредактировал Шаманъ - Apr 21 2017, 08:48