Search in topic

Создание собственной системы стабилизации

Серёг, нафига за ними гнаться?

Чтоб за кем нибуть угнаться или перегнать, изначально нужен системный подход - идея, проект, команда фанатов, распределение полномочий по направлениям, финансы наконец, и … то не факт что будет результат, примеров тому море… (в одиночку +1 бороться со всем миром сложно, но можно).
Ктати, если “вещь” хорошая (как у топикстартера) то она всеравно найдет своего зрителя со временем… было масса казалось бы “передовых амбициозных” проектов которые как то сами ушли в небытие, естественный отбор работает, однако…

изначально нужен системный подход

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

всем нужна выгода, а где её взять?

Ды не всем, (надеюсь)))… сложней наверно воодушевить разных людей одной идеей (у каждого “художника” будет свое мнение), а там уж как получится (хобби же всетаки)…
Ну или кредит в банке тогда брать, как все в “цивилизованном” мире и по общей схеме - со всеми вытекающими… и китайцы кстати не бесплатная рабсила, себе на уме, ищ кто кого хитрей х.з.))…
Третьего не дано.

Не знаю как у вас, а у нас кредит - это минимум 36% годовых, в “цивилизованном” мире пальцем у виска покрутят с такими предложениями…

ну как сказать, оси типа ртос и чибиос… оно как-то не очень помогает, если у тебя всё выстроено до этого, наттикс - да такая никс-платформа позволяющая “пообщаться” с железом, но “тяжелая” да и добавление нового устройства - ацкий труд (… так бы мелкая уже давно под ней жила, сейчас как раз пытаюсь запустить отладочную консоль под чибиос и тоскую по консоли наттикса )))

Вообще меня всё устраивало бы “на прерываниях”, но дело всё в том, что по мере разрастания кода в вычислениях ИНС начали появляться пропуски низкоприоритетных прерываний (вывод в консоль, визуализация), так может дойти и до чтения приёмыша и отправки телеметрии. Посему надо отделить “низы” от “верхов”, чтоб прерывания могли “переслать один байт” в процессе “размышлений о бытие”. Сменить приоритеты не получиться, т.к. мелкие прерывания иногда тянут за собой тяжелые, но не критичные по времени и актуальности данных, расчеты. Ну и плюсом хотелось иметь движек для “постоянного оборота” не привязанных к жесткому времени задач (моргать СВД, выпуск шасси, закрылков, бортовая “медленная” автоматика и тд), с разными готовыми РТОСами на этот счёт будет сложно договориться…
Поэтому планирую за основу взять простой движек дополнить семафорами и отдельным классом задач-обработчиков без собственного стека (которые ранее в порываниях крутились), да и было бы неплохо через USB монтировать СД или фрам на подключенный комп. Да ещё в перспективе “инвентаризировать” все устройства полетника в АПИ, ибо пользуем мы их в одних и тех же режимах (усарт, и2ц, спи, гпио), чтоб зоопарка “в низах” не было.

Вот ведь, оказывается, в фриртосе есть уже такой функционал, задачи без своего стека, сопрограммы называется… Вот и думай… то ли своё рисовать, то ли фриртос влепить? Вообщем если в течение недели своих результатов не будет, буду ртос ковырять.

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

Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.

Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.

Привет, Макс! Не скажи! Я вот обзаботился разобраться в деталях, как всё это работает, и щас смотрю исходники ртоса и всё понятно. Но мне все возможности фриртос особо не нужны (возможно пока) , посему я не буду ждать, а попытаюсь сделать необходимый функционал сам. К тому же заменить на фриртос мою поделку будет не сложно, вызовы методов сделаю аналогично фриртосу.

Я вот обзаботился разобраться в деталях, как всё это работает, и щас смотрю исходники ртоса и всё понятно.

Если все понятно, то зачем изобретать свое. FreeRTOS все же оттестирована и портирована на множество камней.

К тому же заменить на фриртос мою поделку будет не сложно, вызовы методов сделаю аналогично фриртосу.

Ну и смысл изобретать свой велосипед.

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

здесь матерными словами писать нельзя:( дешевше “крутыми” датчиками обойтись )))

Если все понятно, то зачем изобретать свое. FreeRTOS все же оттестирована и портирована на множество камней.

Ну и смысл изобретать свой велосипед.

Смысл есть, ибо:

