Дышите спокойно, индусы НЕ погубят мир. Ничего там такого, ембедед джав было ранее много, мало кто прижился массово. Хотя идея у них правильная, но мало кому нравится спрыгивать с C/C++ и похоже ембедед джаву не поддерживают финансово.

Я как-то не волнуюсь. Просто по работе приходится сталкиваться с их поделиями. Все очень узнаваемо. Использовать проц с такими возможностями для всякой херни - верх идиотизма.

Ну это неверно в корне. Поскольку всё нынче определено рынками. Если много запросов от клиентов, то почему бы и нет? Все же там не лампу включают, а показан элемент умного дома. А тема вообщем востребована. Да и причем тут индусы? Китайцев все же больше.

ерунда, даже дотнет давно уже на более слабых работает

Херни (т.е. самой Java) там кстати очень мало.
А оcновной объем занимает middleware. И там вполне стандартный набор: TCP c IoT протоколами и SSL , FS, GUI и некий HAL к периферии.
Ровно то же самое предлагают такие проекты как mbed.org , MQX и прочие.
А поставить сверху скриптовый движок плёвое дело.

Но именно такой состав middleware это уже закон. Без этого набора в IoT нечего делать.

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



Да пох.. мне что надо клиентам. Маркетологи придумывают "незаменимые вещи' и впаривают их потребителям. Фирмы их разрабатывают, и на выходе получается вот такя хрень - выключатель лампочки. Об - этом речь. А джава на таком проце - "вау -анальный эффект". Не более.

KostyantynT вы правила форума давно читали? ... чтоб так не в тему писать?

Ок, не по** , а равнодушен. Смысл поменялся?
А по теме - заказал его себе. Хочу попробоваь на интересных DSP задачах. К сожалению - инфы по производительности ноль. Посмотрел по теме прцессора - тоже ничего особенного, бла-бла. Почему бы не обсудить?

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

Вас же не заставляют именно так действовать....

Прошу всех участников дискуссии не отклоняться от темы Cortex-M7
Модератор.

Присоединяюсь к модератору. Как по мне сравнивать CM7 и A7/A9 это не то, что жигули и форд, а, скорее, легковой и грузовик. Чаще всего это абсолютно разные ниши. Это без разницы что цена сопоставимая. Цена приобретения и цена применения совершенно разная. Мне необходимо применить флэшку, озу, плату многослойку. Необходимо использовать другое ПО, необходимо ОС (как правило) другую применить ну и так далее. Мне это абсолютно ненужно в моих проектах.
Поэтому рекомендую завести новую тему и там обсуждать разные камни в основном заточенные под linux.

И ещё один момент. Хотелось бы не обобщать по национальному признаку. Индусы, китайцы и так далее... Те кто чувствуют своё превосходство - пусть докажут его на деле!!! Не в стенах конторы с годовым оборотом в 1 лимон $ и 25 сотрудниками, а явят миру свои тексты, изделия, которыми мы все могли бы гордится. Пока, к сожалению, качество отечественной техники, и в особенности электроники, сопоставимо скорее с китайской, чем, с немецкой.

SasaVitebsk

Ещё не многие поняли, что Cortex-M7 стирает грань между А8/9 и ногодрыгалками. Теперь "настоящий" процессор сам затисался в ногодрыгалки. Дело за малым, осталось только поднять частоту. И скоро она поднимется. Вот и всё..

Cortex-M7 просто следующий этап эволюции аврок и пиков на новый, более быстрый, навороченный и, конечно, более сложный для разработчика уровень. С серией Ах его сравнивать некорректно, т.к. эти процы заточены под графику и мультимедиа, а Мх - на управляющий низкий уровень. Конечно, было бы круто, если иметь "под рукой" сочетание этих процов, типа вибрида, но с полнофункциональным процом типа mx6d и M7 от stm с его широкой периферией...

Почему же ST тогда так ломится сделать графические всякие акселераторы и контроллеры дисплеев в своих STM-ах?
Сравнивать все можно.

Может они гребут друг к другу.
Был набор команд АРМ и Тхумб, потом стал Тхумб2 и из кортексов набор АРМ вообще выкинули. Систему прерываний АРМ7 заменил NVIC который теперь в ядре и поудобнее чем эти медленные и быстрые прерывания....

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

