[scifi 1]

И когда избавитесь от float, увидите, что inline даёт сущие крохи по сравнению с float. И об inline надо думать уже в последнюю очередь (при оптимизации по скорости).

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

[pokk 0]

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

 

 

Изменено 20 июля, 2017 пользователем pokk

[scifi 1]

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

[pokk 0]

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

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

 

Во всяком случае, обычно считалось, что компилятор может инлайнить только то, что видит в пределах компилируемого файла, что логично. И не факт, что multifile compilation отменяет это ограничение.

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

 

[jcxz 184]

float апаратный

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

Да надеюсь у Вас этот контекст вообще - сохраняется/восстанавливается?

 

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

Да ладно здесь байки рассказывать! :rolleyes:

На вызов/возврат из функции (две команды CALL/BX LR) тратится +500 тактов???

Здесь всё-таки не форум кухарок.... :laughing:

[scifi 1]

На вызов/возврат из функции (две команды CALL/BX LR) тратится +500 тактов???

Здесь всё-таки не форум кухарок.... :laughing:

Рискуете прослыть кухаркой, уважаемый.

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

[jcxz 184]

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

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

 

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

В случае такого изврата конечно - каждый такт на счету и может и всего один вход/выход в функцию потянуть на 500+ тактов

[pokk 0]

Да надеюсь у Вас этот контекст вообще - сохраняется/восстанавливается?

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

 

 

 

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

Это был частный случий. Самый простой.

А так да всего около 20 вызовов функции ;)

Структура обработчика примерна такая:

void Handler_adc(void){
    uint8_t i;
    uint32_t sample;
    float32_t Result;
    sample=ADC;  // Считали значение АЦП
    filtr1(sample);
    filtr3(sample);
    for(i=0;i<15;i++){
        Result=filtr4(sample);
        Result=calc(Result);            
        Result=convert(Result);
    }
    SendResult();  // Установка DMA
}

 

 

[x893 35]

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

[pokk 0]

Я через St-link программирую а он его кажись не поддерживает =(

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

 

[scifi 1]

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

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

timestamp[i++] = DWT->CYCCNT;

[Obam 30]

Структура обработчика примерна такая:

…

Вот прям нужно ЦОС на скорости получения данных от АЦП?

А "заполнение буфера-->ЦОС в буфере" не вариант, да?

[jcxz 184]

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

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

 

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

Обычно в ISR просто кладут данные в кольцевой буфер, а обрабатывают их неспеша в менее приоритетном процессе (это может быть задача ОС или даже другое программно активизируемое прерывание с меньшим приоритетом (меньшим чем любое аппаратное прерывание)).

Я конечно делал так в одном проекте как-то давно, но там весь код обработчика (и ЦОС) был написан на ассемблере (а значит была уверенность в стабильности времени его работы). И там была острая нехватка ОЗУ в МК.