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

[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 будет нужным/оправданным..

[SasaVitebsk]

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

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

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

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

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

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

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

[singlskv]

Начнём с того, что использование HEAP на Си практически не увеличивает загрузку процессора.
Поэтому вреда от этого никакого. А отсюда следует что его применение возможно везде.

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

Теперь второе. В Си, в отличие от ASM, вы не контролируете память. Не знаю как правильнее выразится.

Как это не контролирую ? Лично я контролирую, и это не сильно отличается от асм,
ну конечно printf, итд я просто не пользуюсь.

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

Эээ..., ну просто стараюсь писать так чтобы перенос c одного чипа на другой заключался
только в переназначении пинов контроллера, обычно получаеться, правда иногда при переходе с более "старшего" чипа на младший приходится таймеры перенастраивать...

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

Вот и я о том же, примерно, вопрос в том где это (использование heap) применимо/эфективно,
Вот для EEPROM, ИМХО, применимо/эфективно, только это не совместимо с использованием
стандартного для IAR _flash...