Здравствуйте.
Долго работал с RISK микроконтроллерами Atmel. Чувствую, вот оно, пришло время осваивать ARM !!!
В связи с этим прошу помощи, а именно:
1) нужна среда разработки. (В смысле где можно скачать). Конкретно интересно под AT91SAM7x. .
2) простейший программатор (схема, софт)
3) ну и назидательные советы, направляющие на путь истинный )))
Спасибо !!!

1) Keil, IAR, Eclipse.
2) Atmel SAM-ICE - но это наверное не самый дешёвый.


Зачем нужно начинать освоение с устаревшей архитектуры? Потому что есть плата с установленным SAM7?

Чем Cortex не устраивает? К тому же они проще...

1. Уже выше посоветовали.
2. Вместо SAM-ICE подойдет JLINK, к тому же в разделе по ARM нетленна ветка по самостоятельному изготовлению JLINK.
3. Купите какую нить девборду, курите даташиты, спрашивайте вопросы

1 - а где скачать то можно?
2 - мне бы самодельный сделать, для внутрисхемного программирования ... Есть где-нибудь схемки?
3 - Cortex - а что это, простите за глупый вопрос ... ?


2 - JLINK - а где веточку то посмотреть можно?
3 - да я ARM изучаю собственно уже с ориентацией на конкретный проект, так что борд не нужен, сразу лепить буду ...

Ещё вопросец: скачал дистрибутив Atmel Studio 6.0. что сие есть? Можно в нём работать под ARM7?

Я же казал Вам - поищите в разделе ARM

Нет. Можно работать с ATMEL SAM3 (Cortex™ M3)

Вы простите за глупый вопрос когда на сайт производителя каких-нибудь контроллеров в последний раз заходили? гда три четыре назад? Это вообще то новое ядро АРМ

www.iar.com
www.keil.com

Есть ещё ARMGCC. Скачать можно, например тут:
www.yagarto.de
там же есть eclipse и примеры для разных АРМов.


Говорят клоны jlink-а можно дешего купить.


Ну вы даёте...


Как это не странно - нет.
Хотя использовать как редактор и компилятор наверное можно. Но отлаживать не выйдет.

Cortex описание
http://www.gaw.ru/html.cgi/txt/doc/micros/...x_arh/index.htm
много готовых отладочных плат www.terraelectronica.ru в том числе с интегрировнными программаторами
вообще с армами по сравнению с тем что было лет пять назад, просто сказка
все можно почти за бесплатно получить
Если завяжитесь с кортексами от stm то пряма там в их софтовой либе можно посмотреть отладчики и ide под которые они портируют свой софт и выбрать что понравится
Удачи

Действительно, Cortex M3 лучше. Сейчас даже четвёртые пошли. Но вот только не могу найти полные Datasheetы ни на один контроллер, например,STM32F417. Где бы можно накачать?


Да я вообще кроме RISK ничего то и не видел ... )))

http://www.st.com/internet/mcu/subclass/1521.jsp
http://www.st.com/internet/com/TECHNICAL_R.../DM00035129.pdf
http://www.st.com/internet/com/TECHNICAL_R.../DM00031020.pdf

Ну так они ж все сокращённые ... Ознакомительные типа )))

А третья ссылка, которую я чуть позже добавилва, тоже не то?

К тому, кто найдет более полные, просьба свистнуть мне - собираю даташиты на МК по зову души и долгу службы (как библиотекарь ftp).

Ну и как с ними вообще тогда работать?

А я с ними и не работаю, а только даташиты на них собираю.

Вообще пишется RISC - Reduced Instruction Set Computer

Наверное все же RISC.

PS. ARM = Advanced RISC Machine.

Свищу - atmel.com, st.com, ti.com... e.t.c.

"Полные" даташиты
http://www.arm.com/products/processors/cortex-m/index.php
вкладка resources
Даашиты по конкретному IC с пенриферией уже прислали см. выше по ветке
хорошая тема по настройке eclips для кортекса от stm
http://makesystem.net/?p=988

Небольшая история про то, как я за одну ночь с AVR на ARM перешёл... http://www.cqham.ru/forum/showthread.php?t=11357

На Atmel Cortex M4 не надо?
http://catalog.gaw.ru/index.php?page=compo...il&id=66763

А чего вы тогда на AVR32 не перешли? Было бы логичнее.

