Есть проблемка. Выбора. Очень хочеться FPU на борту ма-ахонькой платки иметь. А я только только с ARM-ом 7 как следует разобрался.
Господа ARM-сты! Кто работал со старшими ARMами ( которые с FPU)?
Умучался искать. Нашёл только два кристалла у Cirrus Logic: PS7500FE64QC и EP9312-CB. Всякие дилервы и бред менеджеры предлагают перескочить на Хитачи SH7751R. Дескать и RISK и FPU и линух задаром http://www.shlinux.com/products/systemh.htm
А по ARMам тишина. Никто не торгует, что ли?
Может кто и с хитачами возился?
Поможите

Извините, но по-моему требование "нужно иметь на ботрту махонькой платы FPU" слишком абстрактно. Почему бы не взять какой-то DSP с FP? Почему именно SHxxx или EP93xx? Или x86? Почему вообще именно ARM?
И причем тут RISC или Linux?

Я бы на Вашем месте подумал и попробовал сформулировать - что Вам действительно нужно? А здешние обязательно помогут в выборе.
Не сомневайтесь.

Так ведь еще проблема, чем прорамить будете.
Компиляторы не ноддерживают FPU.
У нас плата как раз под EP9312.
Копилятора который поддерживает FPU не нашли.
Хорошо хоть нам FPU и не нужен.

Это будет устройство вроде разжиревшего палма. ЖКИ 640х480 ч/б или цветной, звук, тачскрин, клава по требованию. Три-четыре СОМ-порта, сеть одна или две. Из носителй - CF метров на 256.
Вообщем, замена промпц.
Раз сеть и диски - то и операционка.
Linux, ввиду отсутствия альтернатив .
FPU нужно для расчётов - регулирование всякое в реальном времени. ПИДы с плавующей точкой. Сейчас эмулируем ПТ программно, получаеться один LPC на 60Мгц тянет до четырёх ПИДов. Но это на локальном уровне. На верхнем уровне и ПИДы посложнее и больше других задач.
Почему ARM - привык, наверное. Но и другое мне не противно.

А если не нужен FPU - тогда почему EP9312???

Нужен контроллер TFT экрана и Ethernet.
Но все же интересно, чем компилируют команды для FPU

Я надеюсь что GCC понимает FPU. Хоть ARM, хоть SH-4. Так, как у производителей в качестве инструмента программированиея GCC есть обязательно. Могу конечно и ошибаться.

gcc совершенно точно не понимает FPU процессоров от CirrusLogic. Они используют свой собственный сопроцессор (кстати - весьма неплохой)
MaverickCrunch. Он совершенно не похож на VFP от ARM. Поэтому всю плавучку в этом случае придется писать руками. Хотя я думаю, что на C++
все может получиться достаточно изящно при помощи переопределений.
Весьма неплохой imho вариант для этого случая - OMAP5912 от TI.
С одной стороны - нормальный ARM, с другой - очень приличный DSP 55xx.
И периферия ну прямо вся, которая нужна. И все в одном флаконе. На ARM запустить Linux, а DSP использовать, как весьма серьезный сопроцессор.
И на нем эмулировать плавучку. Может выйти очень даже неплохо.

Я работал с Hitachi SH-4, могу ответить на любые вопросы связанные с ним.
Дело в том, что sh-4 установлен в игровой консоли SEGA DreamCast,
писал под эту консольку игрушки и служебный софт (реассемблер; скриптовый компилятор похий на ассемблер, но с операторами высого уровня - выдающий на выходе машинный код для superH).

По поводу компиляторов GCC: посмотри секцию "инструментарий" на www.boob.co.uk или www.dcemulation.com, есть версии под Linux и Win32(через cygwin). Тамже можно скачать (в сырцах) Linux под SH-4.

Оооо Это я удачно зашел. Как всё-таки дела с плавующей точкой?
И можно ли использовать Dreamcast как борду для разработки? Что бы оценить сам процессор и освоить средства разработки.
Или там всё очень специфическое?

Да, блин, точно не понимает. Наши программеры порежут меня на кусочки И так говорят, что я сексуальный маньяк - затрахал их новыми процессорами. А тут ещё и цитрусовый DSP осваивать.

Уже пробовал - затык на DSP. Некому им заниматься. Мы остановились на 2191 и забросили эти дела с появлением ARMов.
Остаёться один PS7500. Но он старый и не рекомендован для новых разработок.
Может есть в природе ARM с VFP?

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

