Там, где без этого не обойтись, да. А так мне гораздо проще написать проект на Си за один день, чем на асме за две недели. В конце концов, деньги мне платят за работающие проекты, а не за то, сколько я над ними просиживаю. И сопровождать проект на Си гораздо проще. И читать в 1000 раз проще, особенно если проект большой. Так что в 99% смысла в программировании на асме для ARM нет. Оставшийся процент - это те самые зубодробительные задачи, вроде ЦОС на пределе возможностей МК ...

Во-первых, о читабельности. Запутать программу в большей степени, чем на Си, можно только на Си++ и Брэйнфаке Понятно, что, если писать аккуратно, не стремиться экономить нажатия на клавиши и валить в одну строчку несколько разных операций, читабельность кода на Си будет выше, чем на ассемблере. Но это не такая большая проблема, поскольку никто не отменял комментарии для пояснения, где что делается. Можно сказать, что написание комментариев увеличивает время, расходуемое на задачу, и это действительно так. Но, с другой стороны, комментарии не только облегчают понимание кода в будущем, если к нему придётся вернуться, но зачастую помогают выбрать более эффективный путь решения задачи: пока их пишешь, обдумываешь эту самую задачу (конечно, речь о полезных комментариях, а не из серии: MOV R0, R1 ; Пересылаем R1 в R0 ).

Во-вторых, один день и две недели, т.е. разница в 14 раз -- это Вы загнули. Единственное, что всегда занимает на ассемблере больше времени -- это кодирование программы (надо набрать куда больше исходного текста, чем на языке высокого уровня). Однако решение задачи не из одного кодирования состоит, причём кодирование занимает весьма небольшую часть времени. Отладка, например, на ассемблере может в некоторых случаях оказаться даже проще, ведь там ты реально видишь, что делает процессор, а не пользуешься какими-то своими представлениями о том, что должно бы делаться, исходя лишь из текста программы на ЯВУ (всякие гадости могут возникать как из тонких моментов языка, так и из-за банальных ошибок в компиляторе). Решение задачи на "алгоритмическом" уровне -- т.е. выбор подходящего алгоритма, определение структур данных и т.п. -- вообще от языка программирования никак не зависит, по большому счёту (а если зависит, то больше в плане возможностей языка: ну нельзя на классическом Фортране использовать списки -- у него нет средств работы с адресами памяти, как их ни называй). В общем, 14-кратная разница во времени создания программы на ассемблере и ЯВУ -- это скорей исключение, причём редкое, чем правило. На ассемблере уровня ARMа, по моим ощущениям, разница будет в 2-3 раза, на более удобном ассемблере (PDP-11 и VAX-11, например) -- 20-50% времени. Если использовать не ненадёжный и провоцирующий ошибки Си, а Паскаль или Аду, разрыв станет больше (в первую очередь за счёт резкого уменьшения числа ошибок, а значит, облегчения отладки), но там проблема найти инструментарий (например, для АРМа единственная доступная Ада входит в состав GCC, что автоматически означает низкое качество генерируемого кода, а временами неверную кодогенерацию; насчёт ФриПаскаля ничего не скажу, поскольку пока никак не попробую).

Ну а в-третьих -- и самое главное в данном случае: в этой теме речь идёт о контроллере для изучения, а не для работы -- а это немного разные вещи. Не знаю, как кто, а я в принципе не могу считать грамотным программиста, который не владеет свободно ассемблером того процессора, с которым он работает (речь, естественно, о сегменте микроконтроллеров идёт; для решения всяких там бизнес-задач на ПК ассемблер в принципе не нужен, и даже подозревать о его существовании не требуется); соответственно, для меня обучение включает в себя и изучение системы команд и прочей низкоуровневой архитектуры.

Не хотели холивар начинать, а всё-таки начали.

Спорить про C/C++ vs Asm уже давно надоело. Хочется верить в могущество асма и убогость C/C++ - сколько угодно. Только сказанное в предыдущем посте очень сильно не соответствует действительности, и все эти ужасы про ошибки ненадёжного и негодного С скорее указывают на уровень владения этим языком. А уж ставить С/С++ и Брейнфак на одну полку неуместно даже в шутку. Писать большие... и даже средние проекты на асме нынче могут позволить себе только те, у кого много свободного времени, которое им почему-то не хочется потратить на изучение более эффективных средств.

