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

[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 -- это как раз внешние устройства, а не обычное ОЗУ, которому пофиг, сколько раз писать одно и то же по одному и тому же адресу; собственно, именно из-за этой ошибки я предпочёл низкоуровневый код писать не на Аде, как изначально планировал, а на ассемблере: там я, по крайней мере, точно знаю, где и что у меня происходит). Наконец, а вдруг данный конкретный человек решит заняться разработкой компиляторов или высокооптимизированных библиотек для них? Так что для МКшника знать ассемблер необходимо, ну а где и когда его применять -- это уж задачами и прочими факторами определяется.