+1. Если там плавучка не аппаратная, то все эти инлайны будут как мёртвому припарка.

float апаратный, а на инлайнах теряется около 500 тактов из всего 4700, хотя пока есть запас в 1700, но чем больше тем лучше.



Сообщение отредактировал pokk - Jul 20 2017, 09:53

Кстати, gcc с опцией -flto инлайнит направо и налево без всяких подсказок, ЕМНИП. В дизассемблере такое месиво получается, что ничего не понятно. Видимо, яр работает несколько иначе. Во всяком случае, обычно считалось, что компилятор может инлайнить только то, что видит в пределах компилируемого файла, что логично. И не факт, что multifile compilation отменяет это ограничение.

Да если все в одном модуле и объявлено как static то так же все получается. В дизассемблере сначала идет портянка сишного кода(ввиде коментарий) а потом голый ассемблер, что даже не понятно какая строчка СИ во что преобразовалась.


Ага увы, поспихал почти все обратно в один модуль, только что ещё раз отключил галку Function inlining ровно 500 тактов прибавилось.

Даже если аппаратный. Вы как бы совсем не задумывались, что используя float внутри ISR, необходимо сохранить/восстановить контекст FPU на входе/выходе ISR? А например на Cortex-M этот контекст в разы больше чем стандартный сохраняемый контекст. Время этого сохранения/восстановления будет много больше чем выигрыш от inline вашей функции.
Да надеюсь у Вас этот контекст вообще - сохраняется/восстанавливается?


Да ладно здесь байки рассказывать!
На вызов/возврат из функции (две команды CALL/BX LR) тратится +500 тактов???
Здесь всё-таки не форум кухарок....

Рискуете прослыть кухаркой, уважаемый.
Если, скажем, вызовов штук 20, да ещё принять во внимание Wait States, то ничего невероятного тут нет.

См. сообщения #5 и #6.

PS: Не ну конечно можно предположить, что у ТС CPU выполняет код из внешней флешь, подключенной по SPI и работающей на низкой SCLK и без кеширования.
В случае такого изврата конечно - каждый такт на счету и может и всего один вход/выход в функцию потянуть на 500+ тактов

Неа не сохраняется так как прием,обработка и выдача, сразу в прерывании, а маин пустой.




Это был частный случий. Самый простой.
А так да всего около 20 вызовов функции
Структура обработчика примерна такая:

А что бы не взять профайлер и посмотреть ?

Я через St-link программирую а он его кажись не поддерживает =(
Пробовал в симуляторе запускать, функцию Handler_adc закинул в while(1) до инициализации АЦП, но там мне он что-то от начала выдавал количество тактов, и в упор не хотел показывать сколько тактов выполняется каждая функция

У многих кортексов есть счётчик циклов. Поэтому можно тупо записать в массив засечки:

Вот прям нужно ЦОС на скорости получения данных от АЦП?
А "заполнение буфера-->ЦОС в буфере" не вариант, да?

Ну ок. Конечно только если FPU используется только в одном ISR? Иначе - "Шеф, всё пропало!"

Конечно странно - зачем запихивать фильтры (вроде оно там у Вас?) и прочее в ISR? У Вас есть уверенность, что данные успеют обработаться до следующего прерывания от АЦП? И обработаться при любом стечении обстоятельств (других обработчиков прерываний)?
Обычно в ISR просто кладут данные в кольцевой буфер, а обрабатывают их неспеша в менее приоритетном процессе (это может быть задача ОС или даже другое программно активизируемое прерывание с меньшим приоритетом (меньшим чем любое аппаратное прерывание)).
Я конечно делал так в одном проекте как-то давно, но там весь код обработчика (и ЦОС) был написан на ассемблере (а значит была уверенность в стабильности времени его работы). И там была острая нехватка ОЗУ в МК.