Микроконтроллеры ARM7. Семейство LPC2000 компании Philips.
Микроконтроллеры ARM7 семейства LPC2000. Руководство пользователя. Редькин П. П. Формат DJVU. 16,4 Мб.
Микроконтроллеры ARM7 семейств LPC2300/2400. Вводный курс разработчика Книга представляет собой введение в архитектуру процессора ARM7 TDMI и микроконтроллеров семейств LPC2300 и LPC2400 компании NXP. В ней рассматриваются следующие вопросы: введение в ядро ARM7, средства разработки программного обеспечения, системная архитектура и периферийные устройства микроконтроллеров LPC2300/2400. 2010г.
+ CD к книге (33 МБ)
чтобы проще начать, нужно начать с покупки KIT а, наверника у местных есть который валяется и пылится,
отладчик пойдет MT-LINK
есть контроллеры которые с USB у некоторых есть загрузчик программы через USB. Тогда можно попробывать обойтись без отладчика.
Среда разаботки на вкус и цвет...

Спосибо огромное, но я тут по-моему уже в Cortex M4 от Atmel влюбился. Ночь провёл совершенно бессонную ...
http://catalog.gaw.ru/index.php?page=compo...il&id=61016
Вот где бы теперь под неё студию нарыть ...

Вот уж не проблема с тех пор, как Atmel Studio 6 стала поддерживать не только AVR, но и ARM контроллеры фирмы Atmel. Прямые ссылки на продукт (без регистрации) приведены на странице вот этого немецкого сайта:
http://www.mikrocontroller.net/articles/Atmel_Studio
(секция Downloads)

Спасибо огромное, по-поему то, что надо.

Удивитесь... У нас тогда AVR32 в продаже отсутствовали - так, чтобы пришёл и купил.
И дополню - AVR32 ничем из того, что можно сделать "на коленке" не прошить, а AT91SAM7S32 я шил WIGGLER-ом, а потом STK-200 (с помощью h-jtag).

Простите, а зачем для sam7 "делать" программатор? Насколько я помню, в этих контроллерах уже есть прошитый на заводе загрузчик (SAM_BA boot), и для их внутрисхемного программирования нужна только программа SAM-BA (лежит на сайте Атмела), которая программирует контроллер по RS232 и (или) USB...

За тем, что это не очень быстро. А во вторых отладчик на первых порах ой как нужен будет. Это справедливо и для кортексов.

Не подскажете, как у них там дела с симулятором? Не хуже Кейла для AT91?

На сколько я понимаю из информации на сайте ATMEL AVRStudio поддерживает только микроконтроллеры Cortex. Т.е. серия AT91 в список поддерживаемых не входит.

Чёт симулятор не включается для Cortex M4. Хотя компилировать компилирует.

Люди добрые, а существует вообще в природе asm для Cortex??? Или мне C учить ???????

Можете и на ассемблере. Вижу для Вас плевое дело. Вот тут качайте - http://infocenter.arm.com/help/index.jsp?t...g/Cfaggajd.html

Да я про компилятор ...

Это в Atmel Studio? Ага, понятненько. Спасибо.
Насчет асма.
Вы на этом этапе крепко сравните между gas(из GCC для армов) и тот, что кейловский. Имея в виду вопрос, как не подсаживаться на особенности синтаксиса того и другого.

Наверняка потому что нет его - отладка только через атмеловский j-link.


Зачем вам асм в чистом виде?


Конечно, как иначе. Но GCC допускает использование inline assembler-а.

Там же, по моему и компилятор можно скачать.

Что значит "допускает"? 8) А файлы *.S ?
А в этом инлайне разобраться - лучше нинада ужос.

Ну, можно пару строк в С-файле черкануть.


Я не пробовал - не нужно было.
Что лучше всю программу сразу в S-файлах писать? Вот где ужос.

Дык она там в 80% случаях на байт-код будет похожа: таблицы, таблицы ...
Ничего ужасного, дело вкуса.
Писанины поболее, - это такида, но блин, цмсис тоже подзадолбал своим графоманством.

Таблицы? Не представил...


Не мспользуйте cmsis, никто же не заставляет.

Оно всегда распадается на три резко контрастирующие части:
- быстрые подпрограммы - тут всё ясно,
- движок для тредов, тсз, недо-ось,
- медленный интерпретатор для работы с верхней логикой, - тут можно изголяться от макросов, конструирующих байт-код, до собственного языка, с символьным входным потоком
Тут и - сценарии инициализации периферии - пары <смещение>:<значение>,
и таблицы параметров для "общения" с внешним миром, итераторы всевозможные- с описанием работы в виде таблицы <адрес пп>:<адрес перехода, если пп вернула==0>:<адрес перехода если !=0>, причем адреса - короткие, в байт шириной, только зачем это всё - чем дальше, тем непонятнее, - кругом велосипеды .

Жесть... И всё на асме? Двойная жесть.

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

А писать на асме, например, функцию strcpy или sprintf, это, извините, маразм.



