Доброго всем времени суток!

Задача состоит в выборе, отладочной платки для изучения данного типа контроллеров(ARM). Я довольно свободно програмирую на АСМе для AVR(ATmega328p) но вот хочется чего-то нового.
Я недавно начал изучать эту тему.

Смотрел здесь:
http://www.starterkit.ru/html/index.php

Выбрал примерно следующее:
http://www.starterkit.ru/html/index.php?name=shop&op=view&id=2
и
http://www.starterkit.ru/html/index.php?name=shop&op=view&id=36 - просто интересный девайс

Что вы по этому поводу думаете? Или всёж не стоит брать это, а выбрать что-то другое и в совсем другом месте?

А зачем Вам плата с ПЛИС, а не только МК? Это ж прилично её удорожает...

Что касается этой конкретной, то подозреваю, что у тамошнего МК (AT91SAM9260) куча аппаратных ошибок, как это имеет место быть у 9261 (со вторым я сталкивался, а с первым нет, поэтому утверждать на 100% не могу). С этой точки зрения лучше брать плату на AT91SAM9G45: сам процессор быстрее плюс ошибок почти нет (исправили почти всё). Если нужно непременно с ПЛИС, у Стартеркита есть такая платка; правда, она подороже будет (8000, если не ошибаюсь).

Выбранный Вами дисплей можно подключить к платке с ARM9 и ARM7. Какую архитектуру хотите изучать Вы?

Если Linux не нужен, то берите LPC21xx или AT91SAM7xxx. ST брать не советую, для начала он слишком сложен. А если нужен Linux, то потребуется как минимум ARM9, например, тот же AT91SAM9XE512. Да, и об асме забудьте. По крайней мере на время. Придется изучить Си, без него в программировании ARM'ов делать нечего ...

Ну, насчёт асма лично у меня прямо противоположное мнение. Изучить архитектуру без изучения ассемблера в принципе невозможно. А вот от Си/Си++ я вижу лишь один вред. Если уж писать на языке высокого уровня, то на надёжном (Паскаль, Ада и им подобные), а не на рассадниках ошибок...

У LPC21xx, помнится, тоже море ошибок было, так что, если уж брать ARMv4T, то лучше LPC24xx (например, LPC2478: у Стартеркита есть платки на нём).

Не будем спорить. Мне не переубедить вас, а вам - меня. Я просто высказал свою точку зрения ...

О чём спорить? О языках? Так я не спорю, а тоже высказываю свою точку зрения вкупе с очень краткой аргументацией. Ну а если насчёт выбора контроллера, то всё достаточно просто: ИМХО, лучше изучение начинать с чего-нибудь не шибко глючного, поскольку обход аппаратных ошибок -- то ещё удовольствие, да и определённой квалификации требует. Ну а у старых АТМЕЛов и НХП багоглюков, увы, хватает... Поэтому, собственно, я и называю в качестве возможных кандидатов AT91SAM9G45 или LPC2478: они не безошибочны, но ошибок там очень мало по сравнению с их предшественниками.

Кстати, есть ещё один вариант: изучать не "настоящий" ARM, а ARMv6-M или ARMv7-M (более известны по названию своих ядер -- Cortex-M; отличаются от прочих ARMов совершенно другой системной архитектурой, в частности, обработкой прерываний, и отсутствием "родной" системы команд ARM), для чего у того же Стартеркита можно взять платку на LPC1788 (по ногам совместима с LPC2478, кстати, но сам процессор более быстрый и имеет несколько более богатую периферию).

Присоединяюсь.

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

Ассемлер не нужен. Тем более - в начале.

Смотря какие задачи.
Если поставили вписаться в 90 центов и 2 килобайта (а 32 кБ за цельный доллар никак не катят) - нужен.
Маразм, конечно, но могу похвастаться, что пока вписываюсь. Маньяк
Касательно армов, то да, асм разве что для диспетчеров задач RTOS, в остальных местах пока не встречался - м.б., плохо искал. Система команд кортексов пока без надобности, это при том, что с ARM/Thumb шапочно знаком, MSP430 не чужие, с AVR близко дружу, а 51 - совсем родные...

Оптимизировал математические вычисления (RSA), переписывая некоторые блоки на асме. Распечатал СИ - листинг и на его основе переписывал. Ну и при просмотре STARTUP - файлов желательно иметь некоторое представление о системе команд ...

