Evgeny_CDАрхитектор (14.02.2014 19:03, просмотров: 154) ответил 1111111 на Мои поделки тормоза до 1мс и не заметят. На такую примерно задержку и рассчитывал
В кооперативной части проекта анализировать задержки менее 1 мс, в общем случае, не надо. Идея такая. Заточено под быстрые современные MCU с тактовой от 100 Мгц. Есть гибридная ОСь. Под ней живут прерывания и несколько потоков в режиме вытеснения.
Все потоки, кроме одного, компактные по стеку. Они его едят мало и гарантированно предсказуемо, что позволяет очень точно выставить границы стеков потоков.
Прерывания имеют собственный стек.
Один поток особенный.
Ему под стек отдано все, что осталось после глобальных переменных, статических переменных, какого-нибудь продвинутого управления выделением памяти и необходимых ресурсов для прерываний.
Внутри этого потока живет кооперативная ОСь того или иного вида, и собраны все задачи без жесткого RT. И характерная точность привязки событий в этом потоке к внешним событиям от 1 мс и более. Рассматриваемый абортатор живет именно внутри этого потока.
Например, UART получил байт или пачку байтов. Прерывание положило их в память. И вызвало высокоуровневый обработчик. Который один из легковесных потоков, описанных выше.
Этот обработчик "рассмотрел" эти байты совместно с принятыми ранее, и решил - PPP пакет есть или нет, и подсчитал CRC, и, возможно, разложил все в удобную C структуру.
После чего выдал сообщение "толстому" потоку, что, мол, пакет готов, или что пришел битый пакет.
Шедулер кооперативного потока при принятии решений просмотрел 2 очереди: очередь ожидающих данных и очередь таймерных событий и выдал управление кому- то согласно заданной стратегии.
Резюме:
* Имеем экономию памяти
* для быстры ядер можем не проиграть по скорости относительно классического подхода. Ибо если при классической вытесняемости у нас кончится память, и мы прикрутим внешнюю - одно обращение в SDRAM без внешнего кеша будет по времени не сильно больше работы "абортатора".
Но, с другой стороны, для больших проектов кооперативка крайне опасна с точки зрения трудноуловимых глюков. Нужно делать тулзы для автоматического анализа кода, который отслеживает изолированность задач по данным, и общий граф связей в системе.