Здравствуйте все! Немного обрисую ситуацию... мне, по роду своей деятельности. а я программист встроенных систем, очень скоро придётся переходить на линукс (в планах разработка девайса, работающего под линуксом)... так вот, какой линукс удобнее чтоли в плане разработки ПО и какой дополнительный инстркментарий мне понадобится? Спасибо!

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

KDE насколько я понимаю, это чтото типа рабочего стола?

Правильно понимаете, это среда рабочего стола. Можете начать с Fedora, как вам написали выше. Но это дело индивидуальное, везде свои +/- и свои грабли.

Если только начинаете работать с Linux и это связано с ARM - однозначно Ubuntu 10.04 LTS - все BSP и манулы Freescale, TI, Android на данный момент написаны на его основе.

Дистрибутив любой, но из числа тех, которые использует рядом расположенный гуру
Кросс-систему для embedded (buildroot и т.п.) поставить на этот любой дистр и ваять.
IDE к дистрам тоже особо не привязаны.

тоже хочу переходить на Linux в плане разработки... ибо как пользователь давно перешёл

Мой выбор calculate -- он же русский Gentoo. Но это путь не из лёгких. Однако достоинство в том,
что я уверен что все пакеты нужные для сборки всегда есть ибо этот дистрибутив как барон мюнхаузен вытаскивает из болота собирает сам себя.

И ещё благодаря Генте я собрал компилятор для ARM и AVR последних версий (4.7.2).

Я начал с Debian потом перешел на Ubuntu.

А почему "благодаря"? Я вот спокойно собрал 4.7.2 с graphite (ClooG и PPL) в классическом CentOS, собралось с пол-оборота, а затем еще и им собрал целый небольшой свой дистр для АРМ на базе upstart, чтобы грузился в мгновение ока. И, как то даже в голову не приходило благодарить дистр за то, что в нем есть gcc и make и они работают. Это же основа основ любого дистра

вообще, уже давно занимаюсь портами линукса, дровами, и поддержкой их - работаю в CentOS (до этого была федора, затем официальный RHEL), а из реального инструментария (по факту и по реальной жизни) только миднайт коммандер нужен...

В наше высокотехнологическое время, когда роботы бороздят просторы Марса, собирать самому тулчейны уже моветон. ИМХО, правильнее использовать что-то вроде crosstool-NG, который собирает вполне себе годный тулчейн.

вот именно, что вполне... вполне годный можно взять готовый, например arm-arago-и.т.д., и ничего не собирать вообще. Но он к сожалению не отвечает всем требованиям, чтобы бороздить просторы марса впереди конкурентов - а для этого приходится в некоторых случаях даже патчить что-то типа libgcc или glibc, чтобы какие то ее части хорошо соптимизировались например на векторные вычисления NEON'а.

А мне Debian нравится. Как я понимаю он в родстве с Ubuntu?

Да, он ее родитель и основатель своих ".deb" пакетов.

Убунта хороша разве что upstart-ом, который кстати в ембеддед удачно собрался, и дает старт системы почти в мгновение ока (после запуска ядра), а в остальном она навреное для секретарш, убунта эта, винду заменять. Где-то даже слышал, недостоверно, что в базовой установке у нее gcc нативного нету - позор
А дебиан, да, ничего, когда привычка к его дебианской структуре, а не редхэтовской.

На выбор дистрибутива может повлиять и необходимость работы с платным программным обеспечением. Оно чаще тестируется на совместимость с RHEL (Xilinx, Altera). У Debian немного другая структура каталогов и некоторая пляска для запуска будет необходима. Под Debian в отличие от SLCE (Scientific Linux Cyrillic Edition - свободная часть RHEL с добавками и хорошей русификацией, близок к CenOs) ISE(Xilinx) требовалось кое-что настроить руками для прошивки.

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



система инициализации юзерспейс - это далеко не самое слабое звено при старте системы

Наглая и злостная дезинформация . Центос это сборка десктопного RHEL из исходников RHEL, но не редхэтом. Удобна тем, что является копией редхэта, а значит вся поддержка кэденса, ментора, синопсиса, альтеры, и так далее (список всего, почти всего, софта для разработчиков) - действительна и для него. А gcc, так ему все равно какой дистрибутив. С ним проблем нет ни в каком.
Хотя допускаю, что есть и серверные сборки CentOS, как и RHEL тоже не только для десктопов есть. Однако я себе их тоже не ставил, ставить не собираюсь, и не в курсе об их особенностях, как и не пользовался серверными RHEL.