Это как желать на АРМ7 получить NVIC, хотя фактически это станет кортексом, так чего бы его тянуть, а не бросить? И пусть ядро по функционалу будет завышено для задачи, но в производстве иметь 1 ядро может быть выгоднее чем иметь несколько тех процессов и шаблонов пусть и более дешевых...

Нет. Эволюции "аврок и пиков" никакой нет. Они просто вымерли, не как динозавры, ибо в зоопарках еще живут, но вымерли.

Это, увы, слова пико-аврщика который просто жутко боится даже ознакомится с чем-то другим. Для разработчика мелкие армы МНОГО проще. Проще и ядро без разных вульгарных ограничений, проще в ИСПОЛЬЗОВАНИИ и переферия, по причине меньших ограничений и большей аппаратной функциональности.




Набор ARM обладает своей перелестью и добротными фичами. Просто надо понимать, что есть и МЕЛКИЕ контроллеры в которых каждый цент на счету.

А вот это для ПЛОТНОЙ работы с железом - фигово. Но для массового "программиста" сие благо - все однообразненько, вложенннько... В общем - ПРОСТО не думая использовать, вопреки опять-же утверждению mantech.

Замечу, что это не акселератор 2D графики... Это слегка доработаный DMA контроллер даже без необходимой для 2D акселератора функции преобразования растрового black&whitre битмапа в цветной (функция крайне нужная при выводе текста).
Ещё более "правильные" 2D имеют функцию аппаратного ограничения окна при построении графики (требуется для ускорения отрисовки окон с перекрытием а-ля windows).

Сложнее, конечно. Даже если судить просто по объёму соответствующей технической документации. Конечно, это барьер для входа, особенно для пугливых. Ну и пугливые, конечно, ограничивают доступный им инструментарий, и, следовательно, круг доступных для решения задач.
Если честно, когда я увидел структуру шинных коммутаторов STM32F7, слегка ужаснулся. Потом пригляделся и понял, что на самом деле всё должно работать "из коробки", а присматриваться нужно будет тогда, когда понадобиться выжать все возможности из этого МК.

Ну это вообще-то не есть родимое пятно ARM-ов, просто ST так сделали. И на самом деле это ведь многое УПРОЩАЕТ в реальной работе! Ну и "из коробки", как Вы сказали, тоже работать можно.

Чем NVIC хуже? На нем можно с легкостью симулировать режим прерываний ARM7, просто там было фактически 2 приоритета и вложенности, а тут гораздо больше с настраиваемой вложенностью. Я чего-то не учитываю?


ну как я понимаю в Тхумб2 фичи остались, усложнился парсер команд, который раньше брал слово и все, а теперь ему надо крутить 16 или 32 бита. Но зато 128 бит шины флеш хватает на выбор не 4, а уже 8 команд, как следствие для 20 МГц флеши проц в 100-120 МГц может работать без пауз. И это гораздо важнее по мне, чем то что в память больше команд влезает.

Как и любое улучшение и тем более любая эмуляция, эта "легкость" чего-то стоит. В данном случае тактов. Fast IRQ работающий в своем стеке вещь отличная. А, например, те-же вложенности перрываний, при нормальном построении системы, вещь совсем не нужная. А если и нужная, то организуемая руками. Так-что "кортексовский" контроллер прерываний это вещь более, чем компромиссная в угоду простоте и бездумности использования.

Дык, мил человек, команда команде рознь. Из того, что порезали формат команды и команд стало требоваться БОЛЬШЕ. В свое время подробно копался сравнивая - быстродействе в ARM режиме при работе по крайней мере с НЕ 8bit параметрами, было отчетливо больше. Так-что Thumb-бы это шаг прежде всего, на встречу восьмибитовикам. Да, сейчас недостатки Thumb нивелируют, подтягивают путем опять-же усложнения ядра. Но чистый 32bit ARM красив и сам по себе.

Проще-то оно может и проще, если на кубах всяких клепаете, а попробуйте в чистую, на голых сях, уж не говорю про асмы, сам ужаснулся И сравните то, что нужно для инициализации аврки или пика, и 32ф4хх например, Разница заметна?

Чем NVIC не угодил?? Работал и с ним на 407стм и с irq\fiq на А9 первый куда лучше, т.к. гораздо меньше программной обработки...



