Особенности построения ПО 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]

AlexandrY, на счет гибкости системы я с Вами согласен. Но функционал обрисова в первом посте топика.
Что касается жесткого реального времени для АЦП. Как правило, в GPS трекерах это не требуется. И дискретизации данных в 1 секунду вполне достаточно.

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

В состав Keil MDK Pro входит многопоточная файловая система Keil FlashFS.

RAM диск в Keil FlashFS также поддерживается

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

[AlexandrY]

AlexandrY, на счет гибкости системы я с Вами согласен. Но функционал обрисова в первом посте топика.
Что касается жесткого реального времени для АЦП. Как правило, в GPS трекерах это не требуется. И дискретизации данных в 1 секунду вполне достаточно.

Функционал это что должен дивайс делать, а не какая периферия у микроконтроллера.

Т.е. какие датчики в каких задачах управления задействованы.
Например акселерометр для идентификации вибраций, или для инерциальной навигации.
Или датчики тока-напряжения для управления рулями или двигателями.
Или датчики для управления зарядником.
Или микрофоны для записи звуков и т.д.

Вот такое описание функционала и даст только представление о критичности задач и соответственно о свойствах логеров.
Кстати все что перечислил требует жесткого реального времени.

Например в моем дивайсе активируются сразу больше десятка независимых логов:
-системный (следит за порядком включения-выключения задач и другими общими событиями)
-лог протокола PPP
-лог событий для отправляемых на сервер
-лог GSM протокола
-лог GPS протокола
-лог GPRS сессий
-лог зарядника
-лог поступающих сообщений по SMS
-лог TCP/IP протокола
-лог HTTP протокола и облачных сервисов
-логи сырых данных всех UART-ов
Все логи идут в свои файлы с метками времени с точностью до 1 мкс.

А вот для быстрой периферии типа АЦП или I/O сопроцессора реализуются еще синхронные логи.
Синхронные логи могут быть очень большими, до гигабайт.
Никакой Excel и даже Matlab их загрузить не может. Пишутся специальные утилиты обработчики таких файлов.
Синхронные логи специфичны для каждого применения поэтому конфигурируются, но ini файлы для этого слишком примитивны.
Конфигурирование выполняется JSON файлами. Конфигурируется частота дискретизации, какие сигналы будут записываться, тип данных, параметры фильтрации, конвертирующие функции.
Для синхронных логов нужна большая динамическая память для буферизации.