Какой контроллер выбрать в образовательных целях., Определяюсь с выбором контроллера для самообразования. Опции

[0b11011110]

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

Задача состоит в выборе, отладочной платки для изучения данного типа контроллеров(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 - просто интересный девайс

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

[SII]

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

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

[kovigor]

... и грамотное её использование никаких проблем для человека с вполне заурядными умственными способностями не представляет

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

[SII]

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

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

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

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

[Ruslan1]

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

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

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

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