Скажем так, это все таки обычный Low Pass Filter первого порядка. Немного от скользящего среднего отличается. Правда, обычно это пофиг. Мне другой вопрос не ясен. Нафига 2 переменных в структуре? Ведь Y=Y*(1-k)-k*v <=> Y=Y-k*(Y-v), не лишняя ли тут или vSum или vAverage?

Для удобства пользования и для минимизации вычислений.
Если хранить только vSum то вычислять Average придется как минимум 2 раза. Первый раз при апдейте АЦП, второй раз при использовании.

Все... Туплю. Уже и ответ пространный написал, хорошо хоть отправить не бухнул, вовремя дошло. Просто хранится Y/k (k<1, конечно), а не Y. В младших битах - просто дробная часть...
Хотя, тут конечно, классическая дилемма время/память - или лишняя переменная или 2 раза считать.

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

Скажем так, хочу увидеть задачи (все таки контроллерные... хоть чуть...)
где использование heap будет нужным/оправданным..

Видете ли. Совершенно вам не в пику пишу. Это просто вопрос подходов. Вы его не приемлете (...хоть чуть..), а я считаю использование HEAP вполне оправданным.

Начнём с того, что использование HEAP на Си практически не увеличивает загрузку процессора. Поэтому вреда от этого никакого. А отсюда следует что его применение возможно везде. Теперь второе. В Си, в отличие от ASM, вы не контролируете память. Не знаю как правильнее выразится. Давайте лучше на примере.

Представьте, что вы пишите проект на ASM для которого чем больше свободной памяти - тем лучше. Вы его пишете и распределяете память вручную. Выделяете кусок в виде .byte, смотрите на стек и так далее. Задачу эту вы написали например на м64. Через некоторое время вы переползли на м640 где памяти вдвое больше. Вам придётся минимум пересчитать остаток свободной памяти и поменять одну константу. Можно так поступить и на Си. А можно использовать HEAP и тогда при переносе вам ничего менять не придётся. Не придётся ничего менять и пересчитывать также и при внесении изменений в проект . Но это пример, где можно или так или так.

Приведу пример, где я примененяю HEAP.

Представьте себе что контролер выполняет команды. Каждая команда имеет разную длину. От десятка байт до нескольких килобайт. Имеется очередь активных команд состоящая из 10 команд. Каждая команда имеет время старта и время смерти (начала и конца исполнения). То есть находящаяся в очереди команда может исполняться а может не исполняться, но после смерти удаляется из очереди и соответственно подгружается новая команда. Источник поступления команд может быть разный (причём одновременно) RS485, SD, Ethernet, Rf, EEPROM.

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

Ну так я ж выше привел такие примеры.
Везде где есть пакетная обработка - использование heap'a (точнее сказать использование динамической памяти) экономит расход.


Один из способов борьбы с фрагментацией - секторный подход - форматируем некую область памяти на мотив секторов на диске фиксированного размера, потом выделяем и освобождаем их.

плюсы - быстро, нет проблем с фрагментацией, простой менеджер памяти.
минусы - overhead на маленьких объемах, и ограничение по объему.

Увеличивает и очень прилично...
Я как бы понимаю необходимость использования heap например при загрузке картинки или
приеме пакета неизвестной длинны через Ethernet...
но для реалтайма непонимаю...
Как это не контролирую ? Лично я контролирую, и это не сильно отличается от асм,
ну конечно printf, итд я просто не пользуюсь.
Эээ..., ну просто стараюсь писать так чтобы перенос c одного чипа на другой заключался
только в переназначении пинов контроллера, обычно получаеться, правда иногда при переходе с более "старшего" чипа на младший приходится таймеры перенастраивать...
Вот и я о том же, примерно, вопрос в том где это (использование heap) применимо/эфективно,
Вот для EEPROM, ИМХО, применимо/эфективно, только это не совместимо с использованием
стандартного для IAR _flash...

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

Теперь опять возвратимся к терминам. Итак мы работаем с HEAP но не хотим в этом признаваться. Тогда у нас несколько путей. 1) вписываем работу с памятью прямо в тексте проги, 2) используем процедуры с уникальным названием, 3) используем стандартные названия (даже если процедуры пишем сами).

По-моему, лучше 3 путь. Всё таки это опыт программеров и общие термины. А вообще, и это мне тоже очень нравится, Си очень демократичный язык. Возьмите в своём проекте напишите процедуру malloc и вот вам стандартная и в тоже время более качественная (с вашей точки зрения) реализация.


PS: Не вижу ни каких проблем и с EEPROM и c FLASH. Можно сделать всё что угодно. Вплоть до реализации потоков и файлов. Или параллельной кучи и даже общей кучи. В винде вон часть памяти на винте находится территориально. А у меня, например EEPROM внешняя и внутренняя объёденены в общее пространство.
Всё в ваших руках. Не нравится - перепиши.

По-моему, с heap основная проблема в том, как рассчитать максимальную загрузку. И что делать, если память кончилась - допустимо ли отклонить запрос. Например, пример defunct - в 99% времени обработчику нужен только 1 пакет. Если таких обработчиков 5 - то какая куча нам нужна? На 10 пакетов? В этом случае мы не выигрываем по сравнению со статическим выделением памяти. А если, к примеру, на 6 пакетов - то что делать в ситуации, когда пакетов 7. Или можно доказать, что ни в один момент времени не будет больше 6 пакетов...
Следующий нюанс - если вы храните объекты разного размера, то можно получить ситуацию, когда из-за фрагментации невозможно будет разместить новый объект при наличии значительного кол-ва свободной памяти. Тут по-ходу придется мастерить что-то свое, стандартные механизмы работы с кучей не подойдут.
Лично я использую "самописную" кучу для пользовательского интерфейса - например, есть основной экран, из него можно попасть в меню, из него - в другое меню, оттуда - в настройку параметра, из нее иногда - в настройку еще одного параметра. При этом объекты уничтожаются в порядке, обратном созданию, соответственно реализация очень проста и нет фрагментации.

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

Можно доказать, что не 10, а 9 пакетов будет достататочно всегда, а это уже экономия:
Вариант когда на все 5 интерфейсов одновременно приходит пакет, начинается обработка самого приоритетного интерфейса, пакет перекладывает в стек, остальные 4 интерфейса "отцепляют" свой текущий приемный буфер (ставят пакет в очередь на обработку) и выделяют себе другой. Итого 5+4 = 9.

Минимальное же количество необходимых буферов зависит от скорости интерфейсов и от скорости обработки пакетов - минимум который можно достичь - 6.. На практике - 7 буферов будет достаточно.

Если динамическое распределение не нужно, то и не надо его за уши притягивать.
Я, к примеру, применять динамическое распределение при построении меню не стал бы, а вот Непомнящий Евгений реализовал и, как видите, доволен результатом. Это говорит, что мы все разные. А нужный инструмент выбирает программист исходя из видения своего проекта. А качество реализации зависит от того, как программист этим инструментом пользуется.

А знания, я в этом совершенно убеждён, никогда не являются лишними. Если ты знаешь, то точно можешь ответить, надо им пользоваться или нет. А если не знаешь, то не можешь и оценить.

Большое спасибо!!!
пользовалься CodeVisionAVR
перейду на IAR