Особенности построения ПО 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
И тут получается различная реализация разных типов логеров.

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

[kolobok0]

...Поэтому автономных асинхронных друг к другу логгеров должно быть много. ...

цена таких логгеров? Просто типа закачать потом в эксель и красиво выдать кривую? Потому как для анализа глазками
шарахаться между файлами по временным срезам - вряд-ли удобное решение...Если из множество кэшей писателей захотите свести
к одному выводу в файл - то там ышо круче рассинхронизация начнёт наблюдаться... На любителя или медлунных систем типа хэйлохты мир
- имхо...

========

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

рулится всё это из интерфейса и с самой флэшки, типа ай-най файлика...