Чем он был красив? Тем, что под 8 или 16 бит выделял всегда 32бита?? И куда подевалась моя память??
Это как аля виндовое программирование, когда результат команды, хоть 1битный(да нет) представлялся как инт32 бита

Именно на "голых" С и "голых" компиляторах я и работаю. Никакие "библиотеки" и даже IDE от производителя я не использую. Ну а ASM-ы вообще можете забыть. Уже лет 20 на ASM не более нескольких десятков строк пишу, да и то все меньше и меньше. Уже давно обильное использование ASM есть верный способ сделать программу горомоздкой, медленной и глюкавой. Проверено путем _переделки_ работ упертых пико-авр-асм писателей НЕОДНОКРАТНО .
Ну а на кортексе даже startup на C пишется естественно.

Читать умеете? Тогда ВСЕ написано в моем предыдущем посте:



Тем, что позволял БЕЗ коственной адресации БЫСТРО делать сложные вещи.

Если Вы расскажете мне, что Вам на каком-то ARM не хвтило Flash, то я Вам НЕ поверю. Да и по расходу ROM памяти в ARM режиме на МОИХ реальных задачах требующих математики,
а не просто ветвления по одному биту, размер кода оказывался зачастую даже МЕНЬШЕ. Вот такой сюрприз!

Вот тут Вы ОБЛАЖАЛИСЬ по полной.
1) командой Вы обозвали функцию, ибо только о них можно говорить в контексте windows API, а не о командах ядра на которые ни win, ни Lin ни кто-либо еще ну никак не влияют.
2) функции ДОЛЖНЫ по максимуму и получать и возвращать НАТИВНОЕ для данного ядра значение, даже если нужено меньше. Ибо разрядность стека и регистров тут принципиальна. Когда я вижу, что какая-либо "библиотека" под, например, ARM радостно возвращает байт, я сразу понимаю, что мозгов у писателей сего не густо .

Да пожалуйста - sam7s64 16кило памяти и 64 флеш, но он не в счет - дело в оперативке. Не все пишут на чипах с памятью в сотни килобайт.





Вот после таких программеров программы и "пухнут" от размера оперы и своего объема...



Для кортексов нативно и 8 и 16 и 32бита.



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

Не поминайте оперативку всуе. К памяти КОМАНД она отношения НЕ имеет.

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

Абсолютная глупость. Не обсуждаемо даже.

Это, увы, очень влияет на понимание уровня квалификации оппонента .

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

ЗЫ. А еще, мнеб было очень любопытно, еслиб вы рассказали о паре-тройке своих мегапроектов, для расширения кругозора, так сказать, хотябы в 2х словах, а пока это просто понты и не больше.
А если нет - то не вижу смысла дальше дискутировать с такими любителями терминологии.

Ну я пишу без библиотек типа куба, ничего нормально.
Я бы сказал что лок-фуз биты АВР - был тот еще кошмар. Хорошо потом появился визард для них.

Сам арм то быстро настраивается, периферия у него сложнее, и потому она сложнее настраивается. Но зато она может много того что АВР и не снилось.
Так что тут я поддерживаю не надо за АВР держаться.

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

Про вложенность прерываний не согласен, в реализации NVIC оно очень хорошо. В старой системе требуемая вложенность замедляла процесс... Я раздаю приоритеты, и всегда уверен что что-бы не случилось у меня синхронный по таймеру процесс все сделает, с высшим приоритетом и никакие обработки езернета его не перебьют. Я знаю что в программе не будет запрета прерываний на критические секции, которые могут отодвинуть синхронный процесс.
NVIC - 100% добро, с автосохранением части стека и переходом в 12 тактов. Сколько переход в старом арме был? А если вложенность нужна, сколько сохраняли?

Ровно как Thumb2 мне кажется более правильным, что стал сложнее расчет, ассемблер, и проц мне не важно. Ведь сами правильно сказали АСМить уже не надо. А компилятор и косвенной адресацией неплохо справляется. Thumb - режим уступал АРМ это факт, но Thumb2 отличается в нем же не только 16 бит, но и 32 битные команды. И большего числа команд уже практически не надо.

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


А в кортексе М7 еще конвейеры похитрее и прочее..

