Средства и методы разработки

Продвинутая кооперативность: интересно, я снова изобретаю велосипед? 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 - он мудак.