Это зависит от того как вы в дальнейшем используете результат (в частности нужен ли он в этом потоке, или можно сделать асинхронный callback), и используется ли еще где то работа с этой самой i2c шиной (или с теми ресурсами, которые нужны для такой работы). И если да, то можно ли собрать всю эту работу в одно место?

A если надо таймаут не на захват одного ресурса, а на несколько? Не спорю, на потоках тоже можно реализовать, на на SST это проще.
Та же задача с атомным реактором - считываем группу датчиков, если не успели за 5 сек - срабатывает высокоприоритетное событие, которое задвинет стержни и потушит реакцию. С очередями аналогично - вдруг где-то что-то в очередь не влезло - срабатывает событие, которое гарантировано(при любых раскладах) задвинет стержни. Для таких ответственных задач нужна статическая память(то есть гарантия ее наличия еще на этапе компиляции) - никаких стеков и куч и event-ы - никаких сложных планировщиков. И проверенные временем высокоурвневые обьекты - без ручной работы с памятью, иначе будет высокая вероятность схватить segfault - от человеческого фактора никто не застрахован.


Ну да, в SST аналогично - если будет флуд высокоприоритетных событий - низкоприоритетные никогда не запустятся. Если такое поведение не подходит - тогда нужна ОС со сложным планировщиком. Обычно в таких ОС о приоритетах никто уже не задумывается - приоритеты динамически расставляет сама ОС


Да, нужно иметь опыт в even-driven. Много памяти - это очень удобно для SST - можно смело использовать динамическую память (кучи или пулы блоков фиксированных длин), там, где это уместно - тогда начинаешь чувствовать себя, как в Javascript-е


А зачем ждать готовности интерфейса? Добавили запрос в очередь. Как только дойдет до него дело(а раз дошло, значит шина уже свободная) - он выполнится и по завершению выдаст соответствующий event. В любом контроллере есть для этого соответствующие прерывания.
Та даже если и нет, а работаем с шиной вручную дрыганием ног - все точно так же - достали из очереди запрос, выполнили, выкинули соответствующий event. Почему просто не выполнить это без всяких очередей - потому что с SST можно выполнять работу с дрыганием ног в своем приоритете, чтобы и другим не мешать, и чтобы глюков(задержек клока итп) на шине не было, из за того, что кто-то прервал нашу работу.
Такие задачи работы с аппаратурой на SST и очереди ложатся, как влитые.

Нужен в этом потоке. Вызов к i2c может произойти из 2-3 потоков, с разной частотой или нерегулярно. В одно место собрать можно, если захотеть. Но вопрос именно в том как делать подобные блокирующие вызовы а не избавится от них. Например, при чтении/записи файлов не те же проблемы возникнут?



Вопрос был не про SST, на нем задача решится, не сомневаюсь. Проблема только в том, что в C это будет callback hell, а на более другие языки пока нет желания переходить.

А каким образом вы делаете выход из PendSV обработчика на Cortex-M* когда надо после него вызвать обработку события? Где-то упоминали, я не понял.

Если грамотно разложить на функции, то hell-a не будет. Наоборот в C есть вложенные функции, а в C++ их нет Правда есть лямбды, недавно появились относительно.
Сахарку можно добавить в С с помощью макросов, если нужно.
А можно(я так иногда делаю) прогонять исходник через скрипт на Python-е(или что больше по душе) - расширять сишный синтаксис своими фантазиями Иногда мучаюсь с шаблонами, макросами неделю, потом плюю на все стандарты, беру питон и решаю задачу за 10 минут.
Но согласен, без мощного языка работать с event-ами напряжно и лень пробирает


На ассемблере, довольно хитрым, хотя может и не совсем

Смысл в чем - при входе в PendSV создаем кадр стека, кидаем туда адрес функции-планировщика и адрес возврата из этой функции(туда попадем, когда планировщик отработает).
По адресу возврата лежит единственная инструкция - SVC, которая кинет нас в другой обработчик, там нам нужно убрать после себя - удалить наш кадр стека, и таким образом при выходе из этого обработчика мы попадем туда, откуда ранее попали в pendSV.
Этот механизм нужен только для асинхронного прерывания задачи, то есть при добавлении задачи в очередь из прерываний.
Чтобы вызвать планировщик из прерывания(а это делается автоматически после добавления задачи в очередь) достаточно установить PendSV, и по завершению обработки всех прерываний мы попадем в наш хитрый pendsv. Сам pendsv тоже может быть прерван в любой момент - это абсолютно безопасно.
Синхронное прерывание задачи - это просто вызов функции