Да, действительно, для понимания STARTUP ассемблер понимать желательно. Знать - не обязательно. Достаточно ориентироваться в общем.

Думаю, АСМ для АВР и для АРМ , как говорят в Одессе :"Две большие разницы!"

Не такие уж большие. Если хорошо освоил ассемблер одной архитектуры -- считай, быстро разберёшься с ассемблерами 95% других архитектур (а 5% на всякие извращения оставим, где придётся несколько поднапрячь извилины).

Разобраться-то может и не проблема - проблема в том, как это использовать. Команды в ARM настолько "многовариантны" (до трех операндов с опциональным сдвигом), что человеку очень трудно выбрать оптимальный вариант. В результате ЯВУ в 99% случаев дает лучший код

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

Ну а насчёт указанных Вами 99%... Скажу грубо: если эта цифра соответствует действительности, то 99% программистов, работающих с АРМом -- дебилы, причём не столько в ругательном, сколько в медицинском смысле. У АРМа очень простая система команд, и грамотное её использование никаких проблем для человека с вполне заурядными умственными способностями не представляет (у ИА-32, например, куда сложней и запутанней). Никакой особой многовариантности там, кстати, нет, так что оптимальный вариант чаще всего один, и он самоочевиден. Конечно, чтобы научиться "на автопилоте" выбирать именно лучший вариант, нужна практика, но так в любой области: нужно набить руку, чтобы стать мастером.

Там, где без этого не обойтись, да. А так мне гораздо проще написать проект на Си за один день, чем на асме за две недели. В конце концов, деньги мне платят за работающие проекты, а не за то, сколько я над ними просиживаю. И сопровождать проект на Си гораздо проще. И читать в 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.

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

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

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 контроллер, ничего переделывать не придется.

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



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



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

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

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

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

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

Собственно, я сюда заглянул лишь по просьбе человека прокомментировать подключение 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 миллионов строк.

Вот и следуйте этому правилу:



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

sasamy, я неудачно выразился, так сказать. Имелось в виду, что у СК есть не только "умные" (smart) дисплеи со своей видеопамятью, но и обычные "глупые", которые как раз и разумно применять с 9G45 и другими МК, имеющими собственный контроллер. Хотя по дисплеям я по-любому не специалист и даже планирую следовать тому самому правилу

Ну, я за 25 лет программизма (Начиная с ЕС1045 и 4-го Фортрана) не только (и не столько) с Си работал.


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


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

Подозреваю, что нам приходилось работать на близких вещах. Правда, на 1045-й почти не довелось, в основном 1035 и 1130, плюс СМки, плюс ещё всякое разное, но смысл не меняется... Но, как я сказал, "ничего личного": я понятия не имею, в чём Вы разбираетесь хорошо, в чём -- поверхностно, а в чём -- и вовсе никак.



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



Мне Ваш личный опыт банально неизвестен (как и Вам мой); соответственно, он не может служить некоей опорой. А "дедушки" разные есть. Никлаус Вирт или Эдсгар Дейкстра, например, очень даже дедушки, и что? Они Си уж точно никак не одобрят.



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



"Никогда не говори никогда". Есть задачи (и думается, что Вы это понимаете), которые в принципе невозможно решить на языке высокого уровня. Есть задачи, которые на ЯВУ решить теоретически можно, но на практике получается слишком неэффективно. Без знания ассемблера не всегда можно нормально отладить программу, написанную на ЯВУ -- например, из-за ошибок в компиляторах (а такое бывает; GCC, например, при включенной оптимизации любого уровня в каких-то не до конца понятных мне ситуациях генерировал лишнюю запись в память, объявленную как volatile -- а такая ошибка может быть фатальной, ведь volatile -- это как раз внешние устройства, а не обычное ОЗУ, которому пофиг, сколько раз писать одно и то же по одному и тому же адресу; собственно, именно из-за этой ошибки я предпочёл низкоуровневый код писать не на Аде, как изначально планировал, а на ассемблере: там я, по крайней мере, точно знаю, где и что у меня происходит). Наконец, а вдруг данный конкретный человек решит заняться разработкой компиляторов или высокооптимизированных библиотек для них? Так что для МКшника знать ассемблер необходимо, ну а где и когда его применять -- это уж задачами и прочими факторами определяется.

