Особенности построения ПО c использованием RTOS, Взаимодействия между отдельными задачами, событиями ??? Опции

[Asteo]

Доброго времени суток!

По немногу разбираюсь с freeRTOS. До этого использовал архитектуру: "Суперцикл+прерывания".

Интересуют особенности построения архитектуры ПО с ее использованием.
Т.е. "Как наиболее грамотно и рационально произвести взаимодействия между отдельными задачами, событиями ".

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

В кратце:

Планируется использовать несколько цифровых и аналоговых GPIO.
Повесить датчики на стандартные интерфейсы(I2С,SPI,UART,1-Wire).
Использовать несколько каналов АЦП и т.д.
Для ведения "event log" планирую какую нибудь внутреннюю память (FSMC или SPI Serial Flash -- еще не определился),
а также microSD-card.
С помощью GSM модуля данные будут передаваться на сервер.
В качестве отладочных стендов использую STM32f103RET6 от "Terraelectronica", SIM68v и sim900 от SimCom.

Идею обрисовал , теперь ближе к делу.

Поставил RTOS, прикрутил задачу взаимодействия с GPS , установил FatFs от Чана (SDIO) , пишу лог NMEA сообщений на microSD.
Но это сейчас все в одной задаче. Чтобы было видно, что RTOS не завис, параллельная задача мигает диодом .

Дальше необходимо организовать сбор данных с других ресурсов --- GPIO,АЦП, I2C .
И вот тут у меня как у начинающего и возник вопрос ---Как с помощью freeRTOS наиболее рационально и целесообразно осуществить сбор данных с разных ресурсов микроконтроллера и осуществить их запись по протоколу в память?(Передачу по GSM пока не трогаем, хотя и подразумеваем что она будет осуществляться в дальнейшем.)

А хочу я от вас я хочу ответы по типу:


1) Высокоприоритетные задачи обработки периферии с использованием соответствующих прерываний собирают данные. Используя механизмы семафоров и очередей передают их низкоприоритетной задаче, которая собрав все необходимые данные пишет их на SD карту.

2)Высокоприоритетные задачи обрабатывают данные и каждая пишет свой собственный лог в буффер во flash памяти(возможно даже дублирует). Низкоприоритетная задача читает все эти логи и пишет на SD card.

3) Ваш способ + обоснование "Почему так".

[Jekin]

Кольцевые буферы во FLASH это скорее всего будет изобретение велосипеда.
Придется все равно решать проблему одновременного доступа нескольких задач к FLASH, получить при этом проблемы с неопределенностью времени доступа.
В результате будет непредсказуемое взаимовлияние одних задач на другие.

Asteo же планирует использовать один файл лога для всех задач. Может все же тогда проще писать во флеш из одной задачи-логгера, как я писал выше?

[AlexandrY]

Asteo же планирует использовать один файл лога для всех задач. Может все же тогда проще писать во флеш из одной задачи-логгера, как я писал выше?

Что-то конкретно можно обсуждать только зная функциональность всего приложения и ограничения платформы.
А так в общем я отдаю предпочтение не "проще", а "гибче".

RTOS ведь выбирают когда хотят нагрузить побольше функциональности.
Вопрос "проще" тут бесполезен ибо конфликтует с целью.
А вот гибкость однозначно облегчит будущее наращивание функциональности.

Поэтому автономных асинхронных друг к другу логгеров должно быть много.
Отключается модуль (скажем Wi-Fi вместо GPRS) и автоматически перестает работать его логгер.

Потом для периферии типа АЦП нужен синхронный логгер с жестким реальным временем, а логгер GSM можно сделать и асинхронным.
Реально быстрый синхронный лог возможен только в процедуре ISR
И тут получается различная реализация разных типов логеров.

Я использую для логгеров всегда неблокирующие очереди, но не конвейеры. Элементы очередей это указатели на структуры сообщений.
Выделяется ли память структурам динамически или статически зависит от требований к быстродействию. Конвейеры в данном случае менее предсказуемы.

[Asteo]

Что-то конкретно можно обсуждать только зная функциональность всего приложения и ограничения платформы.

В самом начале темы функционал почти описал, а также говорил,что как отладочник использую STM32f103RET6 " от "Terraelectronica
При разработке собственного железа планирую использовать STM32F103VG.
из Flash присмотрел SST26VF064B --- Microchip 2.7V to 3.6V 64 Mbit SPI Serial Flash .
В качестве среды использую Keil

Я использую для логгеров всегда неблокирующие очереди, но не конвейеры. Элементы очередей это указатели на структуры сообщений.
Выделяется ли память структурам динамически или статически зависит от требований к быстродействию. Конвейеры в данном случае менее предсказуемы.

Если можно,эту часть объясните по подробнее, или дайте ссылку где почитать "у Курница " .
Также заинтересовали многопоточные FS на RAM --- в функционале Keil имеется что-то подобное?

Сообщение отредактировал Asteo - May 17 2014, 03:04