Однако вопрос как вы контролировали их производительность, чтобы она была одинаковой?

Ну понеслась она по кочкам

Таймеры в кортексах наворочены до тошнотиков, но программировать их увлекательно! (нежели уТомительно). Поэтому да, что бы запустить ножку на генерацию ШИМ, понадобится 17 строк кода. Ну так это же прикольно! Там столько возможностей, что аж дурно становится..

И потом, что тут за наезды на ассемблер?

Именно в кортексах ассемблер самый прикольный из всех возможных! Причём полностью и хорошо документирован! Правда на английском. Нужна русская книжка. Там именно возможности и ещё раз возможности. В отличии от AVR8, где всё по струнке, тесными рядами, в 8-битном формате.

Только могли бы в М7 набросить командочек ещё каких-нибудь прикольных.

Недостаток у кортексов один - мало регистров

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

На мой взгляд, на ассеблере стоит писать лишь времязатратные алгоритмы, типа БПФ. Причем так, чтобы сперва дать C/C++-компилятору все откомпилировать, а потом вырезать из ассеблерного листинга данную процедуру и оформить ее в виде ассеблерной функции. А когда заработает, то подредактировать ассемблерный код так, чтобы меньше писалось в память, а больше сохранялось в регистрах (если последних достаточно).

А сейчас в отношении регистров меня больше интересует вопрос о том, как в них держать число double64 (которое с двойной точностью). Станут ли у M7 все регистры вдвое длиннее или только некоторые из них? (Можно слазить на сайт ARM для выяснения этого вопроса, но может быть кто-то сходу может дать ответ?)

Посмотрел. Но Keil там не упоминается. Расскажите, как вы узнали, что Keil слабее IAR.

Мне посчастливилось запускать Coremark на keil для STM32f7, и он показал 820 очков на 200мгц. Ну и специалисты из STM объяснили почему. Могу поделиться проектом с тестом coremark, если кому интересно.

keil потому не упоминается, что смысл показывать меньшую производительность отсутствует. В eembc производители сами предоставляют результаты теста.

В M7 регистры как регисты, как в том же M0. Двойную точку читать и сохранять можно будет групповой операцией LDM/STM.

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

И потом, я сейчас устрою дебош. Разобью всю мебель, посуду и выпивку

Инициализация процессора по включению питания. Запуск генерации ШИМ, например для подсветки ЖКИ:

- на меге 256 = 16 строк кода
- на кортексе М407 = 17 строк кода

Блин... я всю жизнь мечтаю встретить программиста! А не мечтателя-фантаста. Хоть один тут есть?

Хватит уже наезжать на ассемблер и на превосходную архитектуру кортексов!

Ну, так куда же она читается из памяти и откуда туда пишется?


Вам крупно повезло, это я! Но с кортексами не работала, а потому и ассемблера их не знаю.

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

Забавно. Интересно, как выглядит на ассемблере веб-сервер или что-то в этом духе? А если другой процессор, то затачивай перо и строчи заново? Класс! Дайте две!

Ну.. у сопроцессора же есть свои регистры. У них есть свои прямые имена S0-S31. Ничего в памятях сохранять или читать не надо. Из обычных регистров пересылаем данные в регистры сопроцессора командой VMOV S0, R0 например. И всё

Всего у сопроцессора 32 регистра. Но они объединены ещё и в регистровые пары, с именами D0-D15. Это как указатели в АВРках - регистры X, Y, Z, хотя на самом деле их не существует.

scifi

Я веб-сервер ещё не писал, хотя планирую. Выглядит наверное так же, как и все серверы. Только очевидно постабильней и пошустрее будет. А может и на 100% стабильный, почему бы и да? И перенести его на любой камень не пролблема. Представьте себе, теперь и в атмелах и в других камнях, один и тот же набор команд. Это же кортекс

Это раньше было, у каждого своё ядро....

Вот поднял сетку CAN. Всё на ассемблере, на прерываниях. Длинна UTP кабеля 137 метров. Скорость 100k. На 1.000.000 сообщений ни одной ошибки передачи/приёма. Оказалось всё просто до банальности, дольше собирался..

Не думаю, что http такой уж шибко сложный будет.. Я сетевые протоколы ещё на perl писал. Писанины конечно побольше, чем с CAN, ну ничего..

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

LWW, а почему вы не пишете на C?

