Есть одна большая функция в программе - которую можно поделить на много мелких ...
Вопрос как выгоднее по скорости исполнения - разделить ее на 18 мелких (по смыслу) или оставить как есть?

Если мелкие сделать принудительно встраиваемыми - то по скорости будет одинаково. А читаемость исходника повысится.

А если и не делать - может, ничего страшного и не произойдёт.
(какая разница, сколько процессор бездельничает в цикле IDLE - 97 или 98%..)

Эээ про Idle можно поподробнее?

ps эта функция исполняется раз в секунду но - ее исполнение может быть критичным по скорости ибо после нее идет обработка буфера uart (если он получил маркер - передача окончена) и посылка ответа

Я обычно большую массивную функцию (например, обсчёт данных с логарифмами, фильтрацией и формулами на полстраницы) делю на множество мелких подзадач, вешаю их на стейт-машину и запускаю всё это в общем цикле.
То есть, при каждой следующей итерации выполняется следующая подзадача, а в конце вся система переходит в IDLE.
В результате время отклика в общем суперцикле существенно уменьшается, а требования к быстродействию вычислений снижаются.

Естественно, это всё при отсутствии RTOS.

богатая идея...
надо обмуслить...
тока общаяя схема у меня порушится т.к. 1 секундный маркер....
и втом теле еще несколько обработчиков...

Ничего не порушится.
Маркер пусть запускает процесс.
Вот для затравки:


CalculateParameters() вставляете в общий суперцикл, флажок TimeToCalc запускает процесс и обнуляется в конце.
Хотя, можно его "вынести за скобки"... Вариаций множество.

И нафига оно такое надо?


И где тут Protothreads, который я "при каждом удобном случае пиарю" ? ЫЫЫ!

Достаточно их сделать статическими и компилятор их сам встроит если они вызываются лишь по разу.
2ТС:
Разбивайте всё по функциям на отдельные законченные логические блоки, чтобы была видна структура и прозрачны взаимосвязи.
Размер кода при этом не увеличиться ни на йоту.

размер кода пока не пугает ...
оперативки уже мало 95% занято (структурой данных и 2мя буферами uart) ... тока на стэк как я понимаю осталось
с ассемблером я практически не знаком - но каждый вызов функции это прыжок по коду - занимающий циклы процессора если я не ошибаюсь
но если написать что она- inline без static то она интегрируется в то место где вызывается?

Сообщение отредактировал GYUR22 - Feb 12 2011, 09:46

Static inline делается для того, чтоб описать в хедере - тогда нету разницы, где и сколько раз оно описано. Все равно будет при вызове встроено

Не всегда, а по усмотрению компилятора.

Для всех функций не представленных в интерфейсе модуля (использующихся внутри одного модуля, иначе говоря файла) считается правилом хорошего тона присваивать квалификатор static. Это сообщает компилятору о возможности встраивания кода функции при оптимальных на его взгляд условиях. А компиляторы нынче весьма и весьма умные.

Использовать квалификатор inline имеет смысл лишь для замены макросов функциями по большей части в заголовочных файлах.

Придерживаясь этих нехитрых правил можно получить не только оптимальный но и самодокументированный код.

Для гарантированного встраивания функции при любых условиях можно использовать особенности различных компиляторов.
В gcc например есть механизм атрибутов:
В других компиляторах используют механизм #pragma ...
Альтернатива - вечно зелёные и неувядающие макросы на все времена года:-)

static inline - не компилируется... пишет что линкер не нашел функций...
inline - все нормально работает
в чем подвох?

1. static inline функцию надо писать в h-файле, который надо подключить (#include) туда, где она будет вызываться

2. Пример написания static inline функции в h-файле (WinAVR)

где-то валяется в пыльном углу, все никак руки не дойдут асилить...




Можно и в .c, но только "для внутреннего употребления"
Короче говоря, static объявление действительно только внутри модуля, в котором оно объявлено.