Не, у меня это было еще любительство непрофессиональное, я тогда школьником был. Но в ВЦ Академии наук проникал и казенное машинное время жрал
Да разве это работа была, сдаешь бланки (или колоду правленную)- на следующий день забираешь 3 метра распечатки с ошибкой.... А терминал свободный найти только в выходные можно было.... И свободный перфоратор тож фиг найдешь чтоб перфокарту заменить, спасибо дубликатор был. Я-то баловался, а люди так работали..... Уважаю.

Ну, тогда б точней обозначили, что именно маразматического в моих высказываниях...
Да я там процитировал. Вы писали что:
1) Ассемблер имеет более читабельный код чем си
2) скорость написания на ассемблере немногим уступает скорости написания на ЯВУ.


Угу, таки не в 2-3 раза, а уже в 50. Но поверьте, писать простейшую базу данных с индексированием на сях может быть даже не в 50, а в 100 раз быстрее. А уж если менять что-то в структуре или методах доступа к записям- отрыв от ассма будет еще больше. Я писал на асме один раз такое (да еще с логом статистики)- на всю жизнь воспоминания остались. А матфункции- фигня, я как-то писал умножение-деление-тригонометрию, легко и непринужденно, книжки есть с алгоритмами, только закодировать правильно нужно было.
Про преславутое дрыгоножество и рассчет тактов - что, реально можете рассчитать на ARM по тактам с включенным кэшем и незапрещенными прерываниями количество циклов и его гарантировать? Уважаю.... Уж не помню когда последний раз вообще такты считал ручками, обычно для дрыгоножества с точными времянками есть аппаратная периферия, да и не может дрыгоножество быть главным, тогда уж плисину проще приклеить.

Сами себе противоречите. Если бы сказали "Есть задачи которые конкретный программист не может решить на ЯВУ" -я бы согласился. Потому что другой программист может быть и может, кто его знает.

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

Если бы вы сказали что знание ассма более полезно чем умение стоять на голове- я бы согласился. Про необходимость- категорически против. Если совсем приспичит- откроет описание асмовских команд и построчно разрисует нужный кусочек. Но ни Вы ни я не можем предсказать на какой архитектуре ему это понадобится, то есть мнемоники зубрить- гиблое дело.
Лично мне жаль тех лет, которые я убил потому что не использовал ЯВУ на МК. Мог же быстро написать- и все, ан нет, сидел и корпел на ассме. А ценилось, что 10 лет назад, что сейчас, скорость получения продукта, а не его внутренняя вылизанность, от которой после двух-трех эктренных кординальных правок может ничего не остаться.
Дурак был и никто не подсказал вокруг (интернета толком тогда и не было, а сам до такой крамольной мысли пользовать ЯВУ на МК не сразу додумался).

С перфокартами чуть-чуть поработал, хотя мы с Вами практически ровесники. Однако ещё в школе (с 15 лет) работал фактически системщиком на СМ-1420 (де-юре, естественно, техником-программистом: в СССР занять инженерную должность невозможно было, не имея диплома), а затем несколько лет на ЕСках и системщиком, и электронищком...



Ну, именно так я не писал. Я писал о возможности ужасно запутать код на Си, в чём его превосходят только Си++ (в силу своей большей сложности) и Брэйнфак (ну, тут, как говорится, без комментариев, но понятно, что его я в шутку упомянул). На самом деле, если писать на Си аккуратно, не пользуясь его свободой, программа, конечно же, будет на нём более читабельной. Однако немаловажную роль играют комментарии, благодаря которым читабельность ассемблерной программы можно существенно поднять (ведь главная сложность в восприятии программы на ассемблере -- понять, что она делает в "глобальном" смысле, а не каждую отдельную инструкцию; в программах на ЯВУ это обычно намного очевиднее, если не валить множество действий в одну кучу -- чем, кстати, злоупотребляют программисты на Си, но это уже вопрос стиля). Хорошо написанная ассемблерная программа вполне себе читабельна и сопровождабельна (и уж точно легче, чем как попало написанная на Си). В общем, хотя низкая читабельность ассемблера и является реальным недостатком, это отнюдь не что-то такое фатальное, делающее его практически непригодным и т.д. и т.п.



