На работе собираются взяться за камни на Cortex-M0 (от "Миландр"). Cortex-M3 изучил и суть уже понимаю. Расскажите, пожалуйста, чем отличается M3 и M0?
И еще - если кто имел дело с миландровскими камнями, на какие проблемы натыкались?

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

Это заметил делая один проект на M0 (LPC1114), M3 (STM32) пока в процессе изучения.

Потреблением ещё вроде как должен отличаться. В меньшую сторону.

А механзм прерываний отличается?
И еще где-то видел, что у него есть DSP, работал ли с ними кто-нибудь?

Вроде бы нет.
Вот еще одно отличие нашел - М3 допускает невыровненный доступ, М0 - нет.

Не могли бы Вы предоставить цифры.
Я как-то сравнивал Мо и М3 для своих проектов и заметил разницу в коде только на несколько процентов. (меньше 10 однозначно)
Оптимизация даёт эффекты большие. Или смена компилятора.

А разве не все кортексы допускают невыровненный доступ?

Специально я не сравнивал. Это субъективное впечатление. Когда писал переключатель контекста для scmRTOS под М0 обнаружил, что нет множества команд, которые приходится заменять несколькими другими. Также у части команд есть дополнительные, по сравнению с М3, ограничения на операнды, из-за чего опять же приходится использовать несколько других команд вместо одной из системы команд М3.

Сравнить могу переключатель контекста scmRTOS (рукописный ассемблерный кусочек): М0 = 56 байт, М3 - 32 байта. Разница 42%.

Хотя... могу сравнить и весь проект.
Откомпилил весть проект с ключами -mcpu=cortex-m0 и -mcpu=cortex-m3. Размер кода для М0 = 14688, для М3 = 14952. "Ниччччего не пониимаю". Начал изучать map. Разница в системных библиотеках. Из них подтягиваются memcpy, memset, strcmp, strcpy, strlen, strupr. Они в сумме занимают для M0 378 байт, для M3 - 1088 байт. Самая большая разница в strcmp - 20 и 476 байт. Сам код из моих исходников занимает 13848 для М0 и 13580 для М3. Действительно, разница небольшая - в районе двух процентов. К ней можно добавить еще библиотечные функции программного деления (156 байт) - М0 не имеет команд деления.

Мельком глянул дизассемблер strcmp - похоже, они собирались из разных исходников. Значит для корректности сравнения их нужно исключить. В результате получаем пусть на 2...4%, но все же больший код для М0.
Компилятор - гцц, сборка Yagarto 20110328.
Оказывается - нет.
Из LPC111x/11Cxx user manual:P.S. а я раньше думал, что наоборот, все ARMы не допускают. M3 приятно удивил.

Ну, это было очевидно. М3 грубо на 98% имеет те же команды, что и М0, плюс 2% новых. Имеется ввиду не мнемоники команд.

Кстати, LPC2xxx (ARM7) всегда допускал невыровненный доступ. Хотя читал не то, что вероятно ожидал "писатель".

Cortex-M0 -- это архитектура ARMv6-M, имеющая только систему команд Thumb, а Cortex-M3 (как и -М4) -- это архитектура ARMv7-M, у которой используется Thumb-2. Последняя по своим функциональным возможностям почти соответствует "родной" АРМовской (которая у Cortex-M отсутствует вообще). В частности, любые операции могут выполняться с почти любыми регистрами, в то время как в Thumb свободно можно использовать лишь R0-R7, а остальные -- лишь в нескольких командах. Результат этого ограничения сильно зависит от компилятора. GCC, например, очень плохо следит за регистрами, из-за чего ему их всегда не хватает, и код прилично раздувается лишними сохранениями-восстановлениями в стеке, что приводит ещё и к тормозам (иногда -- очень приличным; у меня знакомый с этим столкнулся на LPC2478: при компиляции в код Thumb скорость падала в несколько раз по сравнению с кодом ARM, поскольку начинались сплошные обращения к стеку, который находился во внешней памяти вместе с видеобуфером -- ну, процессор и вынужден был стоять, когда к памяти обращался дисплейный контроллер; при коде ARM, в котором свободно использовались все регистры, число сохранений-восстановлений в стеке резко уменьшилось).

Реализация обработки прерываний одинакова, разница лишь количественная (большее число линий и т.п. у Cortex-M3). Правда, насколько помню, в ARMv7-M при возврате из прерывания выполняются дополнительные проверки, в то время как ARMv6-M игнорирует некоторые ошибки, из-за чего некий код, работающий на Cortex-M0, может оказаться неработоспособным на Cortex-M3 (другое дело, что этот код изначально является неправильным).

И это всё? А если сравнить детали?
Тумба 1 является 16-битной системой команд полностью. Почти все дополнительные команды в Тумбе-2 являются 32-битными. Особенно те, которые обращяются к верхним регистрам. А это очевидно значит, что на Тумбе-1 можно поставить 2 команды и иметь тот же размер кода, что и в Тумбе-2. Если Тумба-2 выполняет даже 32-битную команду за такт, то это конечно бонус в скорости выполнения. Но размер кода у них всё равно почти одинаковый.

Да, размер основной массы дополнительных команд у Тубмы-2 составляет 32 бита. Насчёт скорости выполнения не уверен, но не вижу принципиальных проблем для исполнения их за один такт; единственное, что может служить реальным тормозом, -- это скорость выборки кодов команд из памяти и поступления их в процессор. В общем, тут надо вчитываться в описания конкретных ядер.

Однако насчёт размера кода Вы неправы. Одну причину я уже указал: не всякий компилятор умеет извернуться с ограниченным числом регистров, а значит, начинает плодить дополнительные команды, нужные лишь для сохранения-восстановления значений и не выполняющие полезной работы как таковой. Другая причина -- очень ограниченный набор операций в просто Тумбе. Например, там нет логических операций между регистром и константой, почему константу приходится сначала загружать в другой регистр (а число доступных регистров, как мы помним, тоже меньше, чем в Тумбе-2 -- и в результате часто нужно сначала сохранить старое содержимое этого регистра). Выбор самих констант тоже более ограничен: они должны полностью вписываться в один байт, т.е. находиться в диапазоне от 0 до 0xFF включительно; любые другие константы либо требуют использования нескольких команд, либо применения команды LDR и размещения самой константы как слова памяти). Тумба-2, конечно, не позволяет грузить любую константу одной командой (ну, кроме команды LDR, но это уже, по сути, является считыванием значения переменной, а не загрузкой константы как таковой), но выбор допустимых значений существенно больше, чем у Тумбы. Возможность использования трёхадресных арифметико-логических операций тоже иногда весьма полезна. В общем, Тумба-2 позволяет существенно сократить размер кода по сравнению с просто Тумбой, и прилично поднять производительность, если процессор и память способны обеспечить выполнение одной 32-разрядной команды за такт. Но, понятно, достигается всё это только в том случае, если возможности Тумбы-2 используются грамотно. Как обстоит с последним дело на практике -- это уже другой вопрос, не относящийся напрямик к достоинствам/недостаткам архитектуры.

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