А вот мне довелось сбацать свой веб сервер (а так же TFTP, SNTP, SNMP), перейти на другой проц, а там всё это скомпилировалось и просто заработало.

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

Для технических текстов, конечно, английский гораздо удобнее. Пушкин и Толстой не были инженерами :-)

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

Глянул документик, ну нормально, для 2000 года вообще фантастика. Тогда ещё слова "микроконтроллер" не существовало. В реальности F4 уже давно зарулил всё это. За счёт влияния на флаги и условного исполнения, F4 вообще незарулен. Там много вкусностей.

Хотя странно конечно... Кортексу понадобилось 15 лет, что бы повторить математический успех DSP двухтысячных?

Вы бы постеснялись высказывать такие заявления...

Не надо путать систему команд, язык ассемблера, архитектуру ядра, надежность, быстродействие, русский язык и 137 метров кабеля.
Без обид: система команд cortex задумана как самая оптимальная для ЯВУ типа Си; архитектура cortex задумана как дружественная для rtos.
В задачах "ШИМ" и "CAN" гораздо удобнее пользоваться Си.
Вы операционками не пробовали заняться, чтоб "выдавить" по максимуму из архитектуру и системы команд?

В рамках топика "Cortex-M7" глупо обсуждать asm, т.к. и размера памяти, и быстродействия у МК будет огромное количество, - а забить мегабайты asm-кодом не реально)
Надежность программы целиком зависит от программиста. CAN одинаково будет работать на 137 метрах как в программе на asm, так и на Си. Разве нет?

Кста: программу для Cortex-M можно целиком написать на Си без единой asm-строчки (включая startup).

Все-таки мне кажется, что "успех DSP двухтысячных" кроется в железе, а не в системе инструкций. Т.е. не интерпретация инструкции здесь тормозит выполнение команды, а скорость выполнения самого умножения с накоплением.

Кста2: обработчики прерываний - обычные функции без asm-оберток.

p.s. если кто не знал, то вот и вот. Всего инструкций, как минимум:

116 - ядро
88 - DSP
36 - мат. сопроцессор

Но многие из них расширяются, в итоге иинструкций становится тысячи. Есть инструкции, работающие с 3 и 4 регистрами одновременно. Мало? Плохой ассемблер

В M7 ещё ожидаются улучшения сопроцессора, по поводу двойной точки. Ждёмс, ещё не выложили..

p.p.s. как замутить ассемблерный проект - тык.

Нет такого единого языка. А если и есть, то это Си, без вариантов.

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

Упираться сейчас в ассемблер, уже не можно, эта мода прошла где то в 90 годы прошлого века, если не ошибаюсь...

Программа на С пишется быстрее и с меньшими трудозатратами, значит более трудный проект будет написан быстрее или с меньшим число ошибок. Что в итоге влияет на цену, и как не странно качество продукта. Потому что хорошо понятно написанный код с продуманной архитектурой может в принципе не иметь ошибок кроме системных. А последние в удобно читаемом коде правятся опять же быстрее и лучше. В итоге конечный пользователь получает хороший продукт и в срок, а не пойми что, что гномы ковали в пещере год, а потом еще 3 отлаживали....

Потому вести проект на ассемблере сейчас - это вредительство и саботаж! И если в 90 еще кто-то как-то еще выступал, то сейчас это однозначно!

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

Меня другое раздражает в нынешних программерах, особенно в инетных, помню, лет 8 назад, чтоб проверить почту, загружал 50-70 кило кода и все работало прекрасно, скорости хватало, кэша в тамошнем браузере тоже, теперь - это кошмар, по нескольку мегабайт грузит как правило совсем ненужного кода и скриптов, в обычном ПО, то же самое, проги занимают мегабайы и гигабайты, тормозят, глючат, хотя по функционалу вообще не очень, что и изменилось, требуются всякие фреймворки пачками...

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

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

Личные автомобили и скот было запрещено иметь еще во времена DOS, когда доступ к диску можно было получить лишь по прерыванию 21h. Начиная с Windows NT/2000, был запрещен прямой доступ к любому железу. А сейчас полным ходом идет экспроприация того самого визуального интерфейса связи с пользователем. Т.е. это именно та политика, чтобы раскулачить разных сей и дельфей, чтобы им было не повадно пользоваться собственными библиотеками классов типа MFC, VCL, QT и т.п. И хотя декретом этого запретить пока еще нельзя, операционные системы быстро обрастают недокументированными особенностями, за которыми частные производители GUI-библиотек вовремя отследить не поспевают, а потому и допускают массу глюков. Наглядная тому аналогия - глюки браузеров при показе страниц, несмотря на то, что HTML/DOM хорошо стандартизован и на несколько порядков (!) проще, чем интерфейс связи с операционной системой.