Уговорили. Я Вас поддолкну, но дальше САМИ думать будете. Начало простое - откомпилируйте в thumb две функции


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

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


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

В общем случае вложенность есть зло, ибо приводит к недерминированности. Только для достаточно примитивнно строимых вещей нужна. Может просто следует забыть о вечном цикле на столь приличных контроллерах, как ARM?

Справляется, и опитимизация офигительная местами идет. Но все-же 32 бита команда это зачастую очень эффективно.

Не факт. Совсем не факт. Во первых, 32bit команда по количеству сделанного может первосходить 16 bit, так-что в "командах" считать не надо. Второе, к чему мне куча команд зараз считанных из Flash, если у меня первая из команд это переход .
Сравнивать надо на чем-нибудь хоть сколько приближенном к реальности. Ну хотя-бы на dhrystone тестах. Thumb2, несомненно, развитее, но в свое время Thumb ARM проигрывал изрядно.

Как вы умудряетесь в startup на C делать очистку секции "bss" (инициализированые нулями данные)?
У меня это единственная часть, которая делается инлайн-ассемблером. Если делать на Си, то код обнуления области памяти не всегда корректно работает (зависит от компилятора). Видимо, компилятор рассчитывает на изначально нулевое значение переменной счётчика, что не так на стадии стартапа.

Та же проблема, но теперь вынесена в libc.
1) Какие гарантии, что memset не рассчитывает на заранее инициализированную/очищенную область памяти?
2) При оптимизации LTO будет ли вообще этот memset как вызов libc или цикл очистки будет "заинлайнен"?

Всё это меня очень сильно смущает. Есть ли какие-нибудь гарантированные способы обойти эти неоднозначности? (без АСМа)

А меня не смущает.
1) Да, теоретически memset() может использовать статическую переменную, но это было бы довольно глупо.
2) Если в новой среде зануление переменных не сработает, это будет довольно очевидно, и исправить будет несложно. Можно даже добавить assert() по этому поводу.
3) А чем инлайн-ассемблер лучше? Такая же потенциально непереносимая штука.

- C какого-бы бодуна???
- посмотреть в исходик библиотеки
- да написать примитивнейший цикл самому-же на 'C'.
У меня для ARM вызывается своя функция писанная на ASM, но не из-за паранои, а из-за скорости. Для Thumb пока поленился на ASM подчистить.

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

P.S.
Ради интереса одну функцию без заметной арифметики, компильнул 7 IAR-ом в Thumb, Thumb2 и ARM. Результат 234, 230 и 352 байта соответственно. Почему ее вытажил на свет божий? Потому, что во времена IAR 4.x, LPC2148 давал на этой функции процетов 25 прироста производительности в ARM mode. Но скорости, увы, уже впрямую сейчас не сравнить.

это какой-то плохой и злой компилятор.
В кодах от кейла если стоит
int a = 0;
то там в ассемблере явно есть регистр в который пихается 0, а потом используется на месте а. (без оптимизации)
Вроде бы нам как-то с первого курса долдонили что в не инициализированной памяти может быть что угодно, неужели это не долдонили тем кто пишет компиляторы? неверю....



Не чтобы поспорить, а чтобы самому стать лучше.

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

Что thumb проигрывал ARM это известный факт, а вот про thumb2 они написали типа сохранили компактность thumb и производительность ARM, и я не думаю что они сильно лукавят....


и они частично остались, именно те что были очень эффективны...



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



кстати один раз видел как 32 битная система стала тормозить когда ее переписали на 8 битные данные, ответ оказался очень простой, она так и считала в 32 битах, только добавила команду по отрезанию результата маской%).... Если все шины 32, регистры 32, и память 32. То конечно возвращать из функции 8 или 32 разницы по памяти нет. Все равно это либо в регистр либо в стек положат, также записанный за 1 такт, и имеющий все равно размер 32....



А поделитесь примером, самым простым, надеюсь не коммерческая тайна. Мне правда интересно...

у меня недавно был проект где проц должен был ровно раз в 10 мкСек что-то делать, причем максимально повторяемо, при этом он крутил ТСР стек, говорил по езернету и так далее. Я вынес эту работу в прерывание таймера, таймер запустил на 10 мкСек, и назначил наивысший приоритет. В результате где бы программа не находилась и чтобы она не делала, она прерывалась и четко работала. Без вложенности я даже не знаю как такое решить с гарантиями.