Спорить о C & ASM уже заезженая и не актуальная тема. это лишь инструменты как молотоки или кувалда и чем работать каждый выбрать должен сам и это будет его выбор. Перестанем об этом говорить.
Вернёмся к теме поста.
Что же всё таки выбрать??
Я не могу решить в какую сторону стоит капать.
ARM9 или ARM7...?
STM | NXP | ATMEL... ?
Модель?
Какие преимущества недостатки? (Можно ссылками на статьи)
Наличие литературы по данному контролам (Желатеьно на русском. с англ. просто возиться дольше придётся).
Вот как-то так. Меня не интересует на чём писать. Я одинаково владею АСМ(на AVR) и С++(консольный под IBM PC пока что).

ИМХО NXP как-то чаще мелькают в разработках. А значит на начальных порах будет легче разобраться (опять же ИМХО).

Если с армами Вы не знакомы вообще, то я бы посоветовал ARM7. Он легче. Можно больше сосредоточиться на "железе". ARM9 это уже как-то для "серьезной" ОС подходит. Она может "затмить" микроконтроллер, помешать его изучению.

По ARM7 есть очень даже неплохая книга Мартина Тревора "Микроконтроллеры ARM7 семейства LPC2300/2400". Есть в сети на русском.
З.Ы. Английский советую освоить, даже на этой книге. Он все равно обязателен. Изучать до беглого чтения без словаря!

Вот только ассемблер под AVR Вам мало поможет в освоении ARM Загляните в список инструкций ассемблера и Вы поймете о чем я)
З.Ы. Консольного Си++ не существует) Вывод информации пользователю зависит от ОС и используемых библиотек ввода-вывода так сказать

Не было никакого холивара (во всяком случае, с моей стороны). Я лишь утверждал и утверждаю, что без знания ассемблера нет настоящего специалиста, работающего с МК, а значит, его освоение обязательно. Дискуссия ж о том, на чём делать коммерческие проекты, явно выходит за рамки этой темы.



Вот с этим абсолютно не согласен. Какое отношение имеет серия ядер к сложности освоения как таковой? Наличие устройства управления памятью (MMU) или защиты памяти (MPU)? Так его никто не обязывает использовать: всё и без него работать будет, оно ж после сброса выключено. Ну а всё остальное у собственно ядер с точки зрения программиста почти одинаково и не тянет за собой каких-то дополнительных проблем (наличие дополнительных инструкций в более поздних ядрах ничего не меняет: не надо или не хочешь -- не изучай и не используй). Так что, если уж говорить о ядрах, надо выбирать не между ARM7 и ARM9, а между "настоящими" ARMами (к коим относятся и эти две серии, и новейшие Cortex-A, и ряд других) и ядрами серии Cortex-M, поскольку в зависимости от выбора придётся иметь дело с совершенно разными системными архитектурами (набор режимов процессора, набор регистров состояния и управления, обработка прерываний и т.д.), совершенно не совместимыми друг с другом.

Вот в периферии различия, конечно, есть, но они больше зависят от фирмы-производителя, чем от версии ядра. Например, у той же NXP: LPC24xx с ядром ARM7TDMI и LPC17xx с ядром Cortex-M3. Системная архитектура различается кардинально, однако периферия, имеющаяся у обоих семейств, чуть ли не на 100% совпадает.

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



Ещё как поможет. Список инструкций вообще никакой роли не играет, по большому счёту: главное -- сам подход, "менталитет", если угодно. Это с ЯВУ на ассемблер трудно перестроиться, а с одного ассемблера перейти на другой -- никаких проблем (разве что если этот "другой" уж очень извращённый, что ни про AVR8, ни про ARM не скажешь).

Пы.Сы. Если выбираете освоение "нормального" ARMа, то, ИМХО, лучше брать ATMEL AT91SAM9G45 или NXP LPC2478. Они сильно различаются по периферии (разные фирмы) и производительности (400-МГц процессор с ядром ARM9265EJ-S в одном случае и 72-МГц ARM7TDMI в другом), но оба доступны на дешёвых стартеркитовских платах (и не только на них), имеют приличный набор периферии и почти свободны от аппаратных ошибок. Если же привлекательны Cortex-M, то -- NXP LPC1788 (по периферии очень близок у LPC2478, хотя существенно быстрее -- то ли 100, то ли 120 МГц, ну и полностью отличается собственно процессорным ядром) либо что-нибудь из STM32.

Сообщение отредактировал SII - Oct 10 2011, 15:15

