AlexMI 20 8 октября Опубликовано 8 октября · Жалоба 46 минут назад, ДЕЙЛ сказал: Работать всё будет, но операционка будет тупить, если, например, таймер TIM1 будет генерировать прерывание 10000 раз в секунду или по I2C будем получать 50 кБ в секунду. Не, это так не работает. Или "многозадачность" на прерываниях, или RTOS, одновременно эти подходы использовать точно не стоит. А какой лучше это от конкретной задачи зависит, универсального решения нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kochevkv 1 8 октября Опубликовано 8 октября (изменено) · Жалоба 1 hour ago, ДЕЙЛ said: Я не создавал. Здесь поднялся вопрос о нагромождении кода в обработчике прерывания. Считаю, что в любых прерываниях нужно находиться минимально возможное время. Забежал, флаг сбросил, пин выставил, байт прочитал и назад. Да там больше половины это метки времени для теста. Остальное макросы где регистры читаются и устанавливаются. Условно на четных циклах я устанавливаю один период, на нечетных - другой. Сброс флагов. И чтение буфера SPI. Переменные компилятор сократит если упрусь в быстродействие. С учетом того что код в кэше там накладные расходы несколько циклов от 500 МГц. Ну сделаю я часть в цикле, но все равно гарантированное время нужно будет чтобы обработать все что надо, пропуски недопустимы, это выборка сигнала. Хоть в прерывании это будет, хоть в цикле - без разницы. При этом выборке я так могу задать максимальный приоритет и пусть другие подождут. А в цикле часики сработают на отрисовку в прерывании и хана выборке (в случае если мне нужна доп.обработка которую я в прерывание добавлю еще). 6 hours ago, ДЕЙЛ said: Возможно, частота тактирования CPU относительно низкая У cpu - 500 МГц. У таймера 75. Изменено 8 октября пользователем kochevkv Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 8 октября Опубликовано 8 октября · Жалоба 6 часов назад, ДЕЙЛ сказал: Конкретно в коде автора сразу бросается в глаза объявление переменных в обработчике прерывания. Неразумно на мой взгляд. Я их объявил бы заранее и сделал бы статическими, чтобы к вопросу их создания больше не возвращаться. Что??? А ничего, что те переменные - локальные автоматические? Вы понимаете разницу между автоматической переменной и статической? Похоже что нет. Да уж... а я тут о высоких материях.... Да из вас как погляжу - программист как из меня балерина. Начните с чтения учебника по языку си. До того, как начинать что-то советовать... Делать те переменные статическими - глупость несусветная. В 24.07.2024 в 19:32, kochevkv сказал: Поясните что я делаю не так и почему первый вызов занимает гораздо больше чем последующие? У вас в распоряжении = Cortex-M7. Весьма богатый по своим возможностям CPU. В том числе имеющий в своём составе и DWT-таймер. Который позволяет производить замеры скорости выполнения как фрагментов кода, так и отдельных инструкций. Промерить длительность выполнения всех участков кода - плёвое дело. Даже в отладчиках эта функция выведена. Например - в IAR: Шагаем и смотрим - что показывают эти поля. (Естественно: предварительно запретив все прерывания). И так находим где именно тормоза. Далее - изучаем их и понимаем - почему? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ДЕЙЛ 32 8 октября Опубликовано 8 октября · Жалоба Так я не вникал в назначение тех переменных. Сказал о том, как никогда не делал в прерываниях и всё прекрасно работает по несколько лет без перезапуска. Автоматическое выделение в памяти и освобождение тоже кто-то должен делать, а это лишние команды и такты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 8 октября Опубликовано 8 октября · Жалоба В 24.07.2024 в 19:32, kochevkv сказал: Получается что меньше 1,5...2 микросекунд реакции на прерывание не добиться? А зачем вы пытаетесь этого добиваться? Не понимаю. Если нужна обработка данных АЦП с минимальной загрузкой CPU, то для этого используют DMA и обработку сразу всего массива сэмплов, накопленных DMA за некоторый период. И контроллер DMA на чтение данных из АЦП потратит времени многократно меньше, чем CPU. Скорее всего - десятки нс. Что недостижимо для CPU. PS: А задержки входа в ISR могут быть вызваны работой других ISR, с приоритетом больше или равным рассматриваемому. Или из-за интервалов запрета прерываний (например - внутри критических секций) в остальном коде. 10 минут назад, ДЕЙЛ сказал: Так я не вникал в назначение тех переменных. Сказал о том, как никогда не делал в прерываниях и всё прекрасно работает по несколько лет без перезапуска. Автоматическое выделение в памяти и освобождение тоже кто-то должен делать, а это лишние команды и такты. Автоматические переменные любой вменяемый современный компилятор располагает в регистрах CPU. Не тратя на это ни одного лишнего такта CPU. Вы же предлагаете потратить кучу дополнительных тактов на загрузку адресов статических переменных в регистры, и на операции их чтения и записи. Т.е. - ещё более увеличить время выполнения того кода. Совершенно на пустом месте. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kochevkv 1 8 октября Опубликовано 8 октября · Жалоба 23 minutes ago, jcxz said: У вас в распоряжении = Cortex-M7. Весьма богатый по своим возможностям CPU. В том числе имеющий в своём составе и DWT-таймер. Который позволяет производить замеры скорости выполнения как фрагментов кода Ну я системный таймер использовал. Можно и dwt. А по шагам код из внутренней памяти что-то не шагает правильно. Скачет по всему тексту даже не по обработчику прерывания. Как осиавляешь код в sdram - все нормально. При этом ram код по итогу все выполняет, просто отладка глючит. Где-то что-то в среде не так настроено может. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 8 октября Опубликовано 8 октября · Жалоба 9 минут назад, kochevkv сказал: Ну я системный таймер использовал. Можно и dwt. А по шагам код из внутренней памяти что-то не шагает правильно. Скачет по всему тексту даже не по обработчику прерывания. Как осиавляешь код в sdram - все нормально. При этом ram код по итогу все выполняет, просто отладка глючит. Это не "отладка глючит". А у вас включена оптимизация высокого уровня. Естественно в этом случае - отлаживать по исходнику практически невозможно. Что вроде бы очевидно. Так как в высокооптимизированном коде теряются связи между исходным кодом и полученными из него командами. Отлаживать код нужно: или понижая уровень оптимизации; или - по окну дизассемблера. PS: И располагать ваш код в ОЗУ - нет никакого смысла. Сначала хотя-бы напишите его нормально (а не как сейчас). Оптимально написанный код даст выигрыш в скорости многократно выше, чем перенос его в ОЗУ. Тем более на МК с кешем и для кода выполняющегося циклически, и вызываемого часто - разница вообще скорее всего не будет заметна между выполнением из кешированного флеш vs из ОЗУ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kochevkv 1 8 октября Опубликовано 8 октября · Жалоба 6 minutes ago, jcxz said: А зачем вы пытаетесь этого добиваться? Не понимаю. Если нужна обработка данных АЦП с минимальной загрузкой CPU, то для этого используют DMA и обработку сразу всего массива сэмплов, накопленных DMA за некоторый период. Я ж уже писал. Не неправильно выбрал таймер. Понравились 32 бита, которые, в общем-то, не нужны. У него нет отдельных полей длительности 0 и длительности 1. Есть режим переключения 0-1 toggle и период. Т.к. АЦП запускает обмен данными только в 0 решил укоротить 1 и делать "полупрограммный" ШИМ. Период аппаратный, а переключение длительности программно в прерывании. DMA можно, но на прошлом контроллере было сделано так. Вот переделываю на другой. Было сделано в прерывании. Подсчет максимумов, коррекция нуля и прочие вычисления сразу в прерывании. Контроллер тянет, еще и отрисовку делать успевает и точно знаешь что никакое другое даже очень длительное прерывание процесс выборки не перебьет. 5 minutes ago, jcxz said: Это не "отладка глючит". А у вас включена оптимизация высокого уровня. Естественно в этом случае - отлаживать по исходнику практически невозможно. Что вроде бы очевидно. Так как в высокооптимизированном коде теряются связи между исходным кодом и полученными из него командами. Оптимизация отключена. Код из sdram того же прерывания отлаживается как надо. Тут что-то другое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 8 октября Опубликовано 8 октября · Жалоба 4 минуты назад, kochevkv сказал: Оптимизация отключена. Код из sdram того же прерывания отлаживается как надо. Тут что-то другое. Если скачет даже при полностью отключенной оптимизации, то скорее всего - потеряна связь между исходником и результирующим кодом. В этом случае надо удалить все промежуточные файлы (полученные предыдущими компиляциями), оставить только исходники и выполнить чистую полную перекомпиляцию всего проекта заново. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kochevkv 1 8 октября Опубликовано 8 октября · Жалоба 6 minutes ago, jcxz said: PS: И располагать ваш код в ОЗУ - нет никакого смысла. Сначала хотя-бы напишите его нормально (а не как сейчас). Оптимально написанный код даст выигрыш в скорости многократно выше, чем перенос его в ОЗУ. Тем более на МК с кешем и для кода выполняющегося циклически, и вызываемого часто - разница вообще скорее всего не будет заметна между выполнением из кешированного флеш vs из ОЗУ. Кэш активно используется дисплеем. Я б на него особо не надеялся. Дисплей без буфера, в режиме h v sync. Ускорение очень ощутимо при расположении кода и переменных в ram. Отрисовка ускорялась раза в 2 когда установки графики располагал в ram. Код оптимизировать в какую сторону? Там нет ничего лишнего. Он выглядит не очень для любителя ассемблера и регистров, но там везде макросы которые разворачиваются в простые регистровые. операции Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 8 октября Опубликовано 8 октября · Жалоба 1 минуту назад, kochevkv сказал: Кэш активно используется дисплеем. Каким образом кеш флеша (кеш кода) может использоваться дисплеем? Вы что-то путаете. 1 минуту назад, kochevkv сказал: Код оптимизировать в какую сторону? Там нет ничего лишнего. В самом начале у вас там куча ненужных функций. Каждая из которых занимает кучу тактов. Особенно с выключенной оптимизацией. Все эти чтения статусов и их очистка - это одиночные команды чтения и записи регистров периферии. И тот огород, что вы там нагородили - не нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kochevkv 1 8 октября Опубликовано 8 октября · Жалоба 1 minute ago, jcxz said: Все эти чтения статусов и их очистка - это одиночные команды чтения и записи регистров периферии. И тот огород, что вы там нагородили - не нужен. Так это и есть чтение-запись регистров) там нет функций. Я ж говорю - макросы через дефайн типа вот как-то так: #define SetPeriod( x ) ( pTMR1->PER = ( x ) ) 7 minutes ago, jcxz said: Каким образом кеш флеша (кеш кода) может использоваться дисплеем? Вы что-то путаете. Да, точно, путаю. Но как-то спокойнее когда код всегда где ему сказали быть) еще же есть основной цикл и другие прерывания. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexOrlo 0 12 октября Опубликовано 12 октября · Жалоба А как вы конкретно считали время в прерывании? Какой уровень оптимизации включён? Если у вас весь алгоритм в прерываниях, ядро между ними переводится в сон или нет? Как настроен MPU..? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