Да, это один из эффектов. Для борьбы с такими эффектами есть стандартные типы int_least8_t, int_fast8_t и иже с ними. Но их использование у "библиотекописателей" я вижу КРАЙНЕ редко . А безумные char, напротив, постоянно. Вот буквально сейчас вожусь с Jennic контролером у у которого ВООБЩЕ нет описания и только API, причем все байтами усыпано и чувствую себя очень, очень! стремно. Для себя такой "восьмибитовый" тип дефинирую для краткости, как bint (то-ли базовый, то-ли байтовый int - за давностью лет не помню ) и спокойно таскаю исходники по 8-16-32 битникам.

Как-бы не особая тайна, но там, например, все дело в сбаланстрованности Fast IRQ, быстрой обработки от очень специфичного высокоскоростного железа и реалтаймовой операционной системы.
В общем не "контроллер светодиода" и "простым" и понятным там не пахнет. Была важна быстрая реакция на прерывание, а не через сколько-то там тактов и короткий обработчик этого FIQ на фоне не менее жесткого и несколько синхронизированного 2ms прерывания.

Ну на старом контроллере такая вещь на FIQ может быть повешена. Ну на 10 МИКРО секунд перрывание вешать то, что Вы перечислили, это какой-то безумный прдход к делу
То-же TCP стек ни сном ни духом МИКРОСЕКУНД не требует и работает по собственным прерываниям и таймаутам. Это если его правильно писать.

Это лишние эмоции. Кому-то валерьянка помогает, кому-то - медитация. Ну, будут там лишние инструкции, ну и фиг с ними. "Работает - не трогай". "Преждевременная оптимизация - корень всех зол". И так далее.

Увы, это один из показателей КАЧЕСТВА кода. И если он оказывается глюкавым дерьмом, то ни один из Ваших "рецептов" не поможет.

А если НЕ работает. Причем иногда и далеко-глубоко? Ваши действия?

Глупые байки ленивых кодописателей муссирующие изречения 70x годов, когда трудоемкость даже просто написания текста была велика, а уж о качестве компиляторов да и их стандартизации и говорить не приходилось. Посему и существовала проблема, что написав изысканный код, можно получить проблем по самое не хочу. Зато написав любую как-то работающую фигню можно было себе обеспечить буквально пожизненное сопровождение со всеми сопутствующими бонусами.
Опитимизация должна начинаться уже на уровне задумки системы. А в самом низу, все компиляторы должны быть отстроены под нужные и максимальные оптимизации. Надо просто УЧИТЬСЯ правильно и четко излагать свои мысли и требования компилятору. Причем СРАЗУ, а не потом.

ну тут вопрос сколько тактов занимает переход по FIQ, и сколько это времени в той частоте проца.


очень важно было чтобы действия повторялись на одном расстоянии от этой 10 мкСек границы, а ТСР стэк имел свои прерывания, и какое-то время в них тратилось да и прочии прерывания системы, стек просто. Потому иногда граница попадала на серидину-начало другого прерывания, и действия бы смещались. Но благодаря системе вытеснения я точно знал что повторяемость будет 2-3 такта на 100 МГц для 10 мкСек события это 2-3%, то есть хорошо.

Да на старом арме я бы повесил это прерывание на FIQ, а если бы оно было не одно? То есть NVIC мне дает возможность иметь несколько прерываний которые корректно вызовутся как вложенные, без рукописного шедулера. А плата за это 12 тактов на 100 МГц, может так оказаться что это быстрее чем FIQ на старых армах.

Еще учтите, что сам вызов прерывания по себе еще ни о чем, еще нужна процедура, которая берет из массива векторов тот, который нужно по индексу дистрибутора. а это еще такты, такты...



Ну а что тут такого безумного, в прерывании 100к раз в сек, при частоте проца в 100МГц, скажем?? Если это полностью оправдывает задачу.. Безумно повесить на это прерывание код в 1000 тактов, это да, чистой воды дурь.

Ну да... "100к раз в сек, при частоте проца в 100МГц" это не дурь... а "1000 тактов" при частоте проца в 100МГц... 10мкС это дурь... не говоря о приоритете прерываний... Логика где??? Или опять "слова пико-аврщика который просто жутко боится даже ознакомится с чем-то другим"(С)???

