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

[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]

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

Если не поняли, объясню. Возьмём для примера плату 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). Скажите, что мешало Вам вывести ещё и эти сигналы, а заодно и все прочие, что есть у МК? Не хотелось увеличивать размеры и стоимость платы? Допускаю, что именно так. Но тогда вдвойне важно было бы тщательнейшим образом проанализировать, что разведено, а что -- нет, чтобы обеспечить максимальную гибкость использования.

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

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

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

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

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

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

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

[Ruslan1]

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

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

Холивар -- это как раз тогда, когда оппонента называют маразматиком, не имея никаких аргументов, кроме "это неверно, потому что неверно".

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

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

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

[SII]

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

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

Ну, маразматиком я вас не называл, я только назвал маразмом некоторые ваши высказывания о крутизне ассемблера.

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

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

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

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

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

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

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

[Ruslan1]

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

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

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

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

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

"Никогда не говори никогда". Есть задачи (и думается, что Вы это понимаете), которые в принципе невозможно решить на языке высокого уровня.

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

ведь volatile -- это как раз внешние устройства, а не обычное ОЗУ, которому пофиг, сколько раз писать одно и то же по одному и тому же адресу;

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

Так что для МКшника знать ассемблер необходимо, ну а где и когда его применять -- это уж задачами и прочими факторами определяется.

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

[SII]

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

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

1) Ассемблер имеет более читабельный код чем си

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

2) скорость написания на ассемблере немногим уступает скорости написания на ЯВУ.

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

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

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

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

А матфункции- фигня, я как-то писал умножение-деление-тригонометрию, легко и непринужденно, книжки есть с алгоритмами, только закодировать правильно нужно было

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

Про преславутое дрыгоножество и рассчет тактов - что, реально можете рассчитать на ARM по тактам с включенным кэшем и незапрещенными прерываниями количество циклов и его гарантировать? Уважаю...

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

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

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

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

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

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

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

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

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

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

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

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

Дурак был и никто не подсказал вокруг (интернета толком тогда и не было, а сам до такой крамольной мысли пользовать ЯВУ на МК не сразу додумался).

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