День добрый.

Хочу сделать MFD для дельты... Интересует какой из ARM'ов потянет примерно такую графику (см. рис.)? Картинка предполагается 640х480, 256 bpp.

Пока склоняюсь к AT91RM9200 потому как имел дело с AVR до этого, а у Atmel'a это один из самых мощных ARM'ов, как я понял (по крайней мере если судить по частоте)... Но опыта общения у меня с ними не было, по этому оценить "тяжелость" графики для него мне сложно.

Вопросы:

1. Потянет ли?
2. Сколько ресурсов (ну хотя бы +/- километр, чтобы хотя бы представлять) у него это может отъесть?
2. Насколько может облегчить его участь LCD драйвер от Epson... S1D13506 или аналогичный со встроенным ускорителем 2d графики?

Спасибо!

Производительность 9200 примерно такая-же как и у пня с соответствующей частотой. Под Линухом он показывает 89 богомипсов, ровно столько сколько 200тый пень. Я думаю, если там не будет большого количества расчетов с плавающей запятой, то сравится запросто...

1. Кто такие богомипсы?
2. И еще, этот самый 2D акселератор в LCD контроллере намного жизнь процу облегчает?

Если с распайкой BGA проблем нет, возмите EP9315, там есть Graph Engine и мат-сопроцессор, облегчит жизнь.

Если нужно отображать большое количество векторной графики (а в Вашем случае это, похоже,
так), то облегчает, но чудес ждать не стоит. Посмотрите еще EP9307 и EP9315 от Cirrus Logic - там
ускоритель и контроллер на борту.

мини ховто
http://ruslandh.narod.ru/howto_ru/mini/BogoMips/index.html
акселератор сильно облегчает примерно три вещи:
1. отображение шрифтов
2. массивные скроллинги изображения(т. е.) когда надо все или часть изображения скроллировать по экрану
3. сильно упрощает операции с графическими примитивами типа BitBlt (логические операции с группами пикселей)

Личный опыт:
* AT91RM9200
* uCOS
* uCOS GUI
* 320 x 240 экран, 8bit/pixel
* Epson LCD контроллер простой, со встроенной памятью.

Была программа генерации ландшафтов. 2..5 fps выдавала.

Проверить очень просто

* Пишете Вашу графику, в иделае как palin C без особой зависимости от ОС.
* Работает она с виртуальным frame buffer, который никуда не выводится
* Покупаете отладочную плату, например
http://electronix.ru/forum/index.php?showt...iew=getlastpost
* проверяете время отрисовки.

От себя замечу следующее. Если будете по тупому рисовать, весь экран перерисовывать - тут Вам пЫсюк нужен. Если продумаете алгоритмику перерисовки (у Вас там немного рисовать-то надо!) - почти навернякак хватит.

Лучше всего, конечно, взять готовый ARM со встроенным контроллером LCD (ну или не ARM, а MIPS от AMD - Au1100, Au1200). Варинты:

* Cirrus logic Вам уже назвали
* Sharp LH7A400, LH7A404
* Intel PXA255, 270
* Samsung
* много еще кто.

В общем, Вы сначала напишите Вашу графику на С, отладьте ее под виндами
http://electronix.ru/forum/index.php?showtopic=12186 - на том же FTLK
http://www.fltk.org/index.php

http://electronix.ru/forum/index.php?showtopic=11623
http://electronix.ru/forum/index.php?showtopic=11570
а потом "бенчмарките" ее на чем попало.
И будет Вам счастье

Спасибо за развернутый ответ!
Пара вопросов:



Можно чуть подробнее об этом?

Все просто.

1. Делаете в памяти массив. В нем байты и биты лежат так, как будто контроллер считывает их подряд и засовывает в LCD (изучите интерфейс LCD).

2. Делаете прогу - визуализатор, которая отображает этот виртуальный экран на нормальный. Пусть она визуализирует медленно - она нужна для контроля правильности, а не скорости. Тут проще всего взять FLTK.

3. Пишите Вашу софтину, которая работает с массивом, рисует на нем.

