Уважаемые, посоветуйте пожалуйста. Следуя моде, решил заняться освоением ARM. Нужно выбрать микроконтроллер, максимально удовлетворяющий следующим требованиям:
1. ARM7.
2. большое количество доступных библиотек, особенно касающихся интерфейсов (Ethernet и пр)
3. Распространённость
4. Возможность работать с TFT. Имеется в виду TFT "без контроллера". Нужно, чтобы процесс вывода информации не занимал слишком много ресурсов. Возможно, есть ARM с аппаратной поддержкой этого дела? Нет задачи выводить видео или какие-то часто меняющиеся картинки. Просто нужно рисовать красивое графическое меню пользователя, возможно, с графиками, и пр. Но при этом хочется чтобы ресурсов хватало еще и для прочих задач. Все относительно, конечно, но .....
5. Очень бы хотелось поиметь готовые графические библиотеки, наподобие библиотек графических примитивов Microchip. Это всякие линии, кружочки, кнопки, окна и прочее. Удобная штука. Только они для PIC24 - PIC32, а мне религия не позволяет....java script:emoticon(':maniac:',%20'smid_17')
Сам, после изучения форума и подобных ресурсов в сети смотрю в сторону LPC23xx или LPC24xx.
Что скажут люди опытные?
Спасибо.

1, 4. Сразу отсекаете кучу вариантов на ARM9. Почему?
Если остановитесь на ARM7, то имейте в виду, что больше 320x240x16bpp он не потянет, особенно без кэшей.

2, 5. Библиотек разных навалом для всех платформ. Но качественного бесплатного продукта не бывает практически никогда.

Тут наткнулся на платку на at91sam9263, разработанную одной немецкой фирмой специально для совместной работы с TFT 5,7 inch. Если интересно, могу попытаться найти тот журнал.

http://www.embedinfo.com/english/Product/SBC2440-IV.asp
не важно какой арм, сейчас девятые по цене седьмых, цена экранчика порой перевешивает стоимость платочки.

Со всем согласен, кроме разрешения. Потому как разрешение отдельно от быстродействия и функциональности рассматриваться не должно. Более того, у меня 800x480x16bpp на LPC2478, картинка из памяти в память копируется быстро. О видео и эффектах речи нет, конечно, но для встраиваемой аппаратуры это и не обязательно. Кроме того, можно использовать возможность переключения страниц, фоновую загрузку и проч.

Левая файловая система без DMA создаст больше тормозов при выводе готовых картинок.

Да я его так и рассматриваю вроде.


Очень быстро - это сколько в граммах? Сколько займет копирование всей области экрана, например?

