Ну я в подобном случае опираюсь, естественно, на операционку - для точки отправления года три назад была выбрана FreeRTOS, как максимально соответствующая моему предыдущему опыту собственных систем и относительно бескомпромисная (и соответствующая ARM по весу) среди мелких осей. Обращаюсь, правда, с ней вполне вольно - изменений много, некоторые вещи, типа менеджера памяти вообще заменены на 100%. Добавлена дюжина системных вызовов.
IP стек 'свой' - начинался в 90x из Waterloo - рос, развивался.... Привык я к нему, очень неплохую отладку в него встроил, вот и портирую с тех пор. Файловая система на SD - с минимальнешими изменениями FatFS. На AT45 - своя простенькая, ни с чем не совместимая, но зато максимально быстрая и некоторым закосом в надежность. Само-собой консолька на RS232. Все остальное уже индивидуально по месту.

Из Вашего описания я понял что все равно придеться делать ручками ?
ИМХО, по вашему описанию получается что это вся таже "автоматная" модель, только
введен еще один уровень, каждая независимая задача вызывается не каждый такт
работы основного автомата, а просто выставляет(ползьзуясь средствами опрерационки)
некий флаг о том что она тоже хочет выполняться, ну и соответственно выстраевается очередь
задач которые ждут своего часа...
Примерно так ?

Конечный автомат, не конечный автомат - дело хозяйское, ту операционная система ни чему не припятствует.


Не вижу постановки задачи, но в самом общем случае с конечным автоматом - автомат одна из задач спит и ждет сообщений от других задач, таймеров или от драйверов обслуживающих железо. Соответственно задачи спят и ждут сообщений от автомата, драйверов или таймера. Проснувшись - посылают сообщения автомату, или драйверам, или заказывают таймер. Автомат может и сам себе сообщения посылать - удобно поставить сообщение в общую очередь, например для выдачи подтверждения по протоколу, которое, может и не нужно выдавать, если идет штатная передача информации. Сообщения, естественно буферизируются в очереди. Ресурсы делятся в соответствии с приоритетами и разные вспомогательные задачи ( типа отображения на дисплейчике) времени при его недостатке не кушают.
В общем наверное надо про общепринятые механизмы операционых систем для начала читать. Обширные словоизлияния идут от автора uCOS, есть и общие рассуждения на сайте FreeRTOS.....

P.S.
Давайте попробуем держаться к выросшей теме. Для Ваших вопросов желательно создать отдельную тему, естественно перед этим поискав на форуме.

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

В принципе здесь я как раз стоял на стороне работодателя. Да его кругозор подвёл или он текущие вопросы поставил выше задач длительной перспективы.

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

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

Да, выпирает Однако, то, что и его обозначили в этой ветке это тоже правильно.

Надо! Так жизнь интереснее, разнообразнее и движется вперед, да и самого себя, как минимум, уважать надо.

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

Да пока не в этой они ценовой нише, вот в чем дело! Пока площадь кристалла будет играть решающую роль в стоимости контроллера, 8-битники будут дешевле. Ну, допустим есть LPC2101 за 2 бакса, но много вы там напишете "прозрачного, сруктурированного, сопровождаемого, развиваемого и портируемого кода" в 2 кБ ОЗУ и 8 кБ флеши?

Все восьмибитники не дороже 2x баксов? Нет? Почему? Что скажете про восьмибитники за 4-6-8...18 баксов и их конкурентоспособность c тем-же 128K + 32K RAM LPC2105 за 5 баксов против Atmega128 c 128 + 4K RAM поядка 10 баксов? Или 2138 с 512K Flash за 7USD? Кстати, 2101 реально полтора бакса. Это изначально 'толстые' ARM. Изначально мелкие Luminary Cortex еще дешевле на пол бака-бакс за те-же размеры Flash/RAM. Ценовая категория уже давно одна, хотя 8bit продукция Аtmel уже зачастую подороже будет

Как ни странно в 8K LPC2xxx в THUMB моде с оптимизацией по размеру для С кода довольно много - у меня в 6,5K Bootloader, загрузчик во Flash (AES/HEX), консолька отладочная для Exceptions, ну и еще по мелочи. При этом подавляющее количество исходников просто отпротировано с других платформ (в частности с AVR и PC), все вполне читаемо, модифицируемо и развиваемо.

Забыли добавить 4 таймера (16\32) ,2 УАРТА,2 И2С ,2 СПИ и 70Мгц ,хотя по идее восьмибитники полюбому должны быть дешевле ,если не будут ,их через пару лет покупать никто не будет
Вообще у АРМ есть предложение для тех кто шугается 32бита , THUMP называется ,система команд практически индентична 16-ти битовой АВРовской

До кучи RTC и 8 входов ADC.

Ну этого нет и не надо

ИМХО, THUMB(16 бит) в арм пользьзуется мало кто, если хотите
большую плотность кода, то смотрите в сторону Renesas SH2-A или AT32AP7000.

Думаю ,что плотность задает компилятор , щас смотрю пока в сторону Филипсов и кейла ,потренирусь
может гляну на что нибудь другое
Сам кейл по умолчанию дает компиляцию программы в 16 бит ,а прерывания в 32 бита ,хотя можно разбивать чуть ли не каждую функцию на свой лад разрядности.

У m128 есть шина, и периферия более подходящая для ряда задач. Плюс защита в M128 сделана на порядок лучше. 5V мощные выводы, правильный PWM.

У меня на столе лежат два устройства-близнеца, m128 + 64k SRAM + rtl и LPC2106 + плиска + rtl.
Задача девайсов следующая - NAT роутер не сильно большого потока трафика (до 2kpps (2Mbps peak)) + звуковое оповещение.

И mega прекрасно справляется с задачей и lpc.
Самое веселое то, что базово в устройство закладывали LPC, но потом решили переделать на m128 из соображений безопастности и после оценки производительности, порт на M128 занял ровно 1 час. (поудалять непотребное ногодрыганье, и работа с rtl как с внешней памятью + изменение пары define'ов - определяющих типы для ARM'а все что можно вплоть до bool - U32, для меги - где можно U8, где U16, где нельзя U32).

Кода для LPC в ARM режиме получилось ~63k
Для меги - 60k


Я не вижу как прозрачность/структурированность/сопровождаемость/развиваемость и портируемость кода может зависеть того выполнен проект на 8-ми битном МК или на 32-х битном.
Все вами названное зависит только от проектировщиков и разработчиков, а уж никак не от МК под который пишется проект.

Ну это вы погорячились. ;О) Ровно вдвое. В розницу.

Не о том! Речь о противопоставлении писания крутых программ в пару килобайт написанию тех самых прозрачных и т.д. программ на C у которых есть один недостаток - они больше и немного медленнее. Вы же за час не с AVR ASM портировали на LPC? Так в чем непонимание?

Кстати о размерах - при портировании одного куска с AVR тоже получил крайне незначительное увеличение кода на ARM по сравнению с AVR. Помню довольно сильно удивился.






Не знаю о чем это Вы, но LPC в России я покупаю в MT-System за означенные цены, а Atmega128 глянул на efind и выбрал самую низкую цену, хотя там и по 20USD встречались. Так о чем мы это? О том, что 32 и 8 не в одной ценовой категории?