Когда все остальные звенья ликвидированы, оно становится самым слабым, причем по своей "слабости" на пару порядков перекрывает все остальное. И при этом самое сложное по трудозатратам, так как требует кардинальной переписи кучи конфигурации (например выкинуть этот злобный тормоз убут из старта системы при старте из он-борд флеши и то куда проще было).

Это же шутка была, хотя с долей правды



я всегда использую свои срипты + busybox и даже без замеров вижу что они отрабатываю на порядок быстрей инициализации ядра, а на старт приложений больше влияет наличие скоростного носителя с которого они стартуют.

Ну это смотря что стартовать и сколько этого чего стартовать. Многое то грузится из флеш быстро, а потом медленно инициализирует всякие сокеты, грузит всякие фирмвари, и т.п., поэтому upstart дает в этом случае серьезное преимущество из-за многозадачного параллельного старта сервисов. Конечно, можно и в рамках классического init это же реализовать, но не выгодно получается, в т.ч. из-за слишком большого количества параллеьно крутящихся скриптов.

Но это уже за рамками темы.

Накопитель у вас один (и судя по сайту из профиля армы у вас одноядерные) - если для каждого из приложений требуется на чтение с диска 1 сек то вы хоть парраллельно, хоть перпендикулярно их запускайте время в сумме будет 2 сек.



Интересно - вы знаете что можно амперсанд в конце команды ставить и получите тот же самый псевдопарраллельный запуск.



upstart хорош для серверов - больших и толстых и тот же RHEL его использует.



согласен

Во первых, для невнимательно читающих, повторюсь, если для каждого приложения требуется для чтения с диска 0.1 сек, а для инициализации 5 сек, причем инициализируемые ресурсы не пересекаются и во время их инициализации они почти не потребляют процессорного времени - то параллельная загрузка убыстряет время старта на (5-0.1)*N сек. А таких процессов есть и не один, особенно сервисы, работающие с сетевыми интерфейсами. Отношение времени чтения с диска к времени инициализации среднего сетевого демона именно такое на самом деле, что подтверждает и практика. Плюс к этому - поток на максимальной скорости из NAND в память занимает отнюдь не все процессорное время, он вообще-то в DMA идет, и тратить все это время впустую просто расточительство.

Во вторых, запуск с "&" хорош для себя, для дома. А мне, извините, это надо поддерживать, и унифицировать, чтобы и этому клиенту удобно было, и тому, и третьему, и чтобы это было на что-то стандартное похоже хоть как-то, и при этом грузилось хотя бы вдвое быстрее аналогичного по набору наворотов arago. Да и upstart вообще аккуратный, компактный и малоресурсожрущий, даже вместе со своей libnih, меньше этого монстра бизибокса в разы по всем параметрам, и поэтому сам по себе запускается быстрее.

А кто такой шибко умный, сам upstart выкинет, и позапускает что ему надо с "&", но пока таких не встретилось ни одного, всем дай все готовое и поддержи, типа чтобы их приложение на qml написать и оно заработало как им надо само по себе.

PS
upstart на серверах нафиг никому не нужен. там не нужны ни его скорость, ни малая ресурсоемкость, ни возможности динамического запуска сервисов для plug-n-play девайсов. Все это чисто десктопные и ембеддед фичи, но никак не серверные. на серверах обычный sysvinit рулит безоговорочно.

Если не секрет - какая ФС у вас используется для NAND ?



Тогда вы немного промахнулись, стандарт де-факто и майнстрим в Linux - systemd, upstart - это чисто убунтовская система инициализации которую разработали и поддерживают в Canonical. Собственно меня это и удивило с самого начала.



да-да, учитывая то что перед этим написали - он прямо офигеть как для embedded нужен

Секретов в линуксах не бывает Ну почти... На сегодня мы предлагаем и рекомендуем ubifs. Пробовали и исследовали jffs(2), yaffs. А вот logfs еще не пробовали, да и неохота пока почему-то.


Я то как раз не промахнулся, прежде чем на что-то поставить, все варианты инитов собрали, все попробовали в наших конкретных условиях, и сравнили. Против upstart-а остальные в условиях железяки "отдыхают", и это уже проверенный факт. Я не буду спорить, где-то наверняка он не оптимален, но не в нашем конкретном случае. И, честно говоря, мне все равно, кто его поддерживает. Для наших клиентов его поддерживаю я. Он же ведь GPL и open source, а значит подправить под свои нужды всегда можно. Вот со временем напрочь оторву его еще от dbus-а в версии для "совсем маленьких" систем (ключик у конфигуре --without-dbus будет), и вообще красота будет. Я ведь тоже когда-то не верил, что убунтоиды могут что-то хорошее и полезное сделать. А оказалось - могут. Собственно, осталось ждать не сильно долго, мы скоро этот наш дистр выложим со всеми репозиториями, и можно будет убедиться самому. А пока все же, если совсем официально - араго. А это в разработке.


