Ага ARM9 c частотой мегагерц 600 Читаем заголовок темы про АРМ7. От производителя это хорошо,
даже если он весь в исходниках, даже на "похожее" железо само не натянется , ну и документация на "фирменную" сборку скорее всего традиционно отсутствует начисто.

Нет, из Италии я давно уже вернулся, а в Москву еще не еду.
Пока сижу в Вильнюсе.
Если будете делать на стеке от Micrium, то могу показать файл с таким WEB-сервером и с парсингом так называемых server side includes (SSI) - включений в HTML код страниц указавающих серверу сделать вставку той или иной динамической информации в страницу.
Файловая система, кстати, это проблема. Под стек Micrium-а нужна система поддерживающая многопоточность, рекомендовал бы раздобыть и фаловую систему от Micrium-а.

P.S. На Linux-е вам не пришлось бы, конечно, поднимать гору документации, потому что там вменяемая документация большая редкость

Без документации мы делат не будем... Не люблю, когда понимаю только часть системы... А остальная живет своей жизнью. И глючит, глючит...
А что можно сказать про вариант реализации протокола TCP/IP от PHY:

http://www.standardics.nxp.com/support/software/nichelite/

Видите ли, здесь важны детали.
Первое что в NicheLite смущает это подмена нормальной операционки каким-то шедулером.
Как вы будете тогда интегрировать софт 3-их фирм?
Второе это то, что упрощенные протоколы TFTP, DNS, DHCP не намного сложнее того же WEB сервера, но за эту конфетку вы лишаетесь многоинтерфейсного стека, а вдруг вам захочется вскоре иметь и PPP и Ethernet одновременно?
Что-то они там предлагают за деньги, но мне кажеться там будет уже другой TCP стек и как бы он не оказался в виде библиотек.

Пока мне хочется минимизировать софт третьих фирм. Задачи у нас компактные (кроме файловой системы и TCP/IP). Чем проче операционка тем надежнее программа. А на выходе у нас напряжение несколько десятков киловольт с токами до 40а в возможностью пробоя, который надо контролировать.
Надежность нужна как в космосе.
Поэтому будем максимум писать сами.
Но для начала очень нужны готовые блоки, чтобы не терять много времени на раскрутку.
Если они на стадии отладки покажут себя надежно, тогда их оставим и в окончательной версии.

Это не относится к GUI - контроллер дисплея не несет ответственных функций.
Его софт, возможно, мы вообще закажем аутсорсерам.

А что можно назвать "нормальной операционкой", широко используемой "3-ми фирмами" удачно портируемной на LPC 22XX, LPC 24XX?

Свой собственный софт, разработанный под конкретную задачу.

Рекомендую RTOS от Micrium, прошла самые жестокие тесты и рекомендована для критически важных приложений.
Если вам действительно нужна RTOS, то вы точно не напишите ее надежней чем Micrium за реальное время.
Еще Micrium единственный кто подробно описывает принцип работы внутренностей своих программных пакетов, на первом этапе это очень важно.
Но применить RTOS можно и неэффективно, это проблема квалификации ваших разработчиков.
Беда в том, что RTOS всегда зажата между вашими драйверами снизу и вашим приложением сверху.
Т.е. всегда есть почва для подозрений в адрес RTOS и проверить их будет очень трудно.
Для этого думаю и следовало бы выбирать сертифицированные и проверенные оси чтобы отсечь и разделить подозрения и минимизировать ненужные проверки.