LPC122x это Cortex-M0 или M0+? Опции

[GetSmart]

LPC122x это Cortex-M0 или M0+?
Вопрос к специалистам.
Растактовка инструкций у него отличается от M0 (LPC11Xxx, LPC43xx_M0).

Каким способом программно/аппаратно можно определить тип ядра? Если набор инструкций у них одинаковый.

[zltigo]

Обычный. Производительность указана, как для M0. Да и скрывать-то плюс было к чему? Для LPC800,11E0,11U0 прямо указаны варианты plus.

[megajohn]

Каким способом программно/аппаратно можно определить тип ядра?

в NXP есть регистр CPUID
[31:24] Implementer Implementer code: 0x41 = ARM
[23:20] Variant Variant number, the r value in the rnpn product revision identifier: 0x0 = Revision 0
[19:16] Constant Constant that defines the architecture of the processor:, reads as 0xC = ARMv6-M architecture
[15:4] Partno Part number of the processor: 0xC20 = Cortex-M0
[3:0] Revision Revision number, the p value in the rnpn product revision identifier: 0x0 = Patch 0

для Cortex-M0+ Partno Part number of the processor 0xC60

[GetSmart]

Если это M0, то в отличие от всех остальных M0 у LPC122x в юзер мануале есть предложение:

The LPC122x have a high score of over 45 in CoreMark CPU performance benchmark testing, equivalent to 1.51/MHz

Что это значит? CoreMark, судя по названию, тестирует ядро.

[zltigo]

Что это значит? CoreMark, судя по названию, тестирует ядро.

Попугаи производительности на мегагерц. У M0+ их 2.42 по заявлению ARM.

[esaulenka]

... а у M0-не-плюс - 2.33 по тем же заявлениям (ссылка, оригинал сходу не нашёл).

Видимо, ARM рассматривала сферический процессор в вакууме, с бесконечно быстрой шиной. Одно слово - попугаи...

PS посмотреть на попугаи других процессоров можно здесь (кнопка "search")

[ViKo]

По-моему, в M0+ потребление уменьшали, а не производительность увеличивали.
У STM на CoreMark можно взглянуть здесь: http://www.st.com/st-web-ui/active/en/cata...mc/FM141/SC1169
И, да, по ссылке из предыдущего сообщения нам лучше глядеть в табличку Most Recent. А еще лучше Search.

[zltigo]

... а у M0-не-плюс - 2.33 по тем же заявлениям (ссылка, оригинал сходу не нашёл).

А вот так сказать "оригинал" http://www.nxp.com/documents/data_sheet/LPC122X.pdf

По-моему, в M0+ потребление уменьшали, а не производительность увеличивали.

Это на самом деле одно и то же - при большей производительности можно снизить тактовую или больше спать.

[ViKo]

Это на самом деле одно и то же - при большей производительности можно снизить тактовую или больше спать.

На самом деле это не так. Там уделялось повышенное внимание тому, чтобы ненужные элементы не молотили тактовой частотой.
http://www.arm.com/products/processors/cor...rtex-m0plus.php

[zltigo]

На самом деле это не так.

К чему Вы пытаетесь отрицать очевидную вещь, что повышение производительности НЕ за счет повышения тактовой поводит и к экономмии энергии? Это совершенно НЕ означает, что другие меры не предринимались, но возможность полуторократного понижения тактовой при той-же производительности, это ОЧЕНЬ существенная экономия.

[ViKo]

К чему Вы пытаетесь отрицать очевидную вещь...

К тому, что главной целью было снижение энергопотребления. А остальное - средства достижения цели. Не думаю, что если взять CM4 (CM7) и заставить его дрыхнуть, и лишь иногда вскакивать и в бешеном темпе что-то делать, то он переплюнет CM0+ по энергоэффективности.
Да, там что-то про двухступенчатый конвейер говорится. Ну, улучшили и производительность, спасибо.
Кому нужен производительный процессор, тот найдет, что взять. А кто ищет малопотребляющий, чешет репу, чем заменить MSP430, вот ему ARM сделали подарок CM0+!

[zltigo]

Не думаю, что если взять CM4 (CM7) и заставить его дрыхнуть...

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

[ViKo]

Вы таки желаете, в свойственной вам манере, оставить последнее слово за собой? Мы о чем-то спорим? О чем, конкретно?
Смотреть на производительность в единицах CoreMark или MIPS при выборе процессора CM0 или CM0+ - это надо редким педантом быть. Работает, и ладно. Вот на тактовую частоту глянул, "ага, 48 МГц, не слабо, пойдет", и достаточно.

[zltigo]

Вы таки желаете, в свойственной вам манере, оставить последнее слово за собой? Мы о чем-то спорим? О чем, конкретно?

О чем Вы "спорите" мне неведомо. Я только указал на то, что здесь http://electronix.ru/forum/index.php?showt...t&p=1377925 Вы ляпнули ерунду.

[adnega]

А кто ищет малопотребляющий, чешет репу, чем заменить MSP430, вот ему ARM сделали подарок CM0+!

