LPC3130/31 Опции

[Step_ARM]

В поиске по форуму ничего не нашел по ARM9 LPC3130/31. Камень вроде привлекателен и ценой и возможностями, а не встречается в обсуждении.
Прошу поделиться впечатлениями тех , кто сталкивался с этим чудом :-)

[abcdefg]

В поиске по форуму ничего не нашел по ARM9 LPC3130/31. Камень вроде привлекателен и ценой и возможностями, а не встречается в обсуждении.
Прошу поделиться впечатлениями тех , кто сталкивался с этим чудом :-)

А чего в нем интересного кроме цены? Развитие концепции 2880, аудиоплеера и другие батарейчные приложения...

[shahr]

Процессор активно закладывается в массовые разработки. Для единичных изделий, естественно, вариант не самый подходящий.

[Step_ARM]

А чего в нем интересного кроме цены? Развитие концепции 2880, аудиоплеера и другие батарейчные приложенения...

Странный ответ :-) Так можно сказать , что и другие камни Вам не интересны. При чем тут батарейные или не батарейные приложения?
Наличие практически всей обычной периферии.
Высокая частота.
Загрузка с внешних носителей.
При этом такая низкая цена.

[alexQ]

может что то путаю но 2880 это был ARM7 ...

а LPC3130 это ARM9, причем достаточно навороченный и очень дешевый.

[etoja]

На него портирован линукс и этот проект можно скачать с сайта NXP.

[abcdefg]

Странный ответ :-) Так можно сказать , что и другие камни Вам не интересны. При чем тут батарейные или не батарейные приложения?

При этом такая низкая цена.

Его цена - это единственное достоинство. В остальном - урезанный LPC3220.
Насчет производительности - интерфейс SDRAM 16-битный и еще расшаренный с NAND. В какой степени это влияет на общую производительность - неизвестно.

Многие знания - многие беды...

[GetSmart]

Сравнивал как-то LPC31xx и LPC32xx и мне показалось, что 32хх уделывает 31хх во всём, в том числе у 31хх шаг BGA просто неприличный - 0.5 мм из-за чего проводники и зазоры требуются 80 мкм.

[Step_ARM]

Его цена - это единственное достоинство. В остальном - урезанный LPC3220.
Насчет производительности - интерфейс SDRAM 16-битный и еще расшаренный с NAND. В какой степени это влияет на общую производительность - неизвестно.

Многие знания - многие беды...

Ну почему же неизвестно. Кто-то же делает на нем?
Камень заточен под выполнение в кода в ОЗУ и соответственно в довольно приличных по объему приложениях не сильно-то важно какой там интерфейс с SDRAM или NAND. И уж совсем необязательно приделывать к нему операционку.

Мне допустим SDRAM & NAND не нужны. Я бы прикрутил датафлэш и SD и грузил с них.
Мне постоянно не хватает объема флэш. А тут любой практически неограниченный источник при минимальных затратах на комплектуху.
Supports booting from SPI flash, NAND flash, SD/SDHC/MMC cards, UART, and USB (DFU class) interfaces.

Насчет BGA это уже дело третье -- даже хорошо.

Насколько я понял , главное отличие 31 от 32 -- это отсутствие сопроцессора.
3130 стоит около 2.1евро(1000шт)
3131 -- 2.8 евро(1000шт).
Это просто неприличная цена.
И никто не говорил, что 3220 отметается -- тоже не особо дорогой видимо.
Каждый камень для своих задач.
Вот не хватает мне по скорости LPC2364/68 -- беру камень пошустрее раза в 2-3 и дешевле в два раза.

[shahr]

у 31хх шаг BGA просто неприличный - 0.5 мм из-за чего проводники и зазоры требуются 80 мкм.

это в 3180 только шаг 0,5. В других шире
LPC3180 был пристрелочный камень для запуска всей линейки.

[abcdefg]

Камень заточен под выполнение в кода в ОЗУ и соответственно в довольно приличных по объему приложениях не сильно-то важно какой там интерфейс с SDRAM или NAND.

Как это неважно?
Если у вас код расположен в SDRAM, то чем хуже организован интерфейс памяти, тем медленее выполняется программа.