4. Прогой проверяете, что Вы там нарисовали.

5. Замеряете время отрисовки.

6. То же самое на разных платформах. Посему проще всего писать сразу под GCC.

7. Выберите ОСь, под которой будет работать Ваша железяка. Например, если решите ставить Линух, то можете сразу начинать писать под FLTK. (на 100% я не уверен, но по идее, если использовать описанный ниже mingw, то код будет иметь небольшую правку при переносе Win->Lin)
http://electronix.ru/forum/index.php?showtopic=12186
Ибо она портирована на очень простой X-сервер Nano-X
http://www.microwindows.org/
А эти Nano-X живут на очень многих аппаратных платформах.

Евгений, большое спасибо!

1. BGA еще не паял сам Родной evluation board на цирусе стоит дорого, так что придется как-то "на коленке"... и BGA, откровенно, пугает.
2. Цена цируса по сравнению с 9200-м раза в 2 больше... оправдана ли эта разница в цене ростом производительности?
3. Как у цируса с доставабельностью в Питере? Если решусь то нужно будет пара штук "на попробовать" Вы сами работали с ним?

По железу пока все Вернемся к софту.

Пока думаю о линухе.
Могли бы Вы чуть подробнее рассказать о связке FLTK и Nano-X?
Правильно ли я понял, что:
1. FLTK это граф. библиотека. Я должен использовать ее чтобы написать свою графику.
2. Nano-Х... хм, это сервер оконных приложений, надо понимать... Т.е. я должен буду написать нечно вроде "визуализатора" моего "виртуального буфера" c использованием библиотек Nano-X. И в эту программу я должен подцепить код своей "рисовалки". Правильно понял?

А зачем так сложно? Мне ведь, по сути, не нужны будут всякие окошки да кнопочки... Потому как мышка или touchscreen вряд ли в этом девайсе нужны будут Можно как-нить "чтоб попроще и чтоб побыстрее работало"? )

Может быть порекомендуете какие e-book'и по программированию embedded графики? (да и просто по программированию для ARM'ов)

Спасибо!

глянь тут *http://arm.cirrus.com

Да был я там... дохлый форум - вопросов больше чем ответов. :/ В общем, этот цирус навивает какие-то грусные мысли :/

FLTK работает и под линухом, и под виндами. При переходе с одного на другое, насколько я понимаю, код надо править незначительно.

Если User Interface не нужен, то можно просто рисовать "картинки в памяти", а затем отображать их на экран для контроля.

Тогда можно и с линухом не заморачиваться. Поставить uCOS и работать в свое удовольствие.

По Cirrus - есть более дешевые платы

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

Там есть под всякие Cirrus'ы.

Спасибо за терпение и выдержку ) Я, конечно, глупые вопросы задаю, но нужно же с чего-то начинать

1. А ежели все-таки заморочиться с Линухом, то как будет выглядить готовое приложение?
Допустим у меня есть plain-C который рисует в буфер то что мне нужно... Как это подоткнуть в Линух? Интегрируется ли это прямо а ядро линуха... и оно передает моему приложению управление в какой-то момент... или как? Хотя бы "на пальцах", чтоб дальше знать по каким ключевым словам "в поиск"
2. Если производитель дает свои библки для работы с 2D-акселератором (как Epson, например), то по идее я должен юзать их взамен/параллельно с FLTK?

А ядро то тут причем? Есть user application, ктоторое пользуется frame buffer "в лоб". Сосем точно не отвечу, но выглядеть это должно где-то так

Тут Вам чтива надолго хватит...
http://jungla.dit.upm.es/~jmseyas/linux/ke...ckers-docs.html
По идее да, но я такие либы не юзал.

А... т.е. все-таки "мухи отдельно, котлеты отдельно"? Т.е. есть линух... есть мое приложение... И при запуске линуха он просто автоматом запускает мою прогу? Так, нужно понимать?

Спасибо... сейчас прогуляюсь по линку...

