ARM с Linux на борту., С низким энергопотреблением. Подскажите. Опции

[JeDay]

Всем привет
Есть задачка разработать автомобильное устройство с линуксом на борту. Процу большая производительность не нужна. Надо выбрать с минимальным токопотреблением и возможно готовым фреймворком управления питаем и частотой.
Если кто нибуть проходил данный путь, посоветуйте плиз. Мои познания пока ограничены асортиментом план с starterkit. Как вариант iMX233 думаю применить..

[JeDay]

Подробности описывать не могу, нельзя на всеобщее обозрение выносить.
Это автомобильный контроллер, с возможностью автономной работы от встроенного акумулятора. Линух нужен для упрощения реализации, на обычном МК реализовать будет тяжело. Процык нужен не прожорливый, документирован и с хорошо отлаженным BSP.
Из инфы выше понял что самсунг 2410 староват. Буду изучать как с остальными дела обстоят которые назвали.

[AlexandrY]

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

Вот это меня всегда интриговало, как люди определяют, что на линуксе будет проще реализовать.
Да еще в автомобиле с совершенно непредсказуемой электромагнитной обстановкой.

[jcxz]

Вот это меня всегда интриговало, как люди определяют, что на линуксе будет проще реализовать.
Да еще в автомобиле с совершенно непредсказуемой электромагнитной обстановкой.

Такие люди не хотят (как будто боятся) изучать глубоко CPU, периферию, как с ней работать, ожидают что некие "чудесные драйвера линукс" написанные хрен знает кем с хрен знает какой кривости руками всё чудесным образом за них сделают. В результате получается монстр, внутри у которого что-то творится (что именно - такие кодеры понятия не имеют), оно то работает, то вдруг глючит в совершенно неожиданных местах. Начинаются шаманства с задержками, перемещениями по областям памяти, заменами дров и версий в попытках это заставить хоть как-то работать...
И это всё с огромными ресурсами (производительности, памяти, лишних микросхем и т.п.) потраченными сверх всякой меры на данную простую задачу...
А потом ещё оказывается, что некоторые задачи (простые без наличия линуха), но требующие реалтаймовости (которую линух не может дать) или нестандартной работы с периферией (не заложенной в индусских дровах), никак невозможно реализовать на данном жирном CPU из-за наличия линуха, и приходится схемотехникам добавлять ещё отдельный контроллер для решения этих задач (что сразу порождает необходимость в дополнительном программисте и всякие проблемы типа - протокола взаимодействия, обновления ПО этого контроллера в работающей системе и т.п.)...
В результате - получается поделие с кучей неадекватных ограничений типа: невозможности выключать питание в произвольное время (из-за FS), временем старта системы порядка минуты (когда подобная задача реализованная без линуха стартует менее чем за секунду) и в это время тож нельзя питание отрубать, требованиями жирного CPU + всякие NAND и NOR с параллельными шинами и т.п.
Реальное время разработки такого поделия (с поисками различных плавающих багов из-за чужих дров) в результате значительно превышает время решения "stand alone", которое если бы было реализовано, давно бы уже нормально работало.
Зато можно гордо заявить заказчику "Linux embedded!"....

PS: К сожалению очень часто приходится в последнее время сталкиваться с этим в моей практике...

[haker_fox]

Такие люди не хотят (как будто боятся) изучать глубоко CPU, периферию, как с ней работать, ожидают что некие "чудесные драйвера линукс" написанные хрен знает кем с хрен знает какой кривости руками всё чудесным образом за них сделают.

Гм... Это типа шутка такая? Как будто написание программы - это изучение CPU и периферии. Ну давайте по порядку:
1. FS. Пусть это тривиальная FAT12/16/32. Здесь нужно разобраться не столько с драйвером флеш-памяти (SD, SPI, EMC), сколько с реализацией файловой системы. Она хоть и не очень сложная, но повозиться месяцок придётся.
2. Сеть. Драйвер MAC штука не тривиальная, но по сравнению с документом RFCxxx на несколько сотен страниц - детский лепет. А "дополнительные" протоколы типа PPP и т.п.?
3. USB. Там можно застрять на долго, если нет опыта.
4. Графика на дисплей. Ещё месяцок...

Потом всё это дебажить, искать ошибки.

Можно взять готовые реализации файловой системы как FatFS, для сети есть куча свободно выложенных стеков таких, как uIP; даже для USB можно найти готовые и бесплатные реализации стеков. Но чем это будет отличаться от драйверов Линукса, которые

написанные хрен знает кем с хрен знает какой кривости руками всё чудесным образом за них сделают.

Т.е. в любом случае Вы рекомендуете писать всё ПО самому с нуля, если нет предыдущих наработок.

А что делать человеку, которому нужно сдать проект в некий поставленный срок, и Линукс не припятствует решению задачи? Ведь что делает ТС не оглашено. Может быть это некий медиа-центр для автомобиля?

ну вот, пока излагал свои речи, уважаемый demiurg_spb сказал кратко, и по делу!:)