Мне допустим SDRAM & NAND не нужны. Я бы прикрутил датафлэш и SD и грузил с них.
Мне постоянно не хватает объема флэш. А тут любой практически неограниченный источник при минимальных затратах на комплектуху.
Supports booting from SPI flash, NAND flash, SD/SDHC/MMC cards, UART, and USB (DFU class) interfaces.

Обычно бут с произвольных носителей делается следующим образом: камень грузит код весьма ограниченной длины (2-8 кбайта), потом делает Jump на этот код в ОЗУ (внутренний SRAM), который должен самостоятельно догрузить отставшийся код.
Хватит ли вам внутренних 96/192 кб для всего кода?

Насчет BGA это уже дело третье -- даже хорошо.

Стоимость ПП x 2 раза для мелких объемов.

Кстати, шаг там 0.8, 4х-слойки должно хватить

Вот не хватает мне по скорости LPC2364/68 -- беру камень пошустрее раза в 2-3 и дешевле в два раза.

Не хватает именно скорости вычислений или обмена с периферией?

[Step_ARM]

//Как это неважно?
//Если у вас код расположен в SDRAM, то чем хуже организован интерфейс памяти, тем медленее выполняется программа.
А зачем код располагать в SDRAM??? Да и настолько ли уж важно небольшое снижение скорости в ряде случаев???


// Обычно бут с произвольных носителей делается следующим образом: камень грузит код весьма ограниченной длины (2-8 кбайта), потом делает
//Jump на этот код в ОЗУ (внутренний SRAM), который должен самостоятельно догрузить отставшийся код.
//Хватит ли вам внутренних 96/192 кб для всего кода?
192кБ. Куда больше-то? Не компьютеры же делать.


//Стоимость ПП x 2 раза для мелких объемов.
1,3 в 1000 шт.
//Кстати, шаг там 0.8, 4х-слойки должно хватить
Нормально.


//Не хватает именно скорости вычислений или обмена с периферией?
Именно скорости вычислений.

[etoja]

Мне допустим SDRAM & NAND не нужны. Я бы прикрутил датафлэш и SD и грузил с них.

Есть на эту тему интересный проект:
http://www.ulrichradig.de/home/index.php/arm/arm_webbox

Но в нём отсутствует информация о том, как создать образ линукса на карточке SD.

[abcdefg]

//Хватит ли вам внутренних 96/192 кб для всего кода?
192кБ. Куда больше-то? Не компьютеры же делать.

//Не хватает именно скорости вычислений или обмена с периферией?
Именно скорости вычислений.

чего за приложение то такое?

[Step_ARM]

чего за приложение то такое?

Такое ощущение , что Вы делаете устройства которые всегда оснащаете внешним ОЗУ и флэш.
У меня основной процессор ЛПС2364. У него 8+8+16кБ оперативки и 128кБ флэш. Чем не замена?
Мне много-то не надо...

[abcdefg]

Такое ощущение , что Вы делаете устройства которые всегда оснащаете внешним ОЗУ и флэш.
У меня основной процессор ЛПС2364. У него 8+8+16кБ оперативки и 128кБ флэш. Чем не замена?
Мне много-то не надо...

Вы можете ответить на вопрос по существу - что за приложение, которому не хватает быстродействия LPC2364 и код у него укладывается в 128 кб ?

[etoja]

Управление ультразвуковой установкой, например.

[Step_ARM]

Вы можете ответить на вопрос по существу - что за приложение, которому не хватает быстродействия LPC2364 и код у него укладывается в 128 кб ?

Ну, например:-), видеорегистратор 320х240 15fps помещается и в гораздо меньший объем. 2364 по скорости не потянет, ну никак, а вот 3131 уже вполне... Это только пример.

[dmitry-rf]

У меня лежит отладка от Embedded Arstists. Поиграться, правда, ещё не успел. Основное достоинство этого камня, на мой взгляд, это возможность запуска стандартной Java-машины. Программистов на яве много, можно написать что угодно не вникая в низкий уровень.

[Step_ARM]

У меня лежит отладка от Embedded Arstists. Поиграться, правда, ещё не успел. Основное достоинство этого камня, на мой взгляд, это возможность запуска стандартной Java-машины. Программистов на яве много, можно написать что угодно не вникая в низкий уровень.

А прикрутить эту машину пробовали?