Не знаю как там у CM0+, а у STM32L4xx в "Shutdown mode" потребление всего 30 нА.
У MSP430 порядка 100 нА (правда с "RAM Retention").

[GetSmart]

Энергопотребление это характеристика софтом не прощупываемая. Зависит и от техпроцесса. А на уровне софта эти ядра отличаются точно.

Сравнил в реале LPC1227 rev A и LPC812.
1. У LPC812 переходы на такт короче (2 вместо 3). И нет зависимости STR/STM от нечётного адреса инструкции в RAM, равно как и у LPC1227.
2. У LPC812 есть однотактовая GPIO. LPC1227 падает в исключение при чтении этой области.
3. У LPC812 есть VTOR и отличаются CPUID.

Самое серьёзное отличие - первое. Последнее - самое косвенное по отношению к ядру.

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

Сообщение отредактировал GetSmart - Nov 4 2015, 11:04

[zltigo]

Не знаю как там у CM0+, а у STM32L4xx в "Shutdown mode" потребление всего 30 нА.
У MSP430 порядка 100 нА (правда с "RAM Retention").

То, что есть у MSP430 и чего нет у массы всяких декларируемых как супер-пупер-пико-нано потребляющих ядер, это ориентированой на микропотребление пеерферии способной работатать и автомномно, напимер по DMA. MSP очень сбалансированный контроллер ИЗНАЧАЛЬНО.
Ну и дальше процедура просыпания у многих "рекордсменов" зачастую очень громоздка по времени и соответственно по энергии

[GetSmart]

Факта экономии энергии за счет полуторократного повышения производительности при той-же тактовой это не изменит.

В каких последовательностях инструкций это проявляется? Когда вся прога из переходов (B | Bxx) и когда они вперемешку с вводом/выводом в GPIO ? Какая-то среднестатистическая программа без учёта ногодрыга хоть на 5% будет быстрее? Без сна конечно же.

[zltigo]

В каких последовательностях инструкций это проявляется?

Как минимум в тех, которые используются в тесте. Тест попугаев при всей его попугаистости, писался не с бодуна и на основе опыта предшественника Dhrystone. Исходники теста доступны для изучения http://www.eembc.org/coremark/download.php . Можете лично откомпилировать и сравнить.
Если у Вас вырожденные случаи типа 99% ногодрыжества, то это не проблемы теста.

[GetSmart]

Если у Вас вырожденные случаи типа 99% ногодрыжества, то это не проблемы теста.

Наоборот. При 99-процентном ногодрыжестве вопросов не возникает. У M0 большинство инструкций 1-тактовые и ускорить без суперскалярности их невозможно. STR/LDR & STM/LDM на M0+ грубо такой же длительностью как в M0, если только не пишут в fastest GPIO (регион 0xa000xxxx). То есть общая растактовка в применении к 90% существующего кода - ТАКАЯ ЖЕ как и у M0. Откуда 50% и где факт?

Или неописанная особенность M0 STR/STM на нечётных по маске 0x02 адресах RAM тоже "прогибает" (участвует в учёте) относительное ускорение M0+ ? Среднестатистически таких инструкций много в среднестатистическом коде. Но 99% кода обычно исполняется из флэш.

Факта экономии энергии за счет полуторократного повышения производительности при той-же тактовой это не изменит.

Этот факт убежал вперёд паровоза. Сперва надо доказать факт "полуторократного повышения производительности". И обозначить прицеп оговорок.

Сообщение отредактировал GetSmart - Nov 4 2015, 16:20

[ViKo]

О чем Вы "спорите" мне неведомо. Я только указал на то, что здесь http://electronix.ru/forum/index.php?showt...t&p=1377925 Вы ляпнули ерунду.

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

[zltigo]

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

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

Этот факт убежал вперёд паровоза. Сперва надо доказать факт "полуторократного повышения производительности". И обозначить прицеп оговорок.

С этим Вам жаловаться во всемирную лигу сексупльных реформ на компанию ARM, которая официально выдала эти цифры по результатам совершенно конкретных ПРИЗНАННЫХ (не Вами, конечно ) и ОТКРЫТЫХ для изучения тестов производительности.

[ViKo]

zltigo, специально для вас с сайта ARM.
Performance Efficiency

CM0 2.33 CoreMarks/MHz
CM0+ 2.46 CoreMarks/MHz

По-вашему, это в 1,5 раза? Посчитаю для вас: 1,056...
Найдете сами на сайте.
Так что ваше "прямое изложение" тоже слегка хромает.

Двухтактовый конвейер означает, что больше операций будет сделано за такт. Следовательно, нельзя будет поднять тактовую частоту до уровня трехтактового конвейера. То есть, он хорош для низкопроизводительных устройств. Между прочим, у CM7 конвейер 6-тактовый.

[zltigo]

CM0 2.33 CoreMarks/MHz
CM0+ 2.46 CoreMarks/MHz

По-вашему, это в 1,5 раза?
Найдете сами на сайте.

В данных NXP для 0 было 1.51. Ссылку давал.

Так что ваше "прямое изложение" тоже слегка хромает.

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