1. фртос сделана для удовлетворения максимально широких потребностей максимального количества использователей. Мне же надо обеспечить максимльно удобно свои и только.
2. Во фриртос задачи вешаются динамически, мне это не надо, у меня задачи и обработки будут статическими в виде глобальных структур. Что это дает? Нет сложного механизма списков и выделения памяти. Зачем мне использовать сложные, универсальные и тяжелые механизмы РТОС, в которых я всё равно всех тонкостей не знаю, если достаточно простого с ограниченным (и достаточным!) набором функционала?
3. Большая часть моего кода - обработчики событий (сопрограммы в терминах фриртос), а в ртос они всегда в низком приоритете относительно задач. Т.е. использовать сопрограммы как я хочу нельзя. Да можно было бы вызывать их из задачи по семафору, но это опять усложняет механизмы (и увеличивает время реакции!) и плодит частные стеки, ведь обработок нужно более 20, либо нужно делать одну задачу (или 3-4 по функционалу - инс, навигация, связь и т.п.) с выборкой вызовов обработчиков по семафорам. По сути ещё один или несколько планировщиков второго уровня, управляемых планировщиком РТОС через сложный механизм списков… Оно мне надо?
   А так конечно подкупает простота: подключил файлы к проекту, исправил конфиг и вперед…

Но ГУИ и сетевые приложения безусловно нужно рисовать из под РТОС, хотя это другая история )))

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

Алексей, дык оно и так: вся летательное ПО крутится в полётнике, управление двигателями в регулях, визио ( у кого есть) в отдельном вычислителе, ну и у пикса для переифиии отдельный проц… такшта, всё уже есть… Полетные же алгоритмы и так вполне надежны в плане “подвеса” вычислителя, но не надежны с точки зрения обработки инфы ( в разной степени) и получения результатов, тут поле не пахано ( ну мож только отдельными гражданами ).

дешевше “крутыми” датчиками обойтись )))

насчет дешевле это вряд ли, то что лежит в цене тех же порядков ничего не даёт, а оптогироскопы это уже совсем другие деньги.

обработчики событий (сопрограммы в терминах фриртос)… использовать сопрограммы как я хочу нельзя.

в терминах freertos сопрограммы — подпрограмма с множеством точек выхода -> продолжения выполнения. в них пихают либо самые ненужные, либо самые простейшие действия, на которые действительно жалко тратить память. если обработчики событий попадают под это определение, то у вас очень необычный стиль программирования.

у меня задачи и обработки будут статическими в виде глобальных структур. Что это дает? Нет сложного механизма списков и выделения памяти.

а контролировать и гарантировать атомарность будете ручками? одна задача начнет запись в вашу глобальную структуру, планировщик запустит вторую задачу на чтение этой структуры, не до конца обновленной. собираетесь в конце каждой вешать флаг готово/не готово? не факт, что ваш велосипед не превысит сложность имеющихся и “незаметных” инструментов.

кстати, что сложного в однократном выделении памяти при создании задачи?

Оно мне надо?

по моему, все ваши требования укладываются в

while(1) {
task1();
task2();
...
taskN();
}

со вставкой в начало каждой задачи простейшего диспетчера отслеживающего количество тиков.

в терминах freertos сопрограммы — подпрограмма с множеством точек выхода -> продолжения выполнения. в них пихают либо самые ненужные, либо самые простейшие действия, на которые действительно жалко тратить память. если обработчики событий попадают под это определение, то у вас очень необычный стиль программирования.

У меня наоборот, всё критичное выполняется в обработчиках, а в “задачах” самые некритичные действия.

а контролировать и гарантировать атомарность будете ручками?

Ручками, всё и так контролируется.

не факт, что ваш велосипед не превысит сложность имеющихся и “незаметных” инструментов.

Думаю что не превысит, но если превысит, так же легко уйду в ртос.

по моему, все ваши требования укладываются в
Код:
while(1) {
task1();
task2();
…
taskN();
}
со вставкой в начало каждой задачи простейшего диспетчера отслеживающего количество тиков.

Укладывается, но не в такою простую, нужен опрос состояний датчиков и выполнение обработок.

Да и вообще “вращалка” задач мне пока и не актуальна, важно изменить принцип вызова обработчиков по событию. Сейчас так: готовность датчика - запуск чтения через КА в прерывании - вызов обработчика из прерывания, т.е. вся обработка в прерывании, а надо чтоб в прерывании обновился датчик, после чего обработка прерывания завершается, управление предается планировщику, планировщик запускает вычисления.