[dmitry-rf]

А прикрутить эту машину пробовали?

На этом проце еще нет. Запускал на AT91SAM9260 и LPC3250.
Вот тут результаты тестов: http://rwxr-xr-x.blogspot.com/search/label/java

[etoja]

Если на плате работает линукс, то тормоза в виде ява-машины уже ни к чему.

[dmitry-rf]

Если на плате работает линукс, то тормоза в виде ява-машины уже ни к чему.

Зависит от задачи

[etoja]

не зависит.

[Denis8]

согласен, что зависит от задачи.
Не стоит путать Linux, все же это операционная система а не язык прогр.,
Java это язык прогр. и достаточно навороченный, кое в чем развитее C++, недаром микрософт С# занялся.
Если сравнивать коректно, то наверное Linux+С и Linux+Java.
На ARM процессорах Linux+Java будут проигрывать по производительности из-за апаратной архитектуры ARMов.
По этому ява там выглядет тормозом. Есть попытки апаратных real-time Java процессоров таких как "ajile" и ему подобные.
А вот web сервера, ... IP технологии написанные на яве во встроенных приложениях предпочтительнее.

[abcdefg]

На этом проце еще нет. Запускал на AT91SAM9260 и LPC3250.
Вот тут результаты тестов: http://rwxr-xr-x.blogspot.com/search/label/java

"Как видно, SAM9260 немного уступает LPC3250, что логично, так как у последнего частота немного выше. А вот разрыв между АРМами и настольным компьютером просто поражает! Аппаратный FPU - это сила"

Странный тест, т.к. в LPC3250 как раз есть VFP

[etoja]

и неясно как ява-машине помогает аппаратная реализация плавающей точки.

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

[dmitry-rf]

Странный тест, т.к. в LPC3250 как раз есть VFP

Угу. Я этого не написал, но подумал, что, возможно, VFP не был задействован по каким-то причинам. Разбираться было некогда.

и неясно как ява-машине помогает аппаратная реализация плавающей точки.

Помогает не ява-машине, а тесту. Если прочитать его описание, можно увидеть следующее:

Код

reports a composite score in approximate Mflops (Millions of floating point operations per second)

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

Что достигается за счёт огромных размеров и энергопотребления

[Rst7]

Ну, например:-), видеорегистратор 320х240 15fps помещается и в гораздо меньший объем. 2364 по скорости не потянет, ну никак, а вот 3131 уже вполне... Это только пример.

Ну если Ч/Б с десятикратной компрессией, то LPC23xx примерно так и потянет - 320*240*15.

[AlexandrY]

Вы б лучше рассказали где взяли эту JVM, какая версия, какая платформа (J2EE, J2SE, J2ME?). Сколько памяти она заняла, какая файловая системы была. Чем компилировали. ARM или THUMB был режим и т.д. Была ли поддержка jazelle

Я думаю показатели JVM на ARM-ах можно значительно улучшить, в 4-6 раз.
Поставить нормальную JVM.
Надо провести тюнинг быстродействия шины внешней памяти.
Профилировать, перекомпилировать в RealView критичные системные участки и т.д.

Угу. Я этого не написал, но подумал, что, возможно, VFP не был задействован по каким-то причинам. Разбираться было некогда.

[Step_ARM]

Ну если Ч/Б с десятикратной компрессией, то LPC23xx примерно так и потянет - 320*240*15.

Помнится мы с Вами это уже обсуждали. Как раз LPC3131 нормально должен потянуть 320х240х(10-15) в цвете.
Это же быстрый, достаточно навороченный и дешевый камень. Рассматривался вопрос о применении его в простых устройствах.
А тут все сразу полезли в дебри -- операционки , явы...
Интересна так же, мотивация использования операционки. Почему тот или иной разработчик ее использует?

[Rst7]

Помнится мы с Вами это уже обсуждали.

Ах это мы с Вами обсуждали... Точно-точно... Забыл уже

[dmitry-rf]

Вы б лучше рассказали где взяли эту JVM, какая версия, какая платформа (J2EE, J2SE, J2ME?). Сколько памяти она заняла, какая файловая системы была. Чем компилировали. ARM или THUMB был режим и т.д. Была ли поддержка jazelle

