Сопоставление проектов С и АСМ, Немного цифр Опции

[SasaVitebsk]

Написал сначала проект на ASM в AVR Studio, а позже очень похожий на Си. И там и там вылизывал по скорости. Точнее особо не вылизывал. В обоих случаях камни с большим запасом. Естественно во втором проекте было всё намного грамотнее построено. Вопервых дробление шагов на основе ШИМ с большим коэффициентом, во вторых более красивое движение стрелок обеспечено. 18 скоростей с плавным переключением. Фильтрация более красивая. Обработка CAN некоторое место занимает. Тем не менее сравнивать можно

Результаты достаточно любопытны для неопределившихся. Попробовал свести в небольшую таблицу.

Код

Камень       ! atmega8 ! at90can128 !
язык         !   asm   !    IAR C   !
-------------+---------+------------+
Число ШД     !    6    !     6      !
управл.      ! дрб 6   ! ШИМ дрб 16 !
Вх аналоговые!    6    !     3      !
Вх частотные !    0    !     1      !
Вх CAN       !    0    !     2      !
Цифр. флтр   !    +    ! + более слж!
Плавность    !    -    ! спец алг   !
Авар         !    +    !+ более слж !
-------------+---------+------------+
Размер кода  !  5019   !   6901     !
без доп табл !   -     !    672     !
Итого        !  5019   !   6229     !
Итого %      !   81    !    100     !
RAM          !  241    !    415     !
Итого %      !   58    !    100     !
-------------------------------------

Несколько попозже буду перетаскивать Этот проект на м8. То есть можно будет сопоставить практически 1 к 1 (с учётом значительных улучшений).

[_Pasha]

В общем, наигрался я с "С". Память заканчивается, а проект лежит. Теперь переписываю на асме. Размер кода обещает быть в 2 раза короче (к слову о больших проектах). Да и пишется все по-быстрому, если знаешь, что делаешь. После чего все эти компиляторы, расплодившиеся в последнее время у меня в компе, летят в корзину. То же самое, кстати, касается и pic18 и dspic30/33 и HCS08, коими я иногда страдаю. Компилятор-то, оказывается, в голове...

[singlskv]

В общем, наигрался я с "С". Память заканчивается, а проект лежит. Теперь переписываю на асме. Размер кода обещает быть в 2 раза короче (к слову о больших проектах).

Такая разница может получиться ТОЛЬКО на вычислительных алгоритмах и в основном
в местах где при использовании С необходимо делать преобразование типов,
ну или для вариантов когда просто в С нет соответствующего размера типа,
например в С нет 3-байтовых переменных...

Для остальных вариантов..., ну показывайте код что ли, думаю что после некоторой оптимизации
он Вас опять же сможет удивить...

Совет для того чтобы память не заканчивалась в проектах на "C"
1. Делать стек большим, а глобальных переменных поменьше.
2. Использовать heap.

Вот здесь хотелось бы разъяснений и поподробнее...(без подколок...),
я не понимаю как уменьшить количество глобальных переменных.
Я не понимаю как можно использовать heap для уменьшения расхода памяти вместо
использования глобальных переменных...

[defunct]

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

А что Вы храните в глобальных переменных?
Ведь кроме конфигурации там больше нечего хранить.
Под все остальное память можно выделить либо в стеке, либо в куче.

Я не понимаю как можно использовать heap для уменьшения расхода памяти вместо
использования глобальных переменных...

это смотря под что у вас используются глобальные переменные.
Допустим имеем дело с неким протоколом где команды(пакеты) могут поступать не дожидаясь ответа на предыдущую команду(пакет). Предположим что глобально выделенно два буфера фиксированного размера (один обрабатывается, во второй принимается сл. команда). Попробуем сократить объем памяти.
Выделяем буфер из heap, ведем в него прием. По окончании приема, передаем указатель на этот буфер в функцию обработки, выделяем еще один буфер под прием сл. пакета и ведем прием дальше.
В функции обработки - перевыделяем память в соответсвии с реальным размером пакета (не всегда же пакет будет максимально возможной длины), или копируем во временный буфер в стеке, память освобождаем. Итого на лицо экономия памяти на 1 буфер в 99% времени работы нашего устройства (т.к. полных два буфера будет использоваться в очень короткий промежуток времени - только в момент между окончанием приема текущего пакета и запуском функции обработки).

Еще пример:
допустим по i2c раз в секунду надо что-то записать/прочитать.
Выделили буфер из heap - сказали i2c драйверу - читать/писать данные в него.
Все остальное время - эта память будет использоваться под что-то другое.

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

[singlskv]

А что Вы храните в глобальных переменных?
Ведь кроме конфигурации там больше нечего хранить.

Как это нечего ?
Вот вполне реальный пример, нужно по 4 каналам АЦП делать скользящее среднее по 8 измерениям,
ИТОГО:
4 * 8 * 2(байта на измерение) = 64 байта
+ 4(канала) * 2(байта) = 8 байт для хранения суммы
+ 1 байт на хранение номера канала
+ пару байт на всякие сервисные штучки
ИТОГО: ~75 байт глобальных переменных..

Пример N2:
Есть ~250байт которые есть суть текущее состояние системы, эти параметры могут быть запрошены
в любой момент например по протоколу модбас,
допустим что модбас работает на скорости 345600, можем ли мы хранить где-нить кроме глобальных
переменных эти данные ?

[defunct]

Как это нечего ?
Вот вполне реальный пример, нужно по 4 каналам АЦП делать скользящее среднее по 8 измерениям,
ИТОГО:
4 * 8 * 2(байта на измерение) = 64 байта

Я конечно не знаю вашей задачи полностью и возможно у вас есть некие строгие требования к сохранению фазы сигнала поэтому нужен КИХ, а я не брезгую БИХ'ом - ибо эффективней с т.з. памяти..
У меня скользящее по восьми измерениям занимает 2* U16 данных и кот наплакал кода.
итого 4 канала - 16 байт:
код для усреднения по 8-ми точкам:

Код

pChan->vAverage = (pChan->vSum + 4) >> 3;
pChan->vSum += val - pChan->vAverage;

но я не меняя размер данных могу и по 16-ти точкам усреднять и по 32-м и по 1024.
меняться будет только формула..
Конечно, это не тот случай когда heap чем-то помог, но все же думать об экономии там где это возможно - стоит.

Пример N2:
Есть ~250байт которые есть суть текущее состояние системы, эти параметры могут быть запрошены
в любой момент например по протоколу модбас,
допустим что модбас работает на скорости 345600, можем ли мы хранить где-нить кроме глобальных
переменных эти данные ?

Статистика / параметры системы - это есть конфигурация...
Стало быть легально делать их глобальными.

[singlskv]

Я конечно не знаю вашей задачи полностью и возможно у вас есть некие строгие требования к сохранению фазы сигнала поэтому нужен КИХ, а я не брезгую БИХ'ом - ибо эффективней с т.з. памяти..
У меня скользящее по восьми измерениям занимает 2* U16 данных и кот наплакал кода.
итого 4 канала - 16 байт:
код для усреднения по 8-ми точкам:

Я тоже пользуюсь разными вариантами... иногда честное скользящее среднее
иногда экспоненциальный фильтр.

Код

pChan->vAverage = (pChan->vSum + 4) >> 3;
pChan->vSum += val - pChan->vAverage;

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

Конечно, это не тот случай когда heap чем-то помог, но все же думать об экономии там где это возможно - стоит.

Ну вот я и хочу увидеть эту экономию, и особенно в сравнении с асм,
не, я конечно понимаю что для моих задач никакой экономии просто не будет,

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

[defunct]

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

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

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

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

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