Грамотные решения при работе с rtos Опции

[dimanisu]

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

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

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

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

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

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

[AlexandrY]

3. Кроме этого оказалось, что fsmc мешает блоку i2c(не i2s !), через который идут команды на аудио усилитель. Это такая аппаратная проблема stm32 и всплыла она уже после разводки платы. Для нормальной работы i2c требуется отключать тактирование fsmc блока.

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

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

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

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

[_Pasha]

У RTOS такт ИМХО должен быть не короче 10 мс, а у кого короче тот выбрал для RTOS неправильное тактическое применение.

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

Сообщение отредактировал _Pasha - Oct 18 2011, 11:53

[AlexandrY]

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

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