Где-то так
В общем, становитесь своим, и пылесосьте ftp по теме.
А пока купите хорошую книжку по Линуху и почитайте. Да поставьте Линух под VmWare или Colinux у себя на пЫсюке.

Спасибо всем Более ли менее понятно куда копать дальше...
Похоже нужно начать с графики а не с железа...

Мне тоже далеко не сразу стало понятно, что начинать надо сверху, а не снизу Почитайте
http://www.caxapa.ru/echo/arm.html?id=49785
http://electronix.ru/forum/index.php?showtopic=11623
http://electronix.ru/forum/index.php?showtopic=11570
http://electronix.ru/forum/index.php?showtopic=12180

Просмотрел по-диагонали доки по Nano-X и FLTK...

Возможно кому-то поможут мои размышления, чтобы понять откуда ноги ростут Для упрощения понимания все разбил на пункты

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

В принципе в таком виде (в виде ядра) линух уже способен "жить" в нашей железяке... Но нам это не интересно... нам подавай свою програмулину... да еще желательно с графикой в цвете и с окошками... Писать все с нуля и глупо и долго... По этому смотрим по ссылкам выше и начинаем разбираться в...

2. Nano-X - это аналог X-system для Linux. "X"-ы же являются как-бы графической надстройкой для линуха и предоставляют программисту API для написания оконных приложений. Nano-X это сильно облегченный аналог X-ов, способный работать на различных embedded девайсах. Кроме этого, Nano-x берет на себя заботу "общения с железом", программист имеет возможность "писать окошки" меньше заботясь о том, как его труды будут отображаться на железе.

В принципе, связки "Ядро линуха"+"Nano-X" уже достаточно чтобы писать что-то "этакое" Но программисты - люди ленивые (ну хорошо.. не все...). Они решили упростить себе использование Nano-X и написали...

3. FLTK - это тулкит для написания оконных приложений и работы с графикой. Предназначен для работы с Х-ами линуха. Он использует API Nano-x (или другой "реинкарнации" Х-ов) но в то же время предоставляет программисту свой, более удобный API, снабженный, к тому же, многими другими удобными фичами. Как результат имеем, что, например, программа Hello World состоящая из одного окна с кнопкой и написанная с использованием FLTK занимает всего 8 строчек кода Чудо да и только!

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

Единственное, что пока непонятно, так это:
1. Приложение даже под embedded линух живет само по себе... После развертывания ядра его кто-то должен запустить...Как это делается?
2. Обычный линух после старта ядра ненавязчего предлогает залогиниться... естественно это ненужно на embedded устройстве... как это убирается?

Это все частные вопросы, конечно,и на данном этапе они для меня не сильно важны, но, что называется, "свербит" и хочется узнать ) Может кто подскажет?

Пропылесосьте тут. Там есть и по embedded Linux.
http://www.ebookcn.net/search.php?key=linu...=25&submit.y=10

Ну чего-то я не до конца понимаю, но употребление линукса здесь явно не по месту. Готовых графических библиотек для изображения такого рода графики под Хсами нет. Придется либо писать самому, либо портировать из чего нибудь явно с Хсами ничего общего не имеющего. Минимальный обьем памяти ОЗУ необходимого для старта Уцлинукса 4мб просто Линукса 8Мб с большим треском, если добавлять Хсовость 16мб, чтобы там не говорили, не говоря о постоянной памяти не менее 16-32мб. Траффик входной выходной-мизерный не превышает 38400 бит спокойно обработается ручками. Я думаю что для обработки фрейм-буфера 640х480 с двойным буферизированием вполне хватит 2мб ОЗУ. Можно найти туеву хучу ДОСовских графических библиотек по отрисовке графики(можно взять даже Борландовскую BGI)там есть и шкальная графика и портировать ее на рм9200 и все это спокойно влезет в 2мб ПЗУ. Не говоря о том менингите, который сопровождает запуск самого Линуха...

Можно и uC GUI взять (на ftp лежит ). Да, в малую память влезет хорошо. Но отлаживать сложнее. Память нынче дешева!

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

Спасибо!