AVR32? Опции

[SpiritDance]

Ну и что об этом думает уважаемый all?

http://www.atmel.com/dyn/corporate/view_de...short_2_14.html

http://www.atmel.com/products/AVR32/

400 мгц однако. Интересно теперь реальное потребление, корпуса, возможности отладки и цены. Вот вам и АРМ9 блин.

[Evgeny_CD]

Заметим, что Philips один из центровых акционеров ARM (долю точно не знаю). Возможно, этим "финт ушами" с LPC2101 и объясняется.

AVR уже давно не по 0.35 делаются. Последние - 0.18 точно.

Спор AVR <-> ARM идет из покон веков. Нету тут победителя. Это разные процы.

ARM как архитектура не идеален - это все знают. В AVR32 предпринята попытка выправить кривизну. Опять же, если атмел не будет дурковать - все у него получится.

Что касается нас с Вами - писать надо на C, почаще справочники хорошие по языку читать. Писать переносимо, не затачиваясь на Keil, RVDS и пр. Чтобы в ядре plain C был, ну а всякие __flash макросами (можно не обломиться и свой препроцессор на Python или Tcl написать - не так уж и сложно).

Разбивать код на модули. Не то, чтобы под ОС сразу писать - но оно должно быть готово для "нанизывания" на каркас ОС. ASM вставки - только в крайних случаях, отдельными модулями, чтобы опять же легче портировать было.

Аккуратно с типами данных. В ядре - никаких стандартных типов, все через #define. Указатели аккуратно преобразовывать, чтобы на ошибку выравнивания не налететь.

Изначально писать по стандартам Doxygen. Чтобы потом легче в коде разбираться было. Программеров лишать ЗП за непонятный и недокументированный код.

Почаще смотреть в диаграммы связей, которые Doxygen генерит. Можно еще Understand C++ юзать - тоже клевая вещь.

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

CVS или SVN юзать. Один раз разобраться - и кайф на всю жизнь.

И вооще осознать, что ЛЮБОЙ проект, даже контроллер светодиода, начинается с продумывания идеологии. И вместо дурацких споров AVR<->ARM<->PIC<->куча всего другого или, что еще глупее, KEIL<->RVDS<->IAR<->GCC просто берется и пишется plain C код, состоящий из одних заглушек. Затем анализируются связи, залушки заполняются целевым кодом. Все этого гоняется на симуляторе, написанном на том же С, или, что приятнее, Python. Отдебугеренный код надстраивается "железными" модулями - и он готов к впихиванию в любой процессор подходящей производительности, который нашелся в ящике стола. Железные модули дебугерятся отдельно от основного кода в целевом железе.

Весь процесс отладки целевого софта можно проводить в любой среде, главное, чтобы ANSI C поддерживался. Какая есть под рукой, какую программер знает - ту и юзать. При наличии такой возможности осваивать программизм под Linux. Там такая отладка идет куда проще и приятнее.

Что касется JTAG - не надо микроскопом гвозди заколачивать. Это:
* неудобно
* дорого

Да, есть ситуации, когда без JTAG - никуда. Но вот когда plain C цифровой фильтр или декодер DTMF через JTAG отлаживают в целевом железе - за это надо ЗП лишать.

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

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

Собственно, я написал это по одной простой причне - не о том спорим. При правильном подходе процессор безразличен. И правы те, кто говорит - недели для осовение новой архитектуры хватит, если не стоит задача выжать 101% производительности. Просто нужно чуть расширить границы мышления - и мир вокруг заиграет новыми красками! Но увы, это в учебниказ не написано.

[defunct]

....
Собственно, я написал это по одной простой причне - не о том спорим. При правильном подходе процессор безразличен. И правы те, кто говорит - недели для осовение новой архитектуры хватит, если не стоит задача выжать 101% производительности. Просто нужно чуть расширить границы мышления - и мир вокруг заиграет новыми красками! Но увы, это в учебниказ не написано.

Спасибо, честно скажу - проникся Вашим постом ;>
и полностью поддерживаю все вышесказанное, кроме... последнего абзаца, с которым я категорически не согласен. То, про что вы пишете выше, нельзя назвать освоением архитектуры. Вы пишете про освоение языка программирования и освоение принципов построения кроссплатформенных программ (грубо говоря Вы поясняете как надо писать программы, чтобы не зависеть от архитектуры)... Соответственно раз мы говорим о разных вещах - в споре нет и не может быть ни правых, ни левых. Те, кто поддерживает мнение, что архитектуру можно освоить за неделю - скорее всего должны более честно заявить, что архитектуру как таковую осваивать не нужно вообще. Достаточно просто писать кроссплатформенный код. Вот тогда все станет на свои места.

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