логика в том что 10 мкСек на 100 МГц это как раз 1000 тактов
потому сделать такое прерывание реально дурь, ибо только оно и будет работать.

Кстати в той системе в нем от 300 до 700 команд в зависимости от условий, то есть да оно грузит проц на 30-70% но так как это его основная задача, то не страшно....



не совсем так. FIQ - быстрое прерывание было одно, на то оно и было быстрое что одно, не было векторов, он был один источники прерывания уже в процедуре обработки анализировались и конечно их делали по минимуму....

Так то оно так, можно и irq на один вектор задать, а если требуется более чем одно прерывание?
ЗЫ. Одно только непонятно, когда разрабатывали этот суперконтроллер прерываний были уже камни с аппаратным векторным контроллером, аля пресловутых аврок, почему они до этого недотумкали...

Спасибо... посмеялся...
И что... эти 1000 тактов не могут прерваться другим прерыванием... если нужно???
Правильно говорят... "АВР - это диагноз!"(С)...

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

А по сути, ну прервете его и дальше что? Основной программе вообще тактов не дадите?

Я писал это тому товарищу, который думает, что прерывания в 100к раз в секунду - это бред, поясню, нужно сделать сбор данных с порта и поместить в массив, сколь тактов потребуется? Допустим 20, плюс вход и выход в прерывание, все это хозяйство займет 3-4% процессорного времени на данной частоте. И в чем бред?? При условии, что я получаю четко детерминированную выборку по времени, это можно сделать по другому? Или, как мне тут предложили однажды - поставить ПЛИС? По-моему это бред...

Ой! Ограничили изучение рекламным буклетом .
Нет, 12 это только до вызова вектора. Дальше сам переход тактик. А сколько регистров еще НЕ сохраняется за эти 12 тактов? Напоминаю - 8 штук. На их сохранение и последующее восстановление, тоже такты нужны. Ну и возвратиться не забудьте, а это еще 12 тактов плюс такт на собственно команду возврата. При попадании приоритетного на вход в низкоприоритетное - еще до 6 тактов добавляется. Да, еще не забываем, что Flash из которого код выполняется не 0WS, так-что еще всякие фирменные механизмы предвыборки таки слетают при прерывании. На восстановление при входе-выходе еще затраты тактов.

Так-что зря Вы это вы 12 тактов помянули всуе .

На "старых" в FIQ за 5 тактов, причем оказывались в СВОЕМ СОБСТВЕННОМ стеке (а не нагло рвем одну из многих задач и пожираем ее стек) со СВОИМ банком хоть и не полным, регистров. И точка входа последняя в таблице, так-что без всяких джампов сразу можно было писать код. Это если просто тупо только о быстродействии говорить. Я же, напомню, что мне нравилось, как контроллер прерываний ложился на систему. NVIC, несоменно по своему хорош.

Если у вас прога выполняется всего 10мкС... тогда да... (рукалицо)...

Т.е. ... раскатывание сферического коня в вакууме в обратном порядке???
В общем - да... частые прерывания такой же бред как и длинные... а может ещё и хуже... большие потери на вход/выход... а так... по задаче...
И вообще... все эти фобии... из области скелетов в шкафу...

Ну и допустим, но это только если ОДИН вектор прерывания, в NVIC - это любой вектор из множества, а в старом контроллере нужно использовать программный селектор, который сожрет еще кучу тактов...

Ужас . Вообще-то вектора на IRQ родного контроллера прерывания от ARM были и есть, только при необходимости надо было ОДНОЙ комадой этот вектор считать-перейти. Или НЕ считывать, если не нужно было.

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



Чтоб не быть голословным, выложите сюда код обработчика irq с переходом на вектора прерываний из списка. Там и посмотрим, что это за "одна команда"

Ответ выше - ровно одна команда - считать и перейти. Для особо непонятливых скопипастил из startup:

По адресу 0xFFFFF030 и находится этот самый вектор.
Причем ПО ЛЮБОМУ одна команда перехода и вектор есть и в "новом" NVIC. Вот такая НЕСУЩЕСТВУЮЩАЯ проблема
Если, конечно, мы говорим о продаваемом ARM контроллере. Покупатели могли и свой прицепить любой степени примитивизма.