Чтож, мнений выражено достаточно) Каждый изложил видение на проблему со своей точки зрения, с учетом опыта, с учетом предпочтений. Автору темы лишь остается сделать собственный выбор!

Могу предложить несколько подходящих вариантов:

1. http://starterkit.ru/html/index.php?name=shop&op=view&id=49
2. http://starterkit.ru/html/index.php?name=shop&op=view&id=48
3. http://starterkit.ru/html/index.php?name=shop&op=view&id=5
4. http://starterkit.ru/html/index.php?name=shop&op=view&id=66

ну и + дисплейчик:
http://starterkit.ru/html/index.php?name=shop&op=view&id=36

Больше всего склоняюсь к 1-му варианту.

Если склоняетесь к первому варианту - дисплейчик берите другой, у этого


это smart панель, со своим контроллером + видеопамять, вам нужна dumb панель (например эта http://starterkit.ru/html/index.php?name=s...view&id=35)

Этот совершенно нормально работает с процессорными платами Стартеркита; есть ли у него видеопамять, я, честно говоря, не знаю, а сейчас смотреть лень, но процессор управляет им через собственный контроллер LCD со всеми положенными сигналами развёртки, а картинку берёт из внешнего ОЗУ.

Единственный недостаток, но он у всех дисплеев и процессорных плат от СК -- через задницу сделанная разводка. Например, для общения с АЦП сенсорной панели используется интерфейс SPI, но не встроенный в процессор контроллер, а его программная эмуляция! СКшникм, вероятно, религия не позволяет разводить платы по-человечески и использовать аппаратные контроллеры. Так что, если есть желание работать с тем же АЦП нормально, придётся переделывать кабели, связывающие процессорную и дисплейную платы. Впрочем, это лишь неприятные мелочи, серьёзных проблем не вызывающие.

Зачем так спешить с выводами, к 9G45 нет смысла подключать смарт панели со своей видеопамятью на борту (разве что Вы намеренно это желаетет сделать по своим соображениям, например - разгрузить шину, хотя это больше гемороя принесет чем пользы системе), для плат на 9260 я это сделал от безисходности. К 9G45 уместнее подключать обыкновенные TFT.

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

Совсем не уместное заявление, скоро год как на всех 4,3" (да и на 7" так же) плагах выход TS стекла можно коммутировать джамперами и подкючать его в чистом виде к контроллеру или к контроллеру TS (SPI).
И в Linux BSP 9G45 это давно внесено - можно выбрать какой контроллер будет координаты считывать, строенный АЦП или внешний TS контроллер, ничего переделывать не придется.

Сообщение отредактировал starterkit - Oct 11 2011, 12:35

Их надо ещё найти, купить, распаять... А тут -- готовое решение, пускай и не самое оптимальное.



Совместимость -- оно понятно, но что мешало сразу головой подумать? Или наличие SPI-контроллеров в составе любых МК -- тайна за семью печатями, лишь недавно ставшая достоянием гласности?



Ещё какое уместное. Во-первых, встроенный в МК контроллер TS есть далеко не у всех (у AT91SAM9G45 есть, а у того же LPC2478 -- нет). А во-вторых, ноги AT91SAM9G45, используемые для подключения TS, используются заодно для таймеров, ну а, например, в моём случае таймеры жизненно необходимы, поэтому использовать встроенный контроллер возможности нет в принципе, и приходится опираться на внешний АЦП -- а значит, резать провода и т.д. и т.п.

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

Пы.Сы. Ничего личного, просто констатация факта: конструкция плат продумана как следует не была, из-за чего имеем определённые проблемы.

Пы.Пы.Сы. Таки да, есть у СК доступный дисплейчик без памяти: http://starterkit.ru/html/index.php?name=s...=view&id=35. Что-то я стормозил сразу

Пы.Пы.Пы.Сы. А сделать можно, на самом-то деле. С тем, что уже выпускается -- нет из-за сохранения совместимости. Но все новые платы можно разводить уже по-нормальному, они же совместимостью не отягощены. Да и со старыми, честно говоря, тоже вопрос... Я б, например, был бы только рад, если б разводка изменилась на вменяемую: мне же проще стало бы.

Сообщение отредактировал SII - Oct 11 2011, 12:54

Собственно, я сюда заглянул лишь по просьбе человека прокомментировать подключение TFT панели с процессорным интерфейсом к 9G45 и высказался по этому поводу.