Не засекал Более того отдали единственный образец заказчику, который вроде доволен.
Около 0,2 с по моим прикидкам. Нормально для переключения между состояними. А переключением страниц мультик гоняем.
А вот FS требует >6-7 c :-(

Ну вот. ИМХО, для нормальной работы такая операция должна занимать не более 17мс (время одного кадра).


А что такое FS?

Посмотрите на это решение: ТФТ-Компаньон. Может и АРМ осваивать не понадобится...

Просто у вас не остается ресурсов на что-либо еще, кроме регенерации изображения, поэтому все остальные операции создают тормоза.
Вот аппликуха по подключению TFT к LH79520. На стр. 24 приведены прикидки по количеству процессорного времени, которое останется на все остальные задачи в зависимости от разрешения/цветности. Уже при 640х480х16bpp остается только 19.9 МГц эффективной частоты. Это при CPU speed 75 MHz и AHB speed 50 MHz.

Для нормальной работы ЧЕГО? Вы все о видео думаете, а я о приборе с GUI. За прибором работает человек, он кнопку нажал и прибор перешел из одного режима(меню) в другой. И еще не факт, что 17 мс лучше, чем 200 мс.


Файловая система.



Признаюсь, цифрами не владею, мои прикидки несколько оптимистичнее - половина производительности на регенерацию.
Но все равно, в случае с файловой системой... допустим даже треть ресурсов остается процессору - исключив регенерацию, получим вместо 6 с - 2 с. Все равно не спасает (если говорить о 17 мс).

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

Да нет, я тоже о GUI. Представьте, что человек текст на экране прокручивает, дергая за движок scrollbar'а. 200мс лучше будет?


Просто Вы не уточнили, на что она требует >6-7c, поэтому получилось непонятно.

Да, что говорить, прокрутка полного текста исключается на корню. Разве что с помощью смещения указателя на начало страницы.
В приборе два ротор-энкодера, которыми производятся установки числовых значений. Если поле ввода составляет 1/20 площади экрана, получаем приблизительно 10 мс. Пойдет?

Пойдет Но в общем случае для такого экрана я бы не рекомендовал процессор ниже ARM9 200MHz с 100MHz 32-bit внешней шиной.

Большое спасибо за размышления.
ARM9 мне пока не нужен. Я так понимаю, будет нужен - перейти не так уж сложно. Очень слежу за бюджетом своих проектов, подчас нужна небольшая по размеру микросхема, обвес по минимуму, в задачах часто бывает нужно дергать ногами и т.д. Думаю, это скорее ARM7.
TFT упомянул в том смысле, что "это тоже скорее всего скоро понадобится", но это - не основное и не всегда. Речь может идти только о GUI, ни какого видео. Скорости обновления фрейма в 100 - 200 мс будет достаточно. Разрешение 320*240, больше не предвидется.
TFT компаньон..... интим не предлагать. В конце концов, есть TFT со встроенными контроллерами, хоть щас AVRкой управляй. Но не надо. Sharp-овскую апликуху поизучаю, интересно.

На кого из производителей смотреть? Про NXP правильно думаю?
Если есть где-то хранилище библиотек, ткните пожалуйста.

ИМХО, для Ваших целей правильно.

ага. поставил себе галочку
спасибо.

Про "это" Вам уже сказали - полностью солидарен с оценкой. Дальше того что на NXP выложено лучше вообще не ходить. Там, конечно, тоже отнюдь не подарок, но хоть и не полный мрак.

Ну мне пока ответили дословно: "Но качественного бесплатного продукта не бывает практически никогда", не более того. Про standartics.nxp знаю, спасибо.
Все же, неужели нет никаких библиотек для ARM (возможно LPC) для работы с TFT или даже для создания на TFT базовых графических решений??? Опять же, спрашиваю под впечатлением от увиденных на выставке бесплатных библиотек Microchip.

Подобных микрочиповской не встречал. А библиотека Microchip все же условно бесплатная, так как лицензия допускает использование только на их контроллерах.

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

Кстати, а плз ткните меня в подходящий ARM9 ( в разрезе того, что мы тут говорили). Я этот сегмент вообще не смотрел.

Да, еще одно соображение. На каком-то уровне сложности целесообразность собственной разработки контроллера отсутствует. Мы же не делаем для себя PC. Мне казалось, что эта граница и проходит между ARM7 и AMR9. Если это не так, то где же эта граница?

Atmel: AT91SAM9261, AT91SAM9263; NXP: LH7A40x; CirrusLogic: EP9307, EP9315.


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

Так. Ну по ходу обсуждения я понял что вопрос с готовыми графическими библиотеками можно закрывать. Если не Майкрочип, то рисую сам.
Что же касается интерфейса с TFT. Все же, кого из LPC выбрать? Я не очень разобрался по сайту NXP, бывает ли у них что-то вроде "аппаратной поддержки TFT". Т.е. чтобы не вручную прописывать интерфейс с дисплеем, а он каким-то образом "уже был". И еще, я правильно понимаю, что чтобы работать с TFT без контроллера, необходима внешняя SRAM? Там вроде как под мегабайт нужно???
Другие вопросы по выбору ARMа не задаю, т.к. сейчас у меня TFT все определяет. Все прочее, необходимое, у них всех есть.

LPC2470, LPC2478. Или из Sharp'овского наследия, но тогда без флеш.
Selection Guide


Лучше SDRAM.

спасибо, aaarrr

А какой-нибудь nanoX или uC/GUI чем не годятся?

uC/GUI не бесплатный, а вот nanoX может быть вполне нормальным вариантом, если его подправить напильником.

NXP LPC3250 ещё посмотрите. и отладочные комплекты от Phytec:
http://www.phytec.com/products/rdk/ARM-XSc...M9-LPC3250.html





это старый селекшн гайд. здесь новый:
http://www.standardics.nxp.com/literature/...f/line.card.pdf

Ничего об этом не знал. Буду разбираться, спасибо вам.



Ага, и мне "на вырост" сгодится.

ARM9-ому и выше если речь идет об эффективном создании GUI приложений альтернатив нет.
И проблема не в интерфейсе к TFT. Это всего лишь вопрос драйвер-а.
И даже если он оставит всего 10% процессорного времения в среде RTOS никто неудобства не почувствует.
Проблема в том, что действительно переносимые, симулируемые, с большим набором widget-ов и других ресурсов GUI как в MS Net. Micro Framework или Android или QNX Photon microGUI требуют рунтаймных мощных либ которые сносно потянет только ARM9.
Причем цена хардварного решения на ARM9 нынче не отличается от решения на ARM7.
"сложность" освоения ARM9 преодолевается за пару месяцев.
Но сколько придется корячится на либах Microchip-а чтобы создать картинку типа этой http://www.qnx.com/images/products/adv_gra...ha_blending.jpg и еще в динамике я не представляю. Одни только сглаженные фонты обойдутся в год жизни вероятно.
Как видно несоизмеримые "сложности".

К примеру:
В либе от Microchip-а: чтобы создать такой элемент как editbox надо подобрать координаты, нарисовать рамку, выбрать фонт, написать стороку этим фонтом, следить за нажатиями кнопок, парсить их значения, самому иммитировать изменения режимов курсора, самому передвигать курсор, передвигать инверсию селекции текста, следить за переполнением текста, за откатом, за окончанием ввода и т.д.

В нормальном GUI: рисуем на PC как нравится всю композицию и ставим куда надо editbox, назначив фонты, ограничения на длину, тип курсора и проч. мелочь. Компилируем как ресурс и пристегиваем к проекту.
В проге просто даем комманду вывести ресурс, регистрируем функцию которую вызовет GUI при окончании ввода в editbox-е и все!


Естественно для озабоченных "сложностями" подбирать ARM-ы надо в этом случае не по даташитам, а по списку наличиствующих BSP у производителя выбранного GUI.

Сдаётся мне, вы рассказали о ОЧЕНЬ хорошей GUI, и ни о какой халяве и речи быть не может. К ней и верхнии прожки должны быть.

Очень круто, конечно, но вряд ли это стоит советовать в теме про выбор первого ARM......

Александр, да я по большому счету не спорю.
Есть два аспекта:
1) Вопрос на самом деле несколько шире ARM. Допустим, стоимость аппаратуры одинакова, допустим, пару месяцев можно потратить на освоение ARM9. Дальше что? Для того, чтобы освоенные знания стали приносить отдачу, нужен источник денег. Если Вы одиночка, то постоянные разработки для кого-то, если Вы в команде, то команда. Вот Вы кто? Как Вы денежки "отбиваете" на ARM9?
Сейчас ситуация доходит до абсурда - сложные и массовые проекты делаются Китае, а в Европе мелкие и средние фирмы такую фигню производят... На модернизации этой фигни (заказал как раз ST7FOX-A ) проще заработать деньги.
2) Повторяюсь, но IMHO сложная прослойка GUI с масштабируемыми окнами и шрифтами необязательна. Наличием загруженных в память bmp и пяти-семи фиксированных шрифтов легко обеспечить и такие картинки, как в Вашей ссылке. Ну а количество ... Сколько нужно систем навигаций? В обычном приборе так ли нужно иметь GUI аналогично Windows?
Еще раз по поводу картинки. Недавно ехал на старом Форд -Фокусе со встроенной навигацией с немецким языком (знаю сотню слов) и алфавитно-цифровым дисплеем. Жесть, но работает... :-)