На очереди стоит запрет для пользовательских программ исполнять код процессора. Для этого и подготавливают почву дотнеты и шарпы.

Эт потому что игнорируете интернет и нас хотите убедить что его нет.

А приложения между тем уходят в облака. У какого фреймворка лучше поддержка облаков и WEB интерфейсов то и выигрывает.
Нынче если не умеешь программировать WEB приложения, то считай уже и не программист.

А еще мобильные платформы есть.
Тут, кстати, дельфи вполне достойно смотрится.

Ну если не упираться в то что нам запрещают, есть много что нам дают.

Общее стремление развитого мира повышать производительность труда быстрее повышения размера зарплат.

Наглядно на любителях ассемблера, вопрос: А чего в машинных кодах то не фигачим? Зачем нам компиляторы и прочая байда? Почему ушли от машинных кодов в мнемонику?
Ответ легче читать и понятнее что написал, правильно? То есть легче находить ошибки, и код становиться качественнее.

Дальше пошли языки классом выше, мы потеряли возможность четко управлять в какой из регистров кладутся данные, зато появилась возможности делать циклы 1 записью а не несколькими проверками и не надо следить за тем какие регистры заняты.

Дальше ООП, создание объектов и методов доступа. Тем самым мы потеряли возможность управлять потрохами модуля напрямую, а только через методы.
Зато новое повышение качества, пример:
Представьте себе модуль который отображает текст и считает его длину? Метод добавления текста в него сам изменяет счетчик длинны, в итоге вы просто кидаете текст, и не можете забыть обновить счетчик. И никогда текст и его длинна не разойдутся.

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

С# - имеет автоматический сборщик мусора, больше не надо заботиться чтобы количество delete совпадало с количеством new - очень удобно. Много удобных типов, самописание типов. Int.Parse(....) - разбор строки в число. А как бонус идет то что программа компилируется не в машинные коды, а в промежуточный язык, в итоге программа становиться процесоро-независимым, на любом проце поднимите фреймворк, и запускай программы.

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

В этом смысле я понимаю тех кто решил работать с ассемблером на Cortex.
Почему бы и не использовать, если платформа все равно не измениться в обозримом будущем.
Ну потратит год на перенос TCP стека на ассемблер, но зато юзать его будет 10 лет, а стек будет знать как свои пять пальцев.
И что интересно, выложит его в свободный доступ и раскрутит как самый быстрый в мире.
И ведь мало кто осилит такой стек портировать, все будут покупать тех. поддержку у автора.

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

Зачем 10 лет ждать? Как только вы начнете портировать код с STM32F7 на Atmel SAM S7 (или обратно), то вас тут же проберут такие корчи, что не разогнетесь. А вроде бы один и тот же M7.

С# это условно копи пасте Java, но попозже. Сишники с двумя плюсами погнались за явовскими вкусностями типа гарбаш коллектора и тд и накатали свою решётку. TCP стек на ассемблер ну месяц от силы на М4, знаю американских перцев, которые только и пишут на асе под кортексы. Чуть дольше писать, чем на си, но такие челы имеются, и ценятся. Думаю от прикладных задач зависит.


Архитектура то да, а вот фасад с заборами и решетками у каждого свой.

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

Надо заметить что в этом случае код написанный на Ассемблере завязнет гораздо капитальнее

А я нет, во первых, асм хорош тогда, когда имея тини13 с кило флеша на борту, я делал считыватель 1wire на котором читал ключ, цифровой термодатчик, работал термостат с аналоговым задатчиком и все это передавалось по программному уарту.

На сях это бы в память не влезло, а тут еще 250 байт осталось!

На армах не вижу никакого смысла программить на асме, кроме вставок в си. Сколь вы будете программить сетевой стек типа lwip на асме, потому, что без него вы не попадете в ваши любимые облака А главное, зачем...



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

А смартфоны? А планшеты? Пополз микрософт и на другие платформы...



Откуда взялся миф что код на С всегда больше чем на Ассемблере?
Он больше когда пишут быстро и просто, но если задаться целью убиться об размер.... Не забываем опять же что есть оптимизация, которая иногда делает удивительные чудеса)

