Лидеры

Если задачи - независимы друг от друга, то критическая секция нужна. Потому как пишущая задача вполне может захотеть обновить данные до того, как предыдущие данные считаны читающей задачей. Так что = критическая секция (для сериализации доступа к данным) + какой-либо механизм нотификации (об обновлении данных) читающей задаче. Второе может быть как простым volatile-флажком, так и каким-то средством из арсенала ОС. А если предыдущие данные ещё не считаны, но пришли новые? Куда их девать? Вот для того и нужны критическая секция + нотификатор. Из контекста вопроса видно, что передаваемые данные - какие-то параметры, которые могут приходить в любое время, асинхронно работе системы. В том числе и прийти несколько раз подряд с коротким интервалом. Неправильный алгоритм. Сперва читающий процесс должен сбросить флажок-нотификатор, и только потом - считывать данные. Так как иначе он может сбросить флаг новых данных, даже не прочитав их. Это не так. Флажков в РТОС бывает много разных. И в любом случае всегда советовать весьма тяжёлый мьютекс - так себе совет. Мьютекс я бы советовал в самом последнем случае. PS: Если не нравится критическая секция или мьютекс (который весьма сложен внутри, намного сложнее критической секции, а потому требует много ресурсов от ОС; и применять его лишний раз в простых случаях - неоптимально), то есть множество других вариантов межзадачной синхронизации. Вместо критической секции (которая может запрещать все прерывания), можно останавливать шедулер ОС на время чтения/записи разделяемых данных (что является аналогом критической секции, но без помех работе прерываний). Кроме того - есть механизмы межзадачной синхронизации вне-РТОС функционала. Спин-блокировка например. Если у ТС процессор = Cortex-M, то для атомизации доступа к разделяемым данным можно использовать механизм эксклюзивного доступа. В случае, если объём передаваемых параметров небольшой (~десятки байт), то эксклюзивный доступ намного легче (по занимаемым ресурсам) чем мьютекс. И при этом совершенно не мешает работе прерываний. При выборе конкретного способа синхронизации в каждом конкретном случае, следует идти от простого к сложному: Сперва примерить самый простой способ. Если не подходит - переходим к более сложному, примеряем его. И так далее... Только так можно создавать оптимальные программы.

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

Да ладно. Какой-нибудь PIC16C505 отнюдь не был конкурентным провалом.

Так это по сути реализация стандартного ШИМ-контроллера импульсного блока питания на дискретных элементах.) Я что-то подобное мутил ещё в СССР, будучи студентом, на кондовых советских ОУ и транзисторах серии КТ840))) Эх, ностальгия...)))

ну хотя бы один пример сложного embedded изменения приведите. можно даже не в каких то условных деталях, а сколько времени уходит на переделку железа в результате "маленького нового желания" заказчика? как взять готовое ТЗ и с помощью скрама быстренько выкатить MVP, а потом десятком спринтов выкатить нужный (но неполный) функционал заказчику, меняя по ходу разработки цвет светодиода с цианового на сине-зеленый понятно. речь именно про дизайн железа, когда в ходе внесения изменения железа уже чуть ли не проще начать с нового составления ТЗ. я картинку для такого случая даже нашёл 🙂 как быстро сделать такую материнку (в левом нижнем углу) https://www.scruminc.com/scrum-in-hardware-guide/

Думаю, это синфазная антенная решётка из 16 полуволновых диполей над рефлектором (вторые половинки диполей с тыльной ст. платы) со схемой суммирования сигналов и согласующими трансформаторами. Поскольку один диполь над рефлектором имеет усиление около 3 дБ, то без учёта потерь такая антенна не может иметь усиление более 15 дБ.