Этого выпада я вобще не понял ...

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

Бред какой-то.
Самое грустное- что кто-то из начинающих может это принять за чистую монету.

to Топикстартер- фильтруй! верить всему на слово не стоит.

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

Если не поняли, объясню. Возьмём для примера плату SK-MLPC2478. У МК LPC2478 нет никакого встроенного контроллера TS, поэтому работать с сенсорной панелью он должен через установленный на дисплейной плате АЦП. На Ваших "дисплейных" разъёмах выводы от этого АЦП подключены к ногам 5 (выбор кристалла), 35 (вход данных), 37 (запрос прерывания), 39 (выход данных) и 40 (синхронизация). АЦП "общается" с МК по интерфейсу SPI, поэтому совершенно логично было бы подключить его к одному из имеющихся у LPC2478 контроллеров (один "просто" SPI и два SSP). Однако Вы этого не сделали, из-за чего использовать эти самые контроллеры невозможно, и приходится эмулировать SPI чисто программными средствами, что не только усложняет программу (писать лишний код), но и занимает процессор дурной работой. У Вас выведены все четыре ноги контроллера SPI, но они находятся на двух разъёмах: X11 (6 -- SCK, 3 -- SSEL) и X4 (дисплейный; 39 -- MISO и 40 -- MOSI). Выведены и ноги SSP0, и тоже на два разъёма (X1: 21 -- SCK, 31 -- SSEL, 36 -- MISO; X7, 28 -- MOSI). Скажите, что Вам, как инженеру, мешало любой из этих контроллеров развести на соответствующие контакты разъёма X4 (5, 35, 39 и 40), чтобы с АЦП можно было работать через аппаратный контроллер SPI/SSP, а не программно? А заодно хотелось бы услышать, какие непреодолимые препятствия стояли перед Вами, из-за которых Вы не расположили эти сигналы на одном разъёме рядом друг с другом, а раскидали их по разным разъёмам.



Думать головой надо было, а не разводить первым попавшимся способом. Насчёт SPI и SSP для 2478 я уже написал выше, как надо было развести применительно к имеющимся дисплейным платам. На платах с 9G45 Вы, слава Богу, уже догадались, что сигналы, относящиеся к одному интерфейсу, должны находиться на одном разъёме и предпочтительно рядом друг с другом (SPI0, например, занимают ноги 37-40 разъёма X1/X4, а SPI1 -- на том же разъёме, ноги 20-22 и 32). Вы даже вполне разумно решили, что, раз уж этот МК имеет встроенный контроллер TS, то есть прямой смысл использовать именно его, а не внешний АЦП, и вывели линии 20-23 порта D на дисплейный разъём. Однако Вы не удосужились проверить, имеются ли ещё какие-нибудь линии таймеров, кроме тех же самых PD[20:23], и развести их. Если б таковых линий не было, то претензии были бы к ATMEL, а не к Вам. Однако такие линии есть: тот же порт D, 29-31. Однако на Вашей плате они вообще не разведены, а поэтому использоваться не могут (и даже проводами не подпаяешься: корпус-то BGA). Скажите, что мешало Вам вывести ещё и эти сигналы, а заодно и все прочие, что есть у МК? Не хотелось увеличивать размеры и стоимость платы? Допускаю, что именно так. Но тогда вдвойне важно было бы тщательнейшим образом проанализировать, что разведено, а что -- нет, чтобы обеспечить максимальную гибкость использования.

Так что, извините, с таким подходом к разработке вам как инженеру действительно грош цена, хотя это ещё не повод топиться, тем более в слезах.



А это и есть чистая монета. Если, к примеру, Вы (ничего личного!) не умеете хорошо писать на ассемблере или не знакомы в достаточной степени с Адой и Паскалем, а пишете только на Си, то как Вы можете сравнивать эти языки и делать какие-то выводы "на все случаи жизни"? Они будут справедливы разве что для Вас лично...



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



Холивар -- это как раз тогда, когда оппонента называют маразматиком, не имея никаких аргументов, кроме "это неверно, потому что неверно". Ну а заодно когда подменяют саму тему. Ещё раз повторюсь: речь шла об изучении, а не о создании каких-либо крупных и сложных проектов. Я утверждаю, что невозможно качественно изучить МК, не изучив на хорошем уровне его ассемблер, но не то, что на ассемблере надо писать программы в 10 миллионов строк.