В некоторых случаях ручками можно получить код компактнее, но эти случаи очень уникальны. Например, 24-битная арифметика на AVR (из жизни).
В мелких задачах (а именно такие задачи решают "моргальщики светодиодом"), КПД можно поднять чуть ли не в разы, но в серьезных проектах С-оптимизация уделает любой asm-код начального уровня.

Помницо... лет 5 назад... мерялся с С в части подсчета md5 (Cortex-M3): взял алгоритм из описания и сбацал его на Си за пару минут. На asm пыхтел дольше и... проиграл. В итоге удалось чуть-чуть победить С, когда использовал команды групповой загрузки регистров из памяти. С учетом полного объема кода выигрыш оказался мизерным.

Вывод: asm в серьезных проектах нужно знать для чтения листингов, а не для разработки.
Кста, в avr мне до сих под проще написать на asm (не забуду войну с С, когда нужно было написать с точностью до тактов soft-UART передатчик).
Кста2, а генерацию VGA картинки (прием символов по UART и отображение их на VGA-мониторе) для cortem-m3 делал на C без единой asm-строчки.

Я смотрю развиваются несколько стандартных войн:
1) AVR vs ARM / Cortex
2) IAR vs KEIL
3) ASM vs C (как же без этого)

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

Я M7 позиционирую для работы с TFT. В своё время был знаменитый LPC2478 - сделал на нём проект. Потом появился нога в ногу LPC1788 на кортексе, так только за счёт шинной архитектуры был выигрыш процентов на 20%. Это было даже визуально видно на дисплее 4.3" 480x272x16. Поскольку в целом даже этого камня хватало для более менее приличного проекта, то думаю М7 потянет 7", естественно без всякого видео. Ну я про stm. На М4 даже и не успел с TFT поработать. Уж больно сложный проект был. Более 2-ух лет. )))

А это зависит от того какие ошибки чаще делаете.

90% времени это отладка.
Если по любому во время отладки все смотрят скомпиленный код, то не лучше ли его сразу писать на asm?
Здесь еще отягчающее обстоятельство может быть в том, что человек не использует нормальные инструменты для отладки вроде IAR или Keil-а, а сидит на голом GCC.
У того тоже могут быть серьезные причины.

Так что у каждой войны свой контекст, просто надо в нем разобраться.

Это вялое разжигание указанных войн, но неплохой вброс для следующей.

У меня больше времени уходит на архитектуру. А при хорошей архитектуре отладка занимает мизерное время. Дольше тратиться на написание стандартных тестов, проверки функциональности устройства.

Из всего этого мне ни разу не удобнее на АСМе потому что дольше, и текст хуже читаем.

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

Во время отладки я смотрю на отладочную консоль через UART.
Иногда попадаются HardFault с указанием адреса проблемной инструкции - только в этом случае и смотрю листинг, чтобы понять в какой функции рухнуло.
Уж точно не борюсь за такты и за байты.

SAM V71 Xplained Ultra Evaluation Kit



Atmel уже выпустил демо-плату для V71 (это почти как E7, только автомобильный)!
Цена $136.25 в партии из 10 шт.

Тут User Guide для нее, а тут на нее схемы, герберы и прочая документация.

Под S70 и E70 тоже обещают такого же вида платы выпустить, но пока ничего конкретного не нашла.

Но плата получилась очень симпатичная. На нее сверху, как на Arduino, можно свою самоделку водрузить, благо разъемчики для этого есть.

http://www.atmel.com/tools/ATSAMV71-XULT.aspx

Тут, наверно, ачипятка - SAM7S всё же ARMv4T, полноценный ARM

Зависит. Вот sdcc для CC2530 (8051) такой код производит, что хочется обнять и плакать..
Ну понятно, он же клепает дженерик и не пользует все его свистульки для облегчения жизни:
второй DPTR, восемь банков Rx регистров..

Но когда читаю асм код.. Не знаю, не пробовал IAR для этого..

Да, по ошибке вместо SAM S7 написала SAM7S.
Свой пост поправила.

Да пусть ползет куда хочет, но львиная доля - это псишники под виндой.

