Карма: 29
Рейтинг сообщений: 651
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2708 Откуда: г. Чайковский
Рейтинг сообщения:0 Медали: 1
Что такое CCM я не знаю, однако я тоже когда то считал что медленнее, приводил доводы по этому поводу и провел эксперимент, который мои доводы и опроверг. Конечно эксперимент был проведен на определенном камне (т.е. нельзя говорить за все), но скорость обуславливается шинами и скоростью памяти. Шины для конкретного ARM одни и те же, не важно в каком он камне, а флеш однозначно медленнее ОЗУ,
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.
Что такое CCM я не знаю, однако я тоже когда то считал что медленнее, приводил доводы по этому поводу и провел эксперимент, который мои доводы и опроверг. Конечно эксперимент был проведен на определенном камне (т.е. нельзя говорить за все), но скорость обуславливается шинами и скоростью памяти. Шины для конкретного ARM одни и те же, не важно в каком он камне, а флеш однозначно медленнее ОЗУ,
Ок, проведем эксперимент:
Код:
volatile uint64_t a = -1;
for (int i = 0; i < 20; i++) { a /= 7; }
F429, работающий на 300MHz (6WS) выдает 2801 тактов при работе из флеша и 3440, для RAM, у которой никаких WS нет... Для F103, работающего на 72MHz, получается 3516 vs 3627, все равно из флеша быстрее выполняется, даже без ART Accelerator.
Всем спасибо за высказывание мыслей. Перечитав ответы, подумал ещё раз, пересмотрел код и пришёл к следующему итогу: 1. Действительно, первый вариант кода моего примера проще к восприятию. 3. Перечитал статьи в интернете, кое-что вспомнилось про квалификатор volatile. 2. В настоящий момент нет острой необходимости к ускорению вычислений. На тактовой 24МГц прерывание может "съесть" до 30мкс. При текущих оборотах энкодера это вполне допустимо(есть хороший запас). Если обороты возрастут и задержка станет недопустмой, то перейду на проц F103 72МГц. Также может освободится ресурс если пересмотреть сам алгоритм вычислений вместо попытки вручную оптимизировать переменные volatile.
Теперь ответы на вопрос почему много вычислений происходит в прерываниях: 1. Сигнал с энкодера имеет не совсем обычный вид(см рис.). Поэтому аппаратный интрефейс обычного энкодера не подходит. 2. Энкодер генерирует мало импульсов на оборот. Для отслеживания позиции используется экстраполяция с учётом ускорений диска. Ожидаемый интервал корректируется программой с каждым новым импульсом.
для чего он введен? я так полагаю, что для тех платформ, где есть разные storage classes, с разным временем доступа, компилятор должен стремиться (очевидно, в зависимости от параметров оптимизации?) подбирать для переменных этих типов наиболее быстрый класс хранения... ведь auto - это значит "на усмотрение компилятора" в зависимости от контекста... вот как бы fast-типы это дополнительная подсказка компилятору. я не прав в своих предположениях?
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
или нет. Компилятор в общем случае не обязан этого делать
Этот register компилятор скорее всего проигнорит, т.к. в С++17 код с ним уже даже не компилится, а до этого он долго был depricated и игнорировался, потому учитывая общую кодовую базу компиляторов можно ожидать такое поведение и в С, но в том же gсс есть еще другая форма записи, с привязкой к конкретному регистру, вот тот register точно работает.
register это специфичная для компилятора функция. В KEIL (ARMCC) это позволяет использовать переменные именованные конкретным регистром на архитектуре ARM.
Синтаксис register unsigned int My_R0 __asm("r0");
Так же не забываем указывать директиву __inline или __forceinline для встраиваемой функции.
_________________ Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
процессоры (и память/конвееры/предсказатели/черти рогатые) могут по-разному работать с переменными разного размера. К примеру, x86 обыкновенно работает с 32-битными числами в целом быстрее, чем с восьмибитными; 16 бит - самые медленные. На amd64 64-битные еще чуть быстрее 32-битных. Если скучно, можете потестировать определения из gcc с линуксовым libc, x86-64:
Код:
arkhnchul@arkhost-scow:~$ gcc -E -dM -x c /dev/null | grep -E "INT_FAST[0-9]+_TYPE" | sort #define __INT_FAST16_TYPE__ long int #define __INT_FAST32_TYPE__ long int #define __INT_FAST64_TYPE__ long int #define __INT_FAST8_TYPE__ signed char #define __UINT_FAST16_TYPE__ long unsigned int #define __UINT_FAST32_TYPE__ long unsigned int #define __UINT_FAST64_TYPE__ long unsigned int #define __UINT_FAST8_TYPE__ unsigned char
там же, но 32 bit ABI:
Код:
arkhnchul@arkhost-scow:~$ gcc -m32 -E -dM -x c /dev/null | grep -E "INT_FAST[0-9]+_TYPE" | sort #define __INT_FAST16_TYPE__ int #define __INT_FAST32_TYPE__ int #define __INT_FAST64_TYPE__ long long int #define __INT_FAST8_TYPE__ signed char #define __UINT_FAST16_TYPE__ unsigned int #define __UINT_FAST32_TYPE__ unsigned int #define __UINT_FAST64_TYPE__ long long unsigned int #define __UINT_FAST8_TYPE__ unsigned char
я так полагаю, что для тех платформ, где есть разные storage classes, с разным временем доступа, компилятор должен стремиться (очевидно, в зависимости от параметров оптимизации?) подбирать для переменных этих типов наиболее быстрый класс хранения
еще раз - нет, это только тип. Storage class - отдельная сущность.
Я подумал, а нельзя ли включить оптимизацию над этой переменной в обработчиках прерываний и выключить в главном цикле. Всё это затевается чтобы немного сократить время выполнения обработчиков.
На входе в функцию скопировать эту переменную в локальную: uint v = v16; И при каждом изменении этой переменной внутри функции обновлять сразу обе: v16 = v = <expression>; Конечно не забывая про размерности и связанные с ними эффекты. И естественно так можно делать при условии, что данная функция не может быть прервана другой, имеющей внутри записи в данную volatile-переменную. Т.е. - если прерыван-ия (-ие) на время выполнения такого кода запрещены или если данное прерывание имеет наивысший приоритет из всех, где есть записи в данную переменную. Я везде именно так и работаю с volatile-переменными.
x86 обыкновенно работает с 32-битными числами в целом быстрее, чем с восьмибитными; 16 бит - самые медленные.
Зависит от режима CPU. В 16-битном режиме как раз самыми быстрыми (в среднем) будут 16-битные операции (т.к. отсутствуют префиксы переопределения размера операнда).
Частенько (все чаще и чаще) во всяких исходниках встречается записи такого вида: 1000000UL. Что это значит, что это вообще такое, и как с этим бороться?
Частенько (все чаще и чаще) во всяких исходниках встречается записи такого вида: 1000000UL. Что это значит, что это вообще такое, и как с этим бороться?
это значит, что программист пытается сказать "сия константа типа Unsigned Long". Некоторые (далеко не все) компиляторы его даже поймут.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