А вот это я действительно утверждаю, но отнюдь не в таком категоричном виде. Здесь программа -- это некий сфероконь в вакууме, но ведь от рода задачи существенно зависит и скорость её написания на том или ином языке. Возьмите, например, программу, которая считает некие экономические данные (зарплату, например), а потом печатает огроменный отчёт на бумаге (платёжную ведомость). И ненавистный мне Си, и любимые Паскаль и Ада, и древний Кобол -- все являются языками высокого уровня. Однако, несмотря на все недостатки Кобола, именно он наилучшим образом подходит для решения этой задачи средствами самого языка (не привлекая сторонние библиотеки, программы и т.п.), поскольку в нём имеется свой генератор отчётов. Ну а на классическом Фортране писать подобную задачу -- это вообще ужас (мало того, что никаких отчётов он генерировать не может, так ещё и не имеет записей, удобных файловых операций, управляющих конструкций и т.п. -- заточен же под научно-технические расчёты).

То же самое касается и ассемблера. Есть задачи, где его использование действительно тормозит работу во многие разы и даже десятки раз, однако есть и такие, где применение ЯВУ не даёт действительно значительного выигрыша во времени создания программы. Плюс, как я писал, это сильно зависит от системы команд, ведь то, что на VAX-11 можно сделать одной командой, на ARMе (отнюдь не самая плохая система команд!) может потребовать целой подпрограммы. Соответственно, какую-нибудь задачу, сводящуюся к куче действий вроде "проверить бит -- установить бит", на Си можно написать за 1 час, на ассемблере VAX-11 -- за час с четвертью, а на ARMе -- уже за два-три часа. Программу, насыщенную сложными расчётами, на Си можно написать за час, на ассемблере VAX-11 -- за 5-10 часов, на ARMe -- пару дней убьёшь точно (и то, если уже есть библиотека для вещественной арифметики или имеется соответствующий сопроцессор, а если всё это самому писать и отлаживать... ну, ещё пару дней -- если алгоритмы знаешь).



О чём и речь: задачи разные бывают, а посему нечего ассемблер категорически отметать. Я вот с ужасом вспоминаю программу расчёта зарплаты для госучреждений вроде детсадов -- писали горячие литовские парни на ассебмлере, а когда Союз рухнул и разрядности полей экстренно поползли, то такое началось... Интересно, какой идиот решил писать экономическую задачу на ассемблере, когда имелся вполне вменяемый компилятор Кобола?..



Ну, не такая уж фигня, особенно если означенных книжек под рукой нет... Хотя по-любому проще, чем СУБД



Вообще, эта задача (но при запрещённых всё же прерываниях) решаемая даже при наличии кэша -- хотя гемор тот ещё будет, конечно. Однако существуют и АРМы без кэшей, где подобное решается почти столь же просто, как на AVR8 (ATtiny и ATmega всякие; думаю, со знакомыми Вам PICами та же история).



Не всегда такая возможность есть...



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



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



Зубрить -- абсолютно с Вами согласен. Но, не изучив ассемблер, нельзя вот просто так взять, открыть справочник и начать писать. Вот когда изучил хотя бы один на хорошем уровне, перейти на 95% других особого труда не составит.



От задачи зависит. У нас в конторе, например, заложили в проект весьма мелкую АТмегу с 16 килобайтами флэш-памяти, а задача всё разрасталась и разрасталась (аппетит приходит во время еды, как известно). В конце концов от этого флэша осталось меньше 200 байт. Писал бы на сях -- так и не выпустили б финальную версию продукта без кардинальной переделки железа. Что стратегический просчёт тех, кто такое решение принимал, оно понятно (меня тогда ещё в этой конторе не было, и почему именно её избрали, я понятия не имею), но ситуация, тем не менее, вполне жизненная и реальная.

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



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

Уважаемый SII! Не думаю, что лучший способ выразить свою критику Вы избрали. Принижая умственные способности оппонента (и возвышая свои таки образом), Вы не добьетесь положительного результата. Ведь когда человека ругают (пусть даже и заслуженно), какая у него первая реакция? Правильно, обида, ответная грубость и т.п. Не у всех, конечно. Я, как постоянный гость данного форума, хотел бы Вас попросить выражаться уважительно и более корректно! Как никогда между нами должно быть взаимоуважение! Иначе какая же работа может быть? Спасибо за понимание!


Не принимайте близко к сердцу. Вы делаете доброе дело! Предлагаете великолепные платы по доступной цене! У меня уже две ваши платки) Желаю от всего сердца продолжать Вам Ваш путь!

Господа, простите за оффтоп. Мне было обидно, что на человека, который мог бы и не делать, но делает доброе дело, напали с резкой критикой.