Возникла задача поднять Linux на ARM7 ( с ценой кристалла около 10$, ну до 30$).
Мы смотрим на линейку NXP например: LPC 2294.
Нам важно наличие CAN. Внешняя шина для подключения графики. Работа с внешнией FLASH памятью. Linux нужен не только для графики. Система должна иметь развитое управление через Ethernet, возможность настройки через WEB интерфейс.

Вопрос:
реально ли это?
если нет, то какой младший кристалл, подходящий для этого?
где можно найти доки по теме?
где можно скачать версию Linix?

Всем заранее спасибо!

Прибейте ее - на многих ARM9 Линукс даже в кастрированном виде ничего хорошего из себя не представляет, ну а уж на ARM7 - чистый садомазохизм, тем более для декларированных целей, ибо кроме изрядно монстрального для приборных целей IP стека и файловой системы (да и те придется привязывать к железу) больше ничего (CAN, LCD) от волшебного слова Linux на Embedded не получите.

Вы уж извините иностранного гражданина , но...
На ARM7 скорее всего придется садить ucLinux. По причине отсутсвия такой вещи как MMU.
Можете начать отсюда http://www.uclinux.org/ports/ и дальше по ссылкам.

Из ARM9 достаточно простой вариант - платы от Technologic Systems http://www.embeddedarm.com/epc/prod_SBC.htm. Но у них в поставке разный линукс По моему опыту TS Linux кал ещё тот (IMNHO). У них есть варианты на базе Debian - те ещё ничего. Ещё как вариант - купите демоборду на EP9302 с софтом http://www.olimex.com/dev/cs-e930x.html, а понравится - повторите. Я не пробовал Всё это (в разной степени сложности) может быть повторено.
После работы в качестве "скорой помощи" (по линуху) с ребятами, применившими это дело по назначению, полностью отказался от намерения применить линух в проекте на XScale255. Внимательный просмотр сорцов некоторых дров меня полностью убедил правильности принятого решения.

А где такой купить можно?

TS7xxx покупали напрямую у производителя.

Очень убедительно! Значит способ решения поставленной себе задачи нами выбран не верно.
Тогда дайте совет:
с помощью чего можно быстро поднять приборный IP (настройка устройства через WEB) или все же все придется писать ручками? Какой объем транслированного кода получается для настройки 2-х десятков параметров с примитивной табличной картинкой?
С файловой системой проще. Тут можно не поднимать стандартную. Можно обойтись и чем то упрощенным. Впрочем разбор FAT наверное есть в сети готовый.

Абсолютно на любом стеке, ибо по сути ничего проще меееедлеееного WEB сервера об одну страничку для одного клиента почти и не существует

http://82.46.28.98:47821/

Присоединяюсь к zltigo.
Ещё скажу, что иногда и довольно часто применяют передачу параметров в оффлайне - например, через чтение/отправку почты, через работу с файлами на сервере по TFTP... Такое, например, приходится применять при работе по GPRS, когда провайдер не разглашает выданного IP;(.

У меня плата промышленного стандарта X-Board
c PXA255 на борту ,
от поставщика платы имею тестированный линух с ядрами 2.4 ,2.6
проблем с основными подсистемами ввода вывода я не наблюдал.
СAN встроенного нет - нужен внешний чип.

Вы только не забудте про продажу PXA Marwellу, и рыночные последствия этого.

Присоединюсь к мнению zltigo и sensor_ua

Я до запуска плат не имел (не знаю почему, но не пускало) доступа к схемам референсных бордов, на которые Интел ссылал;( Потом, правда, попустило, но поздно... Потому мне ещё один напильник для Линукса на PXA255, если применять, понадобится;(((

Это проблема поставщика плат Xboard.
Пока в обозримом будущем он гарантирует
поставку этих плат, а где он чипы берет у интеля или Marwell
мне парралельно.
Да и массовое применение PXA на наладонниках
убеждает , что чипы будут в обозримом будущем.

WEB сервер - это реально пару десятков строк на С.
Буквально по шагам:
1. Создать сокет на прослушивание
2. Ждать пока кто-нибудь не пришлет запрос и получить сокет соединения
2. Получить текстовую строку запроса от клиента и найти там в нужном месте слова GET или POST
3. После этих слов найти имя запрашиваемого файла открыть его, передать и закрыть
4. Закрыть сокет соединения и идти к пункту 2

И все, весь сервер! Чистого кода пару сотен байт если с проверками.
Другое дело TCP/IP стек с интерфейсом сокетов BSD и драйверами под физическую среду.
Килобайт 40 займет + место в RAM для буферов пару килобайт. Стеки с BSD есть у Micrium, в lwIP, из eCOS можно взять.
Количество параметров на размер кода сервера вообще не влияет, рекомендую для управления параметрами протокол SNMP. Избавитесь от нужды разрабатывать клиентский софт или динамические WEB страницы. Есть туча программ-броузеров SNMP + OPC серверы к SCADA + компиляторы MIB файлов создают автоматом встраиваемый C-код из текстовых описаний ваших параметров и т.д.

Спасибо AlexandrY все выглядят понятно, и, похоже, что по Вашему тексту все можно будет легко раскопать.
Пока не работал, кажется, что придется поднимать гору документации и примеров.
Вы в Москве? Или в Италии?

Ага 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 и проверить их будет очень трудно.
Для этого думаю и следовало бы выбирать сертифицированные и проверенные оси чтобы отсечь и разделить подозрения и минимизировать ненужные проверки.