Миф берется из реальности, ибо та же самая прога, с учетом оптимизации и т.п. не влезала на 100 байт...
Мое предположение - происходила инициализация "по умолчанию" того, что мне было не нужно, си, как правило много bitbang-операций заменяет на код "прочитал-изменил-записал", когда нативно это делается 1 командой, ну и вход-выход в прерывания, как правило сохраняет больше регистров, а на асме можно сэкономить, выделив регистры в "глобальное" использование, без сохранения...




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

Для всего остального есть консоль, либо жк-индикатор, или экран.

За такты и байты не борюсь, но если есть возможность сделать код оптимальнее - не отказываюсь.




Слабоваты они для дисплеев, разве, что только в качестве более расширенных жк-индикаторов. Чтоб был нормальный дисплей и на нем не было слайд-шоу, нужно по крайней мере ддр2или3 и какой-либо апп. ускоритель.



Каждое для своей категории:
1) авр для мелких задач, арм для задач быстродействия, сети, дисплеев
2) на любителя, я выбрал иар, т.к. считаю, что у него более путная иде и неплохой компилятор.
3) си уже дефакто везде, на чистом асме "ваяют" только маньяки...



Ну если сам делал это на меге128, на асме правда, то уж кортекс-то с этим на раз-два справится

Хорошие RTOS-ы (MQX) имеют спец опции для управления объемом сохраняемого контекста.



Не забываем про поддержку очень старого оборудования.
Например в RTOS NuttX штатно идет эмулятор команд Z80.
Вот эмуляция всяких зайлогов тоже интересная тема для M7.

А причем здесь ртос?? Это задача компилятора...

"Не забываем про поддержку очень старого оборудования. " - можно тупой вопрос, все-таки зачем это ?? В те времена и на тех процах писалось довольно примитивное по нынешним меркам ПО, зачем его "гонять" на новых процах в эмуляторах?? Проще переписать заново, даже, если нет исходников. Сам так делал, когда переписывал ЧПУшки с 80186 на СТМ32.

Только что на сайте Atmel появился интереснейший документик:
Migrating from the SAM4E to SAM E70 Microcontroller

А интересен он тем, что очень наглядно демонстрирует отличия M7 (SAM E70) от своего предшественика M4 (SAM4E), с которым они совместимы по цоколевке. Т.е. с упором на то, чтобы проапгрейдить платы, ранее уже разработанные для SAM4E, новым контроллером. А что для этого надо поправить в программе, как раз и сообщается в этом документе.

P.S. Впрочем, кое-какие минорные различия в назначении выводов я в этом документе уже углядела, но сходу не соображу, мешает это замене один в один, или же потребует каких-то изменений в монтаже. Тогда как ранее компания обещала, что такая замена будет возможна.

Нет. Я не указал свою позицию в этих войнах.

простите не задумался об этом ...

Я поддерживаю.
Пишу медленно. Долго осмысливаю - строю приложение. Опыт позволяет, поэтому осмысливаю и предусматриваю почти всё. Пишу определённым образом. Я называю это кубиками. В принципе подсмотрел на ПЛК. (Писал пару крупных линий на сименсе). При разработке архитектуры, главное - архитектура данных, а не программ. Обмен осуществляю через данные. Так пишу даже если нет РТОС.
К сожалению, на крупных проектах не удаётся полностью идеально выстроить архитектуру. Устранение ошибок такого рода приводит к переписыванию "базового функционала", а это ведёт к значительному объёму тестирования.
Тестирование занимает очень большое время. Я его перепоручаю другим людям ... ))))
Ошибок делаю очень мало и их устранение занимает небольшое время. Как правило ничего не задевает, если это не ошибки архитектуры, о которых писал выше. Тогда наоборот - задевает значительную часть. Для меня это чп. ))
То есть всё примерно тоже что и у Вас. ))

Я думаю, что счастья ждать не стоит:
Table 3-3. LQFP100 Pinout Differences
Pin SAM4E__ SAM E70
39_ PD23___ VDDCORE
76_ PD29___ VDDCORE
81_ PA6____ VDDIO
86_ VDDCORE VDDPLL
90_ PA29___ VDDPLLUSB
93_ VDDIO__ VDDUTMII
94_ PB10___ HSDM
95_ PB11___ HSDP
96_ VDDPLL_ VDDUTMIC
97_ PB14___ VBG

Часть PIO занята под питание...

Обратил внимание, что bitbanding порезали благополучно ... ))
Привет всем которые пользуются "расширенными возможностями" камней. В очередной раз...
Я вроде как тоже хотел, потом решил не заморачиваться.