Продвинутая кооперативность: интересно, я снова изобретаю велосипед? http://www.sics.se/contiki/about-contiki.html
Есть код. Который поделен на 3 сущности:
* прерывания
* супервизор
* big loop
Произошло прерывание. Отработалось. Глубина вложенности аппаратных прерываний=1.
_СРАЗУ_ после прерывания, если только нет другого прерывания, работает супервизор. Он смотрит ситуацию по разным статическим таблицам, и определяет, сколько текущей задаче осталось работать. Пишет в специальное место. По сути, супервизор - это программное прерывание более низкого приоритета, чем все аппаратные. Оно вызывается в конце обработчика аппаратного прерывания.
Есть системный аппаратный таймер. Супервизор пишет - до какого значения текущая задача может работать. Задача читает значение таймера и сравнивает его.
Есть текущие задачи. Рамномерно по коду разбросана проверка - а не пора ли отдавать управление? Например, перед каждой достаточно длительной операцией и пр.
Если управление пора отдавать, но текущий "тик" задача не закончила, то она пишет в специальную таблицу метку - типа "меня вернуть сюда", делает ret на корневую функцию задачи, а та отдает управление супервизору.
Супервизор определяет, кому отдать время, и делает вызов корневой функции задачи.
Корневая задача в начале просматривает свою таблицу "точек останова" и делает переход на них.
Хороший fixed size memory pool менеджер сильно поможет делу. Если задаче нужна память, она запрашивает ее. Закончила обработку - освободила память.
Преимущества системы:
* нет запрета прерываний. Они не могут помешать исполнению основного кода и супервизора. Основной код общается с прерываниями через FIFO с программной блокировкой.
* основной код может использовать нереентерабельные функции.
* очень экономичное использование памяти. Ничего не используетмя "про запас".
* сильная экономия на стеках для задач.
В значительной мере это все перекликается с идеями
http://caxapa.ru/156168.html
Суть в следующем. Контроллеры с большим ОЗУ на кристалле - недостижимая мечта. Почему так - не важно, важно, что так есть и будет.
Но! Если внимательно присмотреться, но в реальности большого объема быстрого ОЗУ и в правду не надо. Если есть DMA и внешняя шина, то туда можно отогнать кучу данных, как просто в SDRAM, так и при помощи FPGA делать продвинутые дескрипторы и пр. В таком случае основное ОЗУ используется только для хранения дескрипторов данных, и его надо мало.
Также скорость камней растет, и, например, для 100 Мгц камня, который обслуживает задачи класса "GSM, ГЛОНАСС" накладные расходы на продвинутый менеджер памяти вполне допустимы и не окажут влияния на реальные задачи.
Что касается отладки, то она усложняется, но только если ее пытаться делать примитивными способами. Если же сделать систему с отладной FPGA на внешней шине + SDRAM, то можно без заметных накладных затрат протоколировать абсолютно все, в реальном времени, вплоть до выделения/отлачи каждого блочка памяти. + система упарвления проктом, которая будет автоматом анализировать лог - у кого там память утекла и пр.
В общем, сдается мне, что привычная парадигма вытесняющей многозадачности стремительно устаревает. Т.е. совсем она не удейт, это глупо, но вот по каждому чиху заводить задачу - неправильно. Вспоминаем про contiki -> и видим, сколь хорошие результаты может дать такой подход.
И еще. На самом деле, чем ограниченнее ресурсы контроллера, чем сложнее и мощнее должна быть интерированная среда для разработки. Тем выше требования к квалификации программста. Но, сдругой стороны, если кто-то ставит задачу создания систем, подобно описанной выше, при помощи стандартный IDE - он мудак.