Подумайте, что проще - изучить Си, который применяется поголовно на ВСЕХ процах (даже на АВР-ах без RAM ) или очередной ассемблер.
Я не отговариваю Вас от асма, но прикиньте, вы его изучите, допустим для того же Cortex M3, убъёте на это, например, 2 недели. Потом вдруг осознаете, что этот M3 Вас чем-то не устраивает (например, тем что оно гарвардское, а не фон-неймановское), и решите заняться ARM7TDMI. И будете ОПЯТЬ 2 недели учить ассемблер, уже для ARM7TDMI. И т.д. до бесконечности ....
В итоге Вы будете изучать не новые таймеры, АЦП и прочие плюшки нового контроллера, а то, как запрограммировать ( a + b ) / c, потому как
mov ax, a
mov bx, b
mov dx, c
add ax, bx
div dx
будет работать на 8086, а на AVR или Cortex M3 это всё надо переписывать в силу того, что регистров ax, bx, dx там нету (но есть какие-то другие) и делить оно само не умеет (AVR точно не умеет, M3 - не знаю ) и это опять же надо писать самому.

А любой компилятор Си подобные "уравнения" понимает от рождения и переписывать их каждый раз не нужно. И можно заниматься делом, а не арифметикой. А арифметикой заняться когда того потребует тот или иной конкретный проект.

Это моё мнение, как человека, писавшего программы для Z80, 80x86, x51, AVR и теперь на ARM (AT91SAM7).

Гыыы... ржунемогу. Мож за два месяца? Или за год?

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

Второй момент, что 50% программы это не работа с портами ВВ а что то более осмысленное, которое, при определенном навыке, вообще можно отладить на компиляторе для РС, т.е. на х86.

Когда об этом говорят все, начинаешь сомневаться, правда ли это.
Вы думаете, всем нужен sprintf() в таком виде, в котором он есть?
Вы думаете, что гораздо проще "от балды" сидеть на си, не зная ассемблера?
Вы думаете, что все неизбежно пользуются плавучкой? Это еще при том, что в си нету нативной поддержки fixed point, dsp-инструкций и подобного, всегда надо чего-то допиливать.
Повторяю, люди, пишущие на асме, в основном, приходят к виртуальным машинам, пусть примитивным, но устраивающим почему-то.
А в этом деле главное - отстроить движок - всё сразу портируется. Тут еще сторонники форта на ум приходят - тоже есть аналогии в методах работы.


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

Дак это и есть самый большой плюс переносимости. Потому как для каждой платформы все равно код для работы с портами ВВ, хоть на ассемблере, хоть на Си приходится переписывать. Я называю это драйвером

Тем более. Лишний аргумент в пользу Си. Про 2 недели я образно выразился. Хотя основы можно и за 2 недели выучить ... Чай ТС не студент, которому в институте только делфи и C# преподавали. Слова типа "регистр" и "косвенно-индексная адресация" его явно в шок не ввергают.


А чем он плох? Тем, что "много лишнего"? Если не нравится, пишите свой, я не против . Я не сторонник изобретать новый велосипед, если в старом мне не нравятся одни лишь педали ....


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


А при чём здесь "плавучка"? Плавучку как раз лучше на си применять, а не на ассемблере.
Битовых операций в СИ тоже нету. На этот счёт есть "компиляторо-зависимые расширения", типа PORTA.0 в CvAVR или asm вставки, которые тоже одни хвалят, другие ругают почём свет стоит и пишут на GCC общепринятые конструкции типа PORTA|=0x01 ещё и с кучей макросов "для удобства". А потом иди гадай, что там в машинном коде стоит, одна команда типа sbi или or с кучей регистровых пересылок.



Согласен на все 100. Сaм стараюсь так писать .

Это все красиво, когда нет влияния окружения - оси, или... вот простой пример: есть DMA - нету DMA. Появляется сразу некий средний уровень между HAL и приложением. Игнорировать - гробить ресурсы.


Самый правильный ответ: "А чем он хорош?"
Педали там такие, что для разных размещений форматной строки у нас зоопарк функций, и без "много лишнего" - получается вообще ничего, поскольку там все красиво увязано с остальными сущностями stdlib. Лично мне больше нравится printf с хэндлами - вроде как "вес строки" не теряется и не надо дополнительных телодвижений. К тому же, у меня редко, когда тред "стучит" больше чем в один поток ввода-вывода.

Это уже диалог глухих

А нафига оно надо, чай не 90-е

А никто и не игнорирует. Я ж сказал выше - под каждую платформу, в зависимости от требований и архитектуры, пишется драйвер. Есть DMA на Марсе, нет ДМА на Марсе, науке это известно (С)

Еще один плюс в сторону СИ. Вот сейчас работаю над проектом. В основе XMEGA (заказчик пожелал). Работаю сейчас как раз над HAL. Милое дело Пишу на Си. Драйверы под внешние устройства (к примеру AT45DB) имеются. И с DMA и с 'тупо в лоб'. Ну милое дело. Так как я не думаю о том, как передавать параметры из HAL в драйвер DataFlash. Пусть компилер голову греет. Зато я грею голову пивом. И не плохо идет