Это на самом деле одно и то же sm.gif - при большей производительности можно снизить тактовую или больше спать.
...
повышение производительности НЕ за счет повышения тактовой поводит и к экономмии энергии

Где Вам привидились хоть какие-то цифры?

[ViKo]

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

Вы вели? Оставлю без комментариев.

[zltigo]

Вы вели?

Да.

[GetSmart]

В NXP чистокровным (и одноядерным) кортексам-M0 была присуща особенность - наличие только одного UART-а. У LPC81x их 3. А в LPC11U6x их 4. Других одноядерных M0+ от NXP пока не знаю.

LPC122x имеет два UART-а. + Загадочную строчку о CoreMark. + Отличающуюся от всех официальных ядер растактовку.

Всё-таки интересен вопрос, никто не встречал в описаниях от ARM или где-то в исходниках что-то похожее на код платформы x86, определяющий тип/возможности процессора, на котором код исполняется?

Сообщение отредактировал GetSmart - Nov 4 2015, 11:14

[jcxz]

Всё-таки интересен вопрос, никто не встречал в описаниях от ARM или где-то в исходниках что-то похожее на код платформы x86, определяющий тип/возможности процессора, на котором код исполняется?

В M0 есть Usage-fault? Не работал с ними. Если есть - делаете обработчик этого исключения и пробуете выполнять команды поддерживаемые во всё более и более старших ядрах,
пока не поймаете соответствующее исключение. Так сможете сориентироваться где вы находитесь внутри линейки Cortex-M.

[ViKo]

В M0 есть Usage-fault? Не работал с ними. Если есть - делаете обработчик этого исключения и пробуете выполнять команды поддерживаемые во всё более и более старших ядрах,
пока не поймаете соответствующее исключение. Так сможете сориентироваться где вы находитесь внутри линейки Cortex-M.

ARM сообщает, что набор команд у CM0 и CM0+ одинаковый.
Неужели производитель микроконтроллера не выдает информацию, на каком ядре тот сделан?

[smalcom]

Неужели производитель микроконтроллера не выдает информацию, на каком ядре тот сделан?

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

LPC122x это Cortex-M0 или M0+?

А ещё любят потрындеть, что трындят другие, потому сразу укажу, что говорит нам производитель сиих МК:
LPC122x - M0
LPC43xx - M4F + M0
LPC11U6/LPC11E6 - M0+, остальные - M0.

[GetSmart]

По поводу "чистокровности" стартовых/большинства процессоров NXP M0 может быть погорячился. Т.к. требуется проверка у других производителей. Может эта фича самого производителя - NXP.

Ещё одно отличие в растактовке M0 и M0+, кроме переходов, существует - команды MSR/MRS, которые, что очень хорошо, не связаны с обращением к шинам. В LPC122x MSR/MRS = 4 тактам. В LPC81x MSR/MRS = 3 тактам. Т.о. LPC122x = M0 без плюса.

В M0 есть Usage-fault? Не работал с ними. Если есть - делаете обработчик этого исключения и пробуете выполнять команды поддерживаемые во всё более и более старших ядрах, пока не поймаете соответствующее исключение. Так сможете сориентироваться где вы находитесь внутри линейки Cortex-M.

Вопрос не тот задал. Цель была защитить какой-то асм-исходник от изменений растактовки инструкций, например ARMv6-M для M0. Гипотетически, даже в новой ревизии камня. При этом классифицировать ядро по терминологии ARM будет даже лишним. И ответ скорее всего очевиден - написать измерялку растактовки под свои требования. Т.к. кроме ядер от ARM могут быть ещё фичи производителей.

что говорит нам производитель сиих МК:

Цель темы - объяснить отличие обозначенных отличий растактовок процессоров с ядрами M0 производителя NXP. А так же, отличие от "официальных" растактовок ARM. Это работа посложнее чтения. Так же встречал опечатку, которая по этой причине попала в название этой темы.

Сообщение отредактировал GetSmart - Nov 5 2015, 17:07

[adnega]

Цель была защитить какой-то асм-исходник от изменений растактовки инструкций

Накой? Есть кусок, выполняющийся за 100 тактов. На новом камне он выполняется за 110 тактов.
Как вы сможете защититься от этого и вернуть былые 100 тактов?
Добить и там, и там пустышками до 120 тактов? Сомнительный выход.

[GetSmart]

Накой? Есть кусок, выполняющийся за 100 тактов. На новом камне он выполняется за 110 тактов.

Защита, если таковая нужна, заключается в блокировке работы устройства, "наблюдаемая невооружённым взглядом". Или части его алгоритма. Но можно сделать несколько ветвей одного алгоритма, если допускается работа на нескольких отличающихся камнях. Выбираемых по результатам измерялки. Последний вариант чисто гипотетический. По мотивам x86. Практической пользы в ARM в нём пока сам не вижу.

Сообщение отредактировал GetSmart - Nov 5 2015, 17:15

[megajohn]

если допускается работа на нескольких отличающихся камнях. Выбираемых по результатам измерялки

б-р-р-р, вообще то в NXP/LPC программно можно узнать не только тип ядра, но и тип контроллера и сколько Flash на борту
Device ID register и Read Part Identification number