На кортексе я добавил рантайм-сахара, чтобы не задумываться откуда вызывается планировщик - из прерывания или Thread-mode, тк для меня, что прерывание, что любой другой код - это одно и то же - прерывание точно такая же задача, как и все остальные, имеет свой приоритет, только этот приоритет всегда выше приоритетов обычных задач(не-прерываний).



Без очередей сериализация доступа к аппаратуре может превратиться в мрак. Допустим есть шина I2C.
Ок, для сериализации нам нужен мютекс, назовем его i2c_mutex.
На этой шине висит 5 устройств. Для сериализации доступа к ним нам опять нужно 5 мютексов device_mutex_X.
Дальше одно из устройств - память, часть из которой просто буфер, а другая часть хранит настройки(тн. Settings), для сериализации нам опять нужно 2 мютекса flash_buffer_mutex и settings_mutex.

Получается, чтобы прочитать какой-нибудь setting нам нужно:
1. схватить settings_mutex
2. схватить device_mutex_memory
3. схватить i2c_mutex
4. что-то сделать
5. отпустить i2c_mutex
6. отпустить device_mutex_memory
7. если нужно - перейти к п2.
8. отпустить settings_mutex
Мало того, работа с i2c будет скорее всего выполняться(хотя бы частично) из прерываний, а для этого нам понадобится еще и семафор.

Это еще довольно простой случай. До dead-locka тут еще далеко(хотя не факт), но вот resource starvation при таком обилии локов будет однозначно, если шина нагружена. Ну и оверхед на мютексы, в реализации самих мютексов по любому будут очереди(гы и блокировки.
А если вдруг захочется прочитать setting при работе с устройством X на i2c шине, что будет? Правильно, можно схватить deadlock(раз в неделю/месяц/год).
Можно, конечно, всю работу устройств на i2c покрыть одним жирным мютексом(а не это кучей мютексов), но это во первых ослабляет инкапсуляцию, а во вторых - это тормоза, шина будет простаивать во время обработки данных с флешки.

На очередях этих проблем нет, все будет вертеться в порядке приоритета и очереди, задачи будут нормально выполняться, если для них хватит пропускной способности шины.
Но нужно грамотно расставить приоритеты(и чем их меньше, тем лучше). Если не получается - значит либо что-то не так, либо действительно нужна ОС с динамической планировкой приоритетов задач.

К стати такая динамическая ОС тоже может быть чисто асинхронной (event-driven), но это будет уже не SST, a SCT - Super Complex Tasker
Но не на столько complex, как обычная ОС. Если потоки будут без блокировок(но с тайм-квантами и динамическими приоритетами), то такой планировщик проще, тк поток никогда не блокируется, он может быть только вытеснен другим потоком, так, как это происходит в SST.

ps. Изначально на Javascript асинхронный стиль был вынужденной мерой. WEB-приложения становились все сложнее и сложнее. Потом народ просек, что этот стиль довольно крут и придумал NodeJS, чтобы писать в том же стиле и серверы(да и просто прикладной софт), которые раньше делались на блокирующем PHP

brag прав - тут напрашивается сериализация (например с помощью очереди). Если работу с самой I2C шиной можно собрать в одну процедуру (или набор процедур), то сериализацию можно встроить в них. Таким образом на уровне интерфейса ее видно не будет. Еще можно саму работу с I2C разбить на автомат и поместить в прерывания. Вариант в 2мя мьютексами рожалуй самый простой, но его надо очень внимательно изучить на предмет гонок, и в особенности в части синхронизации проверок состояния I2C аппаратуры и ожидания на мьютексах - можно словить deadlock.
Возникнут. Вариантов решений много - начиная от запрета одновременных обращений из разных потоков к файлам, и заканчивая асинхронным вводом/выводом и сериализацией на уровне ОС

Кстати, для обращения к I2C тоже есть одно простое решение - все обращение должно происходить из одного потока (или из прерываний). Остальные должны отправлять в этот поток запросы, можно поштучно (такая вырожденная очередь получается)


В С их нет. Они есть в gcc, но это его собственное расширение (для С)

Да, действительно, с C их нет. как-то довелось их применять и компилятор схавал, поэтому и подумал, что они есть в C.
Тогда энкапсулировать можно на уровне файлов. i2c движок не сложный, использовать указатели на функции и typedef, на C норм код получиться.

Почитал programming manual, стало ясно, но сложно, хочется проще.



Сама работа с i2c уже на автомате в прерывании. Снаружи только запуск передачи и получение результата. Проверки занятости i2c нет, если мьютекс не взят то предполагается, что i2c не занят, ставим указатель на структуру i2c_request и запускаем прерывание, ждем семафор.

Можно спланировать использование i2c так, чтобы запросы группировались и шли регулярно с некоторой частотой. К некоторым устройствам на каждый такт, к другим лишь иногда. Но это усложнит код использующий i2c и возможно повысит его связность с кодом i2c, в зависимости от деталей. Будут запросы на чтение, а потом рассылка результатов. Обработать все результаты в одной задаче нельзя, разная частота, разные приоритеты.

С мютексом можно работать, но если начнутся вложенные мютексы - пора переходить на очереди...
К стати как с семафором из прерывания работа выполняется? Через очередь или через блокировку всех прерываний?


Проще не будет, кортекс не поддерживает рекурсивные прерывания, поддерживает только вложенные. А для SST нужна рекурсия: задача->планировщик->задача->планировщик->задача итд.

Во FreeRTOS есть xSemaphoreGiveFromISR, она внутри реализована через очередь (базовый примитив, через него все остальные) с одним элементом нулевого размера, а работа с очередью скорее всего содержит в себе запрет прерываний до некоторого приоритета.

На кортексе можно обойтись без запрета прерываний, у меня именно так планировщик был сделан в моей блокирующей ОС(которой я сейчас не пользуюсь, тк перешел на неблокирующий SST).

Вот процедура добавления syscall-a из прерывания в очередь. Стиль еще старый сишный

Этот код проверен анализатором и много раз прокручен разными мозгами, можно с у веренностью сказать, что гонок в нем нет, но при соблюдении условий:
1. PendSV не должен прерывать другие прерывания, которые пишут в очередь.
2. Планировщик и вся остальная работа ОС(мютексы итд) тоже должна выполняться только из PendSV(или из такого же уровня приоритета), то есть быть не конкурентной

Для SST такая очередь не годится, там чтение и запись - конкурентные. Там нужна гораздо более сложная, шаблонная, lock-free очередь, ну или на локах, но локи должны покрывать только работу с метаданными(2 указателя), иначе будут тормоза - задержка обработки особо критических прерываний. Такая очередь на локах тоже довольно не тривиальна и требует тщательной отладки. Но делается это один раз.


С event-driven мы уже научились работать , теперь нужно двигаться дальше, тк асинхронщина - это путь к функциональному стилю. Чисто ФП-язык(Haskell, Erlang,...) на мк уровня LPC175x/STM32F10x использовать для практических RT-задач вряд ли получится, МК слишком слабые для этого, поэтому придется пользоваться тем, что есть. Это на данный момент C++14 и Rust.
Введение в ФП-асинхронщину тут https://www.fpcomplete.com/blog/2012/06/asy...tinuation-monad
Но для начала на Haskell пописать все таки придется, без этого никак. Вот по этому туториалу учился(и учусь) я http://learnyouahaskell.com/introduction#about-this-tutorial
А тут, интересные, на мой взгляд, практические рекомендации, как применять ФП на C++(14):
http://cpptruths.blogspot.com/2014/03/fun-...yle-part-1.html
http://cpptruths.blogspot.com/2014/05/fun-...yle-part-2.html
http://cpptruths.blogspot.com/2014/08/fun-...yle-part-3.html

В процессе написания очередного проекта столкнулся с частыми пропусками ошибок добавления в очередь (человеческий фактор однако).

Вместо:

Ну и последующей обработки этих ошибок.

Поэтому изменил паттерн исполняемого обьекта, добавляемого в очередь.

Движок очереди автоматически вызовет callback(Error::QueueFull) если нет места в очереди.

Сам класс Error:


От Error можно наследоваться, хоть и кривовато, но что поделаешь, C++ однако еще тот


Ну и добавляется сообщение в очередь таким способом:


Ошибку подлавливаем уже в обработчиках

Если ошибку не обработать - компилятор об этом напомнит, это очень сильно помогает. Мало того, поскольку в SST нет блокировок - раскрутка стека происходит автоматически и бесплатно, в отличии от синхронных исключений C++. А обработка ошибок практически такая же, как catch в C++ - подлавливаем группу ошибок в одном месте (в данном примере это функция handle_error

Да, не совсем удобно из за неприспособленности C++ к асинхронщине.
Можно сделать по-удобнее, двумя вариантами:
1. либо написать препроцессор(например на питоне) - все зашибись, но это нестандарт.
2. либо выучить haskell (научиться на нем программировать), написать на нем обертку, потом перевести на шаблоны C++ (на шаблонах можно программировать только в чисто функциональном стиле, а чтобы это уметь - надо иметь опыт в haskell, там все куда проще и круче). - но синтаксис может получиться не совсем короткий, зато решение стандартное.

Пока мне хватает ручного handle_error. Если будут проблемы - скорее всего буду делать по второму варианту.

А автор тем временем вытяснющую блокирующую в комлект включил.

Дайте, пожалуйста, ссылочку, чтобы по всей теме не искать.

https://www.state-machine.com

Благодарю.