КРАМ писал(а):
АРМ архитектура по сути не совсем архитектура реального времени из-за неопределенного времени исполнения команд и входа в обработчик прерываний. Из-за чего требуется более высокая частота работы
Тут уж не архитектура АРМ. Даже не говоря о том, что у АРМ чтото по Фон-нейману, чтото по Гарвардской... Каждое ядро со своим конвеером и тесно интегрированной переферией, типа контроллеров прерывания и памяти, с точки зрения определенности исполнения - уже 'своя архитектура'.
Ну а прерывания... Если критично - брать самые младшие кортексы и с макс частотой - у них конвеер короче, меньше латентность обработки прерывания. Или те ж адкие гибриды M3/4/7+M0 в одном корпусе, что те ж NXP давно начал делать, да и не только они
Да, и если латентность важна - ISR функции в SRAM. Флеш с контроллерах выше ~20-30Mhz чтука архилатентная. Ну и использовать свой стек для ISR.
КРАМ писал(а):
Но для СТМ32, учитывая особенности исполнения команд, писать на чистом АСМе, на мой взгляд, действительно идиотизм... АРМ архитектура по сути не совсем архитектура реального времени из-за неопределенного времени исполнения команд и входа в обработчик прерываний. Из-за чего требуется более высокая частота работы, чтобы минимизировать неопределенности исполнения кода и большой набор разнообразной периферии для привязки кода к реальному времени с высокой точностью.
Это может быть идиотизм с профессиональной точки зрения, а я аматор в этом деле (потому как заработать на хлеб разработкой программ под МК у нас вообще нереально - никому не нужно), поэтому использую то, что мне удобнее.
Думаю что при нормальном трансляторе асма с мощными макросами скорость разработки будет не на много ниже, нежели на си с "регистровым" подходом.
Не знаю как у кого, а у меня основное время тратится на изучение огромных мануалов от ST и на выяснение особенностей работы периферии, а не на написание кода.
У кортексов М0 время исполнения инструкций чётко оговорено в соответствующем документе (arm v6m technical reference manual). Время входа/выхода из обработчика тоже оговорено (с учётом приоритетов и вложенности, и возможности прерывания ldm/stm).
Латентность флеш памяти тоже оговорена, но на малых тактовых частотах можно считать нулевой. Других источников неопределённости я не знаю
Andrew Martin писал(а):
Думаю что при нормальном трансляторе асма с мощными макросами скорость разработки будет не на много ниже, нежели на си с "регистровым" подходом.
Таки есть трансляторы асма с код мувингом и инстракшн шеддулингом ? Реально, я не в курсе современного, я представлял себе компилер асма чисто как предпроцессор+транслятор их мнемонического кода в машинный.
Дело в том, что времена, когда можно было генерировать оптимальный код с табличкой по циклам единичной инструкции прошли.
Важен порядок инструкций при котором они пойдут по конвееру с минимальными задержками. Напомню, кортексы начиная с M3 суперскалярны.
Да и про архитектуру системы памяти тоже нельзя забывать. Было дело, поднял производительность процентов на 30% тормознув ядро по частоте на 12% -))
Andrew Martin писал(а):
У кортексов М0 время исполнения инструкций чётко оговорено в соответствующем документе
Вот, собсно, граница, на которой все просто почти "как на AVR", я бы очертил M0 на 24Mhz.
Так и есть. Выше по частоте уже латентность флеша, но она, как я понял из умных доков, тоже величина вполне определённая. Но можно же код исполнять из ОЗУ - AVR такое и не снилось Правда таблица векторов всё равно жестко сидит во флеше, но обработчики тоже ведь можно затолкать в ОЗУ. Это на случай если латентность жмёт.
Разговор сейчас именно о М0, посему не будем упоминать М3 и старше зря.
Кто-нибудь прояснит вопрос по SPI?
Andrew Martin писал(а):
Думаю что при нормальном трансляторе асма с мощными макросами скорость разработки будет не на много ниже, нежели на си с "регистровым" подходом.
Таки есть трансляторы асма с код мувингом и инстракшн шеддулингом ? Реально, я не в курсе современного, я представлял себе компилер асма чисто как предпроцессор+транслятор их мнемонического кода в машинный.
Дело в том, что времена, когда можно было генерировать оптимальный код с табличкой по циклам единичной инструкции прошли.
Важен порядок инструкций при котором они пойдут по конвееру с минимальными задержками.
Воно каких слов понабирались, да всё заграничных - "код мувингом и инстракшн шеддулингом"
Загляните в дизасме на сишный код. Я смотрел на выхлоп кейла, общая идея построения такая же, как в моём куске кода. В частности, большие 32битные константы хранятся в конце, после выхода из функции, а не в теле (перемежаясь с переходами).
Andrew Martin писал(а):
Загляните в дизасме на сишный код. Я смотрел на выхлоп кейла, общая идея построения такая же, как в моём куске кода. В частности, большие 32битные константы хранятся в конце, после выхода из функции, а не в теле (перемежаясь с переходами).
Это особенность Thumb кода - непосредственно адресуется +-2Кб вокруг SP. Поэтому Не делаются отдельные сегменты кода и сегменты данных, они перемежаются мелкими кусками.
Не знаю, как нынче Keil компилирует. И какие настройки оптимизации использованы. IAR с высокой степень оптимизации код так размывает, что родной дебагер уже перестает по сишному коду идти, т.к. кода с исходниками уж теряет структурную связь
Хотя, даже если "выхлоп кейла, общая идея построения такая же, как в моём куске кода", то уже идея писать на асме, на котором производительность разработчика на порядок ниже, становится сомнительной.
Andrew Martin писал(а):
Загляните в дизасме на сишный код. Я смотрел на выхлоп кейла, общая идея построения такая же, как в моём куске кода. В частности, большие 32битные константы хранятся в конце, после выхода из функции, а не в теле (перемежаясь с переходами).
Это особенность Thumb кода - непосредственно адресуется +-2Кб вокруг SP. Поэтому Не делаются отдельные сегменты кода и сегменты данных, они перемежаются мелкими кусками.
Хотя, даже если "выхлоп кейла, общая идея построения такая же, как в моём куске кода", то уже идея писать на асме, на котором производительность разработчика на порядок ниже, становится сомнительной.
Ну вот, точно этот самый адепт
Во-первых не +-2кБ, а только +1кБ, во-вторых не SP (стек-то тут при чём?), а относительно PC.
На порядок, уважаемый, это в 10 раз. Не надо утрировать. "На порядок" возможно только тогда, когда человек всю жизнь сидел на HLL и вдруг начал пробовать асм и соответственно смотреть на него, извините, как баран на новые ворота, да плюс к тому если у него череззадничный транслятор вроде родного но неуважаемого ARMASM.
Ассемблер - это образ мышления. Многие достаточно крутые кодеры даже сейчас его пользуют в некоммерческих проектах, хотя бы для эстетического наслаждения
Поэтому не нужно разводить холивар, лучше бы с SPI помогли.
a5021, я не удосужен обсуждать что-либо с теоретиками, тем более то, что давным-давно обсосано и работает на ура на всех линейках STM32. RTFM , клоун...