Конечно для ембеддед! Из сетевых сервисов всем вайфай+блютуз+изернет дай, причем половине дай access point. А некоторым еще видео захвати, пожми, сколько кадров влезет, и по сокетам раздай. Оно за собой тащит весь нетфильтр (зачем? А фиг его знает, "хотим!"), и кучу сопутствующих сервисов, причем не бизибоксовского уровня, и все это надо естественно запустить, не запутавшись в "&"-ах.

тогда должен вас немного огорчить но с DMA тут не все так радужно
http://comments.gmane.org/gmane.linux.port...m.kernel/112063
http://lists.infradead.org/pipermail/linux...May/041178.html



буду иметь ввиду, потому что пока не нашел "золотой середины" - все приходится руками делать По поводу систем инициализации - на imx53 старт системы примерно одной функциональности Yocto-openembedded (sysvinit):Ubuntu(upstart):buildroot(busybox) по времени примерно соотносятся как 10:5:1
В общем тут очень много факторов - надо компрессию применить в ФС или с носителя данные быстрей читаются чем при переносе нагрузки на процессор, есть ли лишние сервисы, размер бинарников, с каими зависимостями собраны бинарники и нужны ли они в данном случае т.д. В целом ручная оптимизация все равно зарулит а какая система инициализации будет наверно не так важно.

Спасибо, намек понят, но пока что прецедентов глюка не было. У нас не atmel_nand, а omap2, вероятно, в нем нет этих проблем с дма, а дма включал (и проверял, что он включился) лично я - то есть сейчас "все включено" - dma+prefetch

А вы попробуйте отключить и сравнить скорость чтения/записи - возможно будете удивлены, иногда накладные расходы на инит chain dma или чтение маленькими кусочками с постоянными переключениями контекста от прерываний могут быть такими что данные просто так прочитать проще

Так прежде чем включить, оно же отключено было И скорость, и загрузка процессора записаны....

Если речь идет о целевом устройстве, то я бы ставил "Дженту": поддержка от 80486-х процессоров и выше, "АРМов", "Спарков", "Мипсов" и "Пауэр-Пи-Си"; гибкая настройка служб; сборка ОС самым свежим компилятором с нужными ключами оптимизации, что весьма прибавляет скорости работы. Читать придется много, но это того стоит. Успехов!
На компе я использовал среду разработки "Кдевелоп". Она заметно шустрее "Эклипса" и работает довольно устойчиво.

Удалено.

Моя рекомендация -- Qt-Creator примерно из той же песни что и Kdevelop и также быстрее "Эклипса" ибо они обра на Qt. Ещё есть CodeBlocks причём оба этих приложения портированы под Window.



Если вы собрали gcc c помошью системы установки то я за вас рад, а так мне кажется вы вручную распокавали исходинки gcc, запустиили configure ну и так далее. а потом скопировали полученные файлы в дерево дистрибутива причём сам дистрибутив скорее всего ничего не знает о том что у него стоит avr-gcc
а в Gentoo этого нет ибо есть утилита которая сама генерирует пакет который сам всё это делает, а захотите пересобраить или удалить система сборки emerge за вас это всё сделает.

У меня цель - собрать наиболее кросс-дистрибутивный SDK - поэтому я еще и инсталлятор к нему делал, чтобы не привязываться к манагерам пакетов, и он одинаково теперь ставится на убунте, дебиане, редхате и пр. И имеет внутри себя все необходимые "редкие" зависимости, типа того же ClooG/PPL, которого не найдешь днем с огнем в дистрибутивах. И ставится он не обязательно в недра системы, его можно проинсталлировать себе в ${HOME} без прав root-а и работать - то есть в дерево дистрибутива я его не то, что не ставил, а и не собирался ставить, максимум ему место если не в HOME, то в /opt/my_arm_sdk/. Да, и вот тут уже, именно БЛАГОДАРЯ центосу, причем не последнему, он не требует наличия в системе того, кто будет им пользоваться, какого нибудь супернового GLIBC, а довольствуется >=2.6.каким-то - то есть пойдет без танцев с бубном у гораздо большего количества людей, нежели, если бы я его собирал под какой нибудь свежайшей и крутейшей системой.

А попробуйте:
archlinux
Там огромный репозитарий, всегда новые и свежие пакеты, есть и AVR, и ARM:
AVR
ARM