всё критичное выполняется в обработчиках, а в “задачах” самые некритичные действия.

ну я и говорю, очень необычный стиль.

вся обработка в прерывании, а надо чтоб в прерывании обновился датчик, после чего обработка прерывания завершается, управление предается планировщику, планировщик запускает вычисления.

если вычисления полностью зависят от обновления датчика, то накой нужен планировщик? это линейная задача, практически атомарная, а вы ее зачем-то бьете на части. подозреваю, что с остальными “более 20 обработками” происходит так же.

ну я и говорю, очень необычный стиль.

Наверное, если обычным считать программирование на Бейсике.

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

Нужен для разделения получения данных от их обработки. Бить на части нужно, потому что, способ получения данных (“низы”) для разных платформ может быть разный, а “верхи”, обработчик для всех один и обращается к абстрактному вектору из абстрактного датчика по обновлению данных в нём. Безусловно всё это можно было “выпрямить” в линейный алгоритм внутри задачи ртос, но так сложилось исторически, и упрощать это СЕЙЧАС я смысла не вижу. Зачем то, что работает явно, загонять в экосистему, которая от меня скрыта? Я просто хочу разорвать “атомарную цепочку” на “верх” и “низ” в процеесе выполнения, а не только в структуре проекта, ну и плюсом получить механизм “вращения” задач.

но дело всё в том, что по мере разрастания кода в вычислениях ИНС начали появляться пропуски низкоприоритетных прерываний

Это признак того, что время выполнения прерывания уже больше периодичности вызова… (определяется и лечится легко).

с разными готовыми РТОСами на этот счёт будет сложно договориться…

Имею сказать - CoOS мучаю уже год, задержки прерываний -0, все вроде работает даже “из коробки”, проще чем FREE RTOS, чего ещё надо ?, советую обратить внимание… (один минус описание слабовато…)

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

Реализовать это “общение” - задача не из тривиальных, и дико медленно получится, и по факту на каждом “модуле” должна быть многозадачность, иначе приоритет задач общения придется ставить наивысшим… т.е. о реалтайме можно забыть… (короче - думал, пробовал, непонравилось, выкинул…))))

Новый проект, где большее количество задач и меньше критичность по выполнению, буду делать на ртос. Торжественно клянусь )))

время выполнения прерывания уже больше периодичности вызова…

нет это не так, это период обработки низкоприоритетного прерывания меньше, чем вычисление “навалившихся” приоритетных, описывать “многа букафф” будет, но попробую кратко, как пример:
“вдруг” привалило данных по датчикам ИНС, стало быть в приоритетных прерываниях надо последовательно обсчитать интеграцию, местоположение (по барику и ГНСС) и коррекцию (3-4 задачи последовательно), а в это время считается период входного ППМ. Получается так, что входной фронт поймали, а спад не успели.

меньше, чем вычисление “навалившихся” приоритетных,

Тогда это проблема не в прерываниях-как таковых, а в расстановке приоритетов… (причёсывать надо).

проблема не в прерываниях-как таковых, а в расстановке приоритетов…

Нет, я об этом выше писал. Проблема действительно в том, что обработка прерываний длинная, но сам цепочки состоят из 10 “низов”- 1"верх" (длинный “верх” обрабатывается 1 раз из 10 вызовов). Так например получение инфы с приемыша, надо “поймать” 16 перепадов чтоб получить кадр управления, по которому вычислить “задатчик положения”. Ловить перепады быстрая задача (“низ”), а формирование управления в АП (“верх”) долгая. Соответственно я могу на недолго прервать расчёт “верха” ДУС на обработку “низа” ППМ, но нельзя прирывать “верх” ДУСа “верхом” ППМ. Так понятно?

То есть я хочу дать “низам” приоритет выше “верхов”, при этом сохранив их горизонтальные приоритеты меж разными обработками. Было бы хорошо вызывать прерывания для верхов программно, но даже у СТМ32 нет такого количества векторов.

Так понятно?

Понятно… Просто из двух “конкурирующих реалтаймов” (ДУС и ППМ), один наверно придётся в “свободное плавание” отпустить с поправкой на SysTick… , хотя возможные задержки и искажения результатов могут быть настолько малы что ими можно пренебречь… (это просто мысли вслух, не более… у меня ППМа нету, главный - ДУС и всё…, поэтому и проблем этих нет))