[usercod 0]

Добрый день, друзья!

 

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

Оба борда поддерживают Linux и имеют примерно одинаковую периферию.

 

Отличительные особенности:

 

1. OMAP-L138(TMDSLCKDK138)

- DSP(TMS320C674)+ARM9(ARM926)

Тут меня привлекает двухядерность и само ядро С67. Я в основном пишу на С5000 и хотелось бы попробовать С67 в деле.

 

2. AM335x(TMDSSK3358)

- Android

- LCD

Здесь можно еще бесплатно и Android изучать.

 

Что думаете?

Изменено 30 мая, 2015 пользователем usercod

[aaarrr 63]

Если уж тема в форуме DSP, то вариант 1 :)

[usercod 0]

Если уж тема в форуме DSP, то вариант 1 :)

 

ахаха законно :rolleyes:

 

Ну а так, в принципе, стоит ли рассматривать Android, как что-то, что стоит изучать?

[aaarrr 63]

Смотря с какой стороны рассматривать. Если как средство для зарабатывания денег путем написания ПО под него, то платформа AM335x, наверное, не самый оптимальный выбор. Или речь идет об использовании Андроида как базы для собственных изделий?

[usercod 0]

Смотря с какой стороны рассматривать. Если как средство для зарабатывания денег путем написания ПО под него, то платформа AM335x, наверное, не самый оптимальный выбор. Или речь идет об использовании Андроида как базы для собственных изделий?

 

Только как платформа для встраиваемых приложений.

 

Стоит уточнить, практически все современные embedded systems истользуют операционки и знание Linux становится необходимым требованием к кандидатам на получения работы. Можно ли рассматривать Android в таком же ключе?

[aaarrr 63]

Можно ли рассматривать Android в таком же ключе?

ИМХО, пока рано. И не выгодно для соискателя, если сравнивать с прикладным программированием под А.

[usercod 0]

ИМХО, пока рано. И не выгодно для соискателя, если сравнивать с прикладным программированием под А.

 

Отлично, спасибо за помощь! :rolleyes:

[jcxz 184]

Стоит уточнить, практически все современные embedded systems истользуют операционки и знание Linux становится необходимым требованием к кандидатам на получения работы.

На линухе свет клином не сошёлся. Кроме него полно других embedded ОС.

К примеру я на том-же L137 (на ARM-ядре) использовал uCOS.

[ASN 0]

usercod

Оба камня хороши. Изучать, видимо, лучше тот, который ближе к планируемой работе.

AM335x - это телефоны, планшеты, IP-камеры;

OMAP-L138 - малопотребляющая аппаратура, SDR, медицинские приборы.

IMHO, OMAP-L138 для изучения попроще будет на первом этапе, поскольку ARM926 попроще в освоении, чем Cortex-A8. Но это только IMHO.

Думаю, лучше начать OMAP-L138: освоить Linux, а затем и Android.

 

[sysel 0]

У OMAP-L138, L137 есть несколько подводных камней:

 

1) у ARM-ядра отстутствует FPU. Можно, конечно, достаточно будет софтовой арифметики с плавающей запятой, и/или переноса всех операций с плавающей запятой на DSP.

 

2) Если не достаточно функций библиотеки DSPLIB для DSP ядра С674x и требуется создать что-то своё, надо погружаться в дебри архитектуры С674x. Код с плавающей запятой на "С" (без оптимизации под архитектуру С674x) работает на DSP ядре медленее чем на Cortex-A8 при одинаковых тактовых частотах (запускал неоптимизированное под архитектуру быстрое преобразование Хартли на С674x и на iMX535 на частоте 300МГц: DSP: 30мс, A8: 8мс. Хотя по мегафлопсам С674x в 6 раз круче).

 

3) Пропускная способность контроллера динамической памяти. Если использовать видеоконтроллер, то даже на не очень высоких разрешениях экрана он "съест" очень много.

 

Для изучения линукса я бы взял BeagleBoard/BeagleBone платку на AM33x. Много примеров, разные сборки, комьюнити и т.д.

 

В догонку:

* У AM33x есть видеоускоритель (в отличае от L138), есть поддержка OpenGL. Для линуксов, андроидов и Qt вещь крайне полезная.

* У AM33x есть расширение инструкций NEON (производительнность/МГц ниже чем у С674x, но всё-таки довольно шустро). Есть библиотеки DSP под NEON. Выполняется всё на ARM ядре из одной программы, не надо осваивать связку ARM+DSP (L138)

 

[usercod 0]

sysel, классный совет, спасибо! Присмотрелся к BeagleBone - крутая штука и стоит не дорого)

[usercod 0]

Если уж до конца заморочиться, то стоит рассмотреть Raspberry Pi vs BeagleBoneBlack.

 

В Raspberry Pi мне нравится стандартный HDMI, 3.5mm audio in/out, видеопроцессор поддерживающий 1080р и просто огромное количесто учебных материалов и горовых проектов.

 

BeagleBoneBlack - проц новее (1GHz TI Sitara AM3359), расширяемость доп. платами.

 

Что думаете?

[DmitryM 0]

Если уж до конца заморочиться, то стоит рассмотреть Raspberry Pi vs BeagleBoneBlack.

 

В Raspberry Pi мне нравится стандартный HDMI, 3.5mm audio in/out, видеопроцессор поддерживающий 1080р и просто огромное количесто учебных материалов и горовых проектов.

 

BeagleBoneBlack - проц новее (1GHz TI Sitara AM3359), расширяемость доп. платами.

 

Что думаете?

 

RPi тоже платы расширения есть, но imho, BBB. Учебных материалов тоже не мало, широкая номенклатура пинов выведена на гребенки и главная ценность, с моей точки зрения - полностью открытые доки, в том числе на процессор, чего не скажешь о RPi.

[usercod 0]

Ну не знаю, Raspberry Pi 2 очень крут.

[jcxz 184]

2) Если не достаточно функций библиотеки DSPLIB для DSP ядра С674x и требуется создать что-то своё, надо погружаться в дебри архитектуры С674x. Код с плавающей запятой на "С" (без оптимизации под архитектуру С674x) работает на DSP ядре медленее чем на Cortex-A8 при одинаковых тактовых частотах (запускал неоптимизированное под архитектуру быстрое преобразование Хартли на С674x и на iMX535 на частоте 300МГц: DSP: 30мс, A8: 8мс. Хотя по мегафлопсам С674x в 6 раз круче).

Имхо - некорректное утверждение.

Что значит "без оптимизации под архитектуру С674x"? В опциях компилятора выключена оптимизация? Тогда любой компилятор сгенерит очень медленный код.

Я переписывал самостоятельно на си некоторые функции из DSPLIB (с некоторыми модификациями) используя оптимизацию по скорости, используя intrinsinc-функции, restrict-указатели

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

При этом я очень туманно представляю себе архитектуру C674x поэтому не мог оптимизировать "под неё" (хотя плотно работал с архитектурой C55xx, оптимизировал под неё на асме,

поэтому примерно представляю общие принципы оптимизации для DSP).

У меня даже сложилось впечатление, что и сам DSPLIB был написан на си, а потом скомпилён ;)