Мне не встречался ни один ARM с VFP.
А в чем затык с DSP? В данном случае пожалуй можно писать софт для него на C. а потом, глядишь и потихоньку асемблерные п/п пойдут, разве нет?

Может быть стоит посмотреть на PowerPC? Хороший быстрый RISC, есть плавающая запятая. Но чтобы при этом был контроллер TFT и жирная периферия (кроме коммуникационной) - это вряд ли.

Плохо смотрели. В ADS есть выбор FPU и не одного.



Искать надо не у производителей ширпотреба а у специализированных фирм.
Допустим netX на базе ARM926 все идут с VFP9.

http://www.edn.com/article/CA438294.html

Списки выпускаемых процов. Очень познавательно!!!

Теперь по поводу обсужаемой темы.

С точки зрения моего опыта, не факт, что стоит все вгромоздить на один проц. Пусть он и будет быстрым, но сложность программ, и сложность корректного переключения между задачами могут все угробить. Представте, одна ошибка, и все ваши N пидов полягут. Например, ошибка в ГУЕ (а нафига TFT без красивого гуя? А реалтаймвость гуя - это вещь в себе. Либо ГУЙ будет подтормаживать (если фоновая нагрузка большая), либо пиды полягут.). Кто за это будет платить?

Я бы (IMHO) сделал распределенную систему. Пусть себе LPC пидят, а центральный проц, с достаточным запасом по переключению между процессами, "дрочит" их. С одно стороны, вроде бы как сложнее. Но с другой, гораздо надежнее. Контура обратной связи будут замыкаться внутри одного проца, с делать протокол на основе CAN (IMHO) не так уж и сложно, благо он для этого и заточен. А центральный проц неспеша будет рисовать неземную красоту на TFT.

Опять же, расширяемость такой системы почти безгранична.

Хочу уложиться в 200-250 уе вместе с ч/б ЖКИ. Начет продажи пока не думал - слишком рано.

Система распределённая. Сейчас на месте такой платы - промперсоналка или даже обычная персоналка. Это не всегда удобно. А ПИДы, которые на ней крутяться - регулировки регулировок и настройки настроек локальных ПИДов. Много, много локальных ПИДов. Кроме того, связь с вышестояшей сетью. Кроме того, пульт оперативного контроля и отладки.


Я вижу - мы единомышленники?

Насчет ПЦ - полностью согласен!!! Не место им в промавтоматике, сколько бы их делатели не убеждаи в обратном!

Тогда задача понятна, и, похоже, имеет смысл делать FP. Насколько я понял, от "нереального" времени вторичных ПИДов то, чем управляют меленькие ПИДы, сразу не взорвется.

А то я уж испугался .

И все таки, еще раз призвал бы к модульной структуре. Есть чудная вещь - AD DSP BlackFin. Он хоть и не FP, но имеет переменную разрядность операндов- могут быть и 16, и 32 битным. Очень шустрый, суперскалярный. Хорошо поддержат со стороны AD. Есть куча библиотек, в том числе и FP. Цены - 20$ или около того.

Самое главное, у него есть неплохие средства для межпроцессорного взаимодействия.

Поставить такое чудо в качестве внешнего сопроцессора, наладить обмен между ними по DMA - и радоваться жизни. Опять же, blackfin'ов много, последние имеют мощу до 3 GOPS.

А в качестве проца выбрал бы Sharp LH7A404 - чудный кристалл!

В ADS поддержки FPU для EP9312 нет.

Да, я ж и говорю - делали мы так. Или почти так. Но время программистов оказалось гораздо дороже. И поэтому я гораздо охотнее воспользоваться бы FPU + компилятор+программист, чем (Blackfin+програмист№1)=FPU+програмист№2. Увы. Столько чудных проектов погибло из-за нежелания программистов работать за так



Да. Согласен. Да не потянем. А с LH7A404 работали или как?

Пока еще нет. Только готовимся

http://forum.electronix.ru/index.php?showtopic=2377

программист+програмист=1.8программиста

Не, чаще надо не складывать, а перемножать. Тогда будет программист*програмист=0.81программист

Почему 0.81? 1.8 обычно объясняют "20% уходит на межпроцессорное взаимодействие", 0.81 можно наверное "- на пиво"

http://forum.electronix.ru/index.php?showtopic=2424

Возможно, это отвечает всем чаяниям автора данной темы

Мда. Заманчиво. Но и SH4 на его фоне неплох. Буду посмотреть. Сенькс.