Брал здесь: http://java.sun.com/javase/downloads/embedded.jsp
Java SE for Embedded 1.4.2
Если я правильно помню, то у меня OABI, glibc2.3.3, Soft Float, что и даёт низкую производительность. Надо EABI, glibc2.4, Hard Float (VFP) попробовать. Файловая система - NFS, всё остальное за меня Sun сделал.

[AlexandrY]

Мда, ресурсы эта ява требует дикие. 32 метра только для голого JVM без графики и клавы и не включая приложения. А с поддержкой дисплея так все 64 метра. Поддержка WEB технологий еще требует отдельного пакета. И при этом они еще специально урезали ресурсы памяти требуемые для нормальной явы.
Смысл применения дешевых LPC здесь полностью исчезает.
Здесь начинает доминировать цена памяти и интерфейсные контроллеры.

Хотя либы у этой явы очень мощные, но сильно избыточные для embedded, как например работа с офисными документами, печать, многоязычность, движки для распределенного корпоративного управления и т.д.
ИМХО, сильно архаично и бестолково. Фреймворк идущий с WinCE 6.0 гораздо приятней и целенаправленней. Да и C# пожалуй пошустрей будет выполняться

Брал здесь: http://java.sun.com/javase/downloads/embedded.jsp
Java SE for Embedded 1.4.2
Если я правильно помню, то у меня OABI, glibc2.3.3, Soft Float, что и даёт низкую производительность. Надо EABI, glibc2.4, Hard Float (VFP) попробовать. Файловая система - NFS, всё остальное за меня Sun сделал.

[Step_ARM]

Ах это мы с Вами обсуждали... Точно-точно... Забыл уже

Как коротка память разработчика... :-)

[alexQ]

Мда, ресурсы эта ява требует дикие. 32 метра только для голого JVM без графики и клавы и не включая приложения. А с поддержкой дисплея так все 64 метра. Поддержка WEB технологий еще требует отдельного пакета. И при этом они еще специально урезали ресурсы памяти требуемые для нормальной явы.
Смысл применения дешевых LPC здесь полностью исчезает.
Здесь начинает доминировать цена памяти и интерфейсные контроллеры.

Хотя либы у этой явы очень мощные, но сильно избыточные для embedded, как например работа с офисными документами, печать, многоязычность, движки для распределенного корпоративного управления и т.д.
ИМХО, сильно архаично и бестолково. Фреймворк идущий с WinCE 6.0 гораздо приятней и целенаправленней. Да и C# пожалуй пошустрей будет выполняться

2AlexandrY

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

у меня джава хорошо крутится с графикой на 7-м арме, а уж про 9-й и разговора нет.
и ресурсов требует чтото около 20к оперативки и 200к флэша.

Кстати если у кого есть EA-LPC2478, могу закинуть бинарник с джава-демо, чтобы разговоры были непустыми.

[AlexandrY]

C J2ME который вы имеете в виду я знаком довольно давно.
Вам бы следовало уточнить название платформы если вы хотите сказать что-то ценное.
А речь зашла о J2SE. Это небо и земля.

Ну чем может похвастаться там ваша графика в J2ME? Кружок нарисовать может, или там линию
Так я GUI с нормальными оконными контролами имею в виду, а не графические примитивы.

Для J2ME в малых ARM-ах есть много достойных скриптовых конкурентов, те же Phyton, LUA, PAWN и т.д.
Но это только вспомогательные инструменты.
Целиком апликацию на них не сделать без мощного промежуточного middleware написанного на С-и

2AlexandrY

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

у меня джава хорошо крутится с графикой на 7-м арме, а уж про 9-й и разговора нет.
и ресурсов требует чтото около 20к оперативки и 200к флэша.

Кстати если у кого есть EA-LPC2478, могу закинуть бинарник с джава-демо, чтобы разговоры были непустыми.

[dmitry-rf]

Хотя либы у этой явы очень мощные, но сильно избыточные для embedded, как например работа с офисными документами, печать, многоязычность, движки для распределенного корпоративного управления и т.д.

Надо же.. Не знал, что там всё настолько серьёзно.
JavaSE я выбрал потому, что там хоть понятно, что скачивать. А для JavaME есть куча невнятных пакетов. Сам я с Java практически не знаком. Сказали запустить - запустил...