Здравствуйте!
Хотел открыть новую тему по методам работы с RTOS, в которой можно было бы делиться опытом реализации тех или иных функций с привязкой к конкретной оси.

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

Сам я только осваиваю это направление, поэтому и хотел бы начать с конкретной задачи, над которой сейчас работаю.
Исходные данные:
1. ОС – tnkernel
2. Процессор stm32f103z

Задача следующая:
1. процессор выводит информацию на графический дисплей(со встроенным контроллером) 640х480, также читает из памяти аудиоданные, которые потом отсылает на микросхему аудио усилителя по i2s.
2. И память и жки висят на одной параллельной шине, и работа с ними ведется посредством fsmc блока stm32f103z. Т.е. и там и там нужно работать с большими массивами. Как сделать так, чтобы работа с жки не сказывалась на аудио и наоборот.
3. Кроме этого оказалось, что fsmc мешает блоку i2c(не i2s !), через который идут команды на аудио усилитель. Это такая аппаратная проблема stm32 и всплыла она уже после разводки платы. Для нормальной работы i2c требуется отключать тактирование fsmc блока.

Как видно, разделяемый ресурс здесь блок работы с параллельной шиной fsmc.

Интересно мнение как приверженцев tnkernel, так и приверженцев других rtos.

FSMC нельзя назвать разделяемым ресурсом, так как разделение достигается на аппаратном уровне. Вам остается только распределить процессорное время для конкурирующих задач.

Я рассматриваю fsmc как ресурс, за который борются задача вывода на жки и задача вывода на аудио усилитель.

Задаче вывода на ЖКИ нужен сам ЖКИ, выводу аудио - память. И где тут борьба?
То обстоятельство, что они физически оба висят на FSMC ничего ровным счетом не меняет.

Но они же не могут одновременно обращаться к fsmc. Да они должны как то разделять между собой время для обращения к fsmc, т.е. опять таки делить его между собой.

Чтобы внести ясность в этот вопрос - что вы подразумеваете под разделяемым ресурсом?

Выполнятся одновременно на одном ядре они тоже не могут.


FSMC - это просто некая шина наружу. На ней висят разные устройства - ЖКИ и память. Где конфликт?


Разделяемым ресурсом, например, мог бы быть тот же ЖКИ, если бы его одновременно хотели крутить две задачи.

Чего им его делить-то ? Процессор-то один. Каждая задача в свой квант времени, который ей выделила ОС, беспрепятсвенно общается со своей периферией.
Разделяемый ресурс начинается тогда, когда одна задача не может произвольно работать с ресурсом и должна оглядываться на другие задачи, чтобы они завершили свою работу с тем же ресурсом.
Классический пример - две параллельные задачи работают с одной переменной, увеличивая её на единицу.

Спасибо за ответы Demeny, aaarrr. Это я понимаю. Просто в своем первом посте у меня есть третий пункт:



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


К тому же, а что произойдет если переключение задач произойдет в момент обращения к шине.

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

Ну что, глубоко сочувствую. Тож один раз нарвался на эту неприятность с I2C.
Никак не разруливал эту ситуацию, просто упростил функциональность устройства.

Это не задача для RTOS.
У RTOS такт ИМХО должен быть не короче 10 мс, а у кого короче тот выбрал для RTOS неправильное тактическое применение.
Т.е. для быстрой коммутации между I2C и внешней шиной RTOS не подходит.

Что касается разделения времени владения внешней шиной, то лучше всего для этого подходит DMA и механизм приоритезации в DMA.

Как вариант для разруливания конфликта I2C и внешней шины можно было бы использовать таймера с прерываниями вне контекста RTOS.

Каким образом?


???Не понял о чем речь. Поясните пожалуйста. По i2c у меня скорость не очень большая


Если не сложно, можно более подробно осветить этот момент именно для работы с rtos.

В момент обращения к шине переключения задач произойти не может - до завершения транзакции чтения или записи по шине smc процессор как бы "висит", для медленных устройств на такой шине иногда вводится сигнал NWAIT, удерживающий процессор, пока медленное устройство не обработает запрос.
А если переключение произойдёт между транзакциями - ничего страшного не будет - задача продолжит свою работу после возращения ей управления.
Безусловно, острота такого вопроса возникает тогда, когда не хватает пропускной способности шины - либо звук захлёбывается, либо картинка тормозит. Тут уже от RTOS ничего не зависит, надо пересматривать всю архитектуру системы в целом.

Может вам просто организовать софтверный i2c и забить на хардварную проблему?

Может, лучше количеством тактов оперировать, скажем, накладные расходы оси не превышают 1% от общего процового времени

Может, лучше количеством тактов оперировать, скажем, накладные расходы оси не превышают 1% от общего процового времени?

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