Я использую слишком много оперативной памяти. Как это можно измерить?

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

Я решил это, потому что я могу добавить раздел, а затем все адские разрывы где-то еще в моем коде без видимой причины. Если я #ifndefчто-то еще, это работает снова. В новом коде нет ничего плохого

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

Проходя и пытаясь решить это, у меня возникают проблемы, когда я получаю перечисления и структуры; сколько памяти они стоят?

Первое редактирование: ТАКЖЕ, с самого начала я так много редактировал свой эскиз, это не фактические результаты, которые я изначально получил, а то, что я получаю сейчас.

  text     data     bss     dec     hex filename
 17554      844     449   18847    499f HA15_20140317w.cpp.elf
 16316      694     409   17419    440b HA15_20140317w.cpp.elf
 17346      790     426   18562    4882 HA15_20140317w.cpp.elf

Первая строка (с текстом 17554) не работала, после большого редактирования вторая строка (с текстом 16316) работает как надо.

редактировать: в третьей строке все работает, последовательное чтение, мои новые функции и т. д. Я по существу удалил некоторые глобальные переменные и дублировал код. Я упоминаю об этом, потому что (как и предполагалось) речь идет не об этом коде, а об использовании оперативной памяти. Что возвращает меня к первоначальному вопросу: «Как лучше измерить это?» Я все еще проверяю некоторые ответы, спасибо.

Как я на самом деле интерпретировать вышеупомянутую информацию?

Пока что мое понимание таково:

`TEXT` is program instruction memory
`DATA` is variables (unitialised?) in program memory
`BSS`  is variables occupying RAM

поскольку BSS значительно меньше 1024 байта, почему второй работает, а первый нет? Если это так, DATA+BSSто оба занимают более 1024.

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

Вы можете использовать функции AVRGCC: Мониторинг использования стека

Функция была предназначена для проверки использования стека, но она сообщает о фактической оперативной памяти, которая никогда не использовалась (во время выполнения). Это делается путем «раскрашивания» (заполнения) ОЗУ известным значением (0xC5), а затем проверки области ОЗУ с подсчетом количества байтов, имеющих прежнее начальное значение.
В отчете будет отображаться ОЗУ, которое не было использовано (минимальное количество свободной ОЗУ), и поэтому вы можете рассчитать максимальное ОЗУ, которое было использовано (Общая ОЗУ - указанная ОЗУ).

Есть две функции:

• StackPaint выполняется автоматически во время инициализации и «закрашивает» ОЗУ значением 0xC5 (при необходимости может быть изменено).

• StackCount может быть вызван в любой момент для подсчета ОЗУ, которое не было использовано.

Вот пример использования. Не делает много, но предназначено, чтобы показать, как использовать функции.

// -----------------------------------------------------------------------------
extern uint8_t _end;
extern uint8_t __stack;

void StackPaint(void) __attribute__ ((naked)) __attribute__ ((section (".init1")));

void StackPaint(void)
{
#if 0
    uint8_t *p = &_end;

    while(p <= &__stack)
    {
        *p = 0xc5;
        p++;
    }
#else
    __asm volatile ("    ldi r30,lo8(_end)\n"
                    "    ldi r31,hi8(_end)\n"
                    "    ldi r24,lo8(0xc5)\n" /* STACK_CANARY = 0xc5 */
                    "    ldi r25,hi8(__stack)\n"
                    "    rjmp .cmp\n"
                    ".loop:\n"
                    "    st Z+,r24\n"
                    ".cmp:\n"
                    "    cpi r30,lo8(__stack)\n"
                    "    cpc r31,r25\n"
                    "    brlo .loop\n"
                    "    breq .loop"::);
#endif
} 


uint16_t StackCount(void)
{
    const uint8_t *p = &_end;
    uint16_t       c = 0;

    while(*p == 0xc5 && p <= &__stack)
    {
        p++;
        c++;
    }

    return c;
} 

// -----------------------------------------------------------------------------

void setup() {

Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
Serial.println(StackCount(), DEC);  // calls StackCount() to report the unused RAM
delay(1000);
}

Основные проблемы, которые могут возникнуть при использовании памяти во время выполнения:

• нет доступной памяти в куче для динамического выделения ( mallocили new)
• при вызове функции в стеке не осталось места

Обе они на самом деле одинаковы, поскольку AVR SRAM (2K на Arduino) используется для обеих (в дополнение к статическим данным, размер которых никогда не изменяется во время выполнения программы).

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

Стек и куча можно увидеть на рисунке ниже (любезно предоставлено Adafruit ):

Следовательно, наиболее ожидаемая проблема возникает из-за переполнения стека (т. Е. Когда стек увеличивается в направлении кучи и переполняется в нем, а затем - если куча не использовалась при всех переполнениях в статической зоне данных SRAM. В то время у вас высокий риск:

• повреждение данных (то есть стек перезаписывает кучу или статические данные), давая вам непонятное поведение
• повреждение стека (то есть куча или статические данные перезаписывают содержимое стека), что обычно приводит к сбою

Чтобы узнать объем памяти, оставшийся между вершиной кучи и вершиной стека (на самом деле, мы можем назвать это дном, если мы представим и кучу, и стек на одном изображении, как показано ниже), вы можно использовать следующую функцию:

int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

В приведенном выше коде __brkvalуказывает на верхнюю часть кучи, но это 0когда куча не используется, и в этом случае мы используем &__heap_startуказатель __heap_startна первую переменную, которая отмечает дно кучи; &vКонечно, указывает на вершину стека (это последняя переменная, помещаемая в стек), поэтому формула, приведенная выше, возвращает объем памяти, доступный для стека (или кучи, если вы ее используете) для роста.

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

Конечно, если вы когда-нибудь увидите, что эта функция возвращает отрицательное число, тогда уже слишком поздно: вы уже переполнили стек!

Когда вы выясните, как найти сгенерированный файл .elf во временном каталоге, вы можете выполнить приведенную ниже команду, чтобы сбросить использование SRAM, где project.elfего следует заменить сгенерированным .elfфайлом. Преимущество этого вывода - возможность проверить, как используется ваша SRAM. Все ли переменные должны быть глобальными, действительно ли они все обязательны?

avr-objdump -S -j .bss project.elf

project.elf:     file format elf32-avr


Disassembly of section .bss:

00800060 <__bss_start>:
        ...

00800070 <measurementReady>:
        ...

00800071 <cycles>:
        ...

00800073 <measurement>:
  800073:       00 00 00 00                                         ....

00800077 <measurementStart>:
  800077:       00 00 00 00                                         ....

0080007b <timerOverflows>:
  80007b:       00 00 00 00

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

Кроме того, avr-objdump -S -j .data project.elfможно проверить, но ни одна из моих программ не выводит ничего с этим, так что я не могу точно сказать, полезно ли это. Он должен в список «инициализируются (ненулевые) данных».

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

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

Если вы используете динамическое распределение, вы можете столкнуться с проблемой, как только начнете освобождать память. Это связано с фрагментацией памяти в куче.

Проходя и пытаясь решить это, у меня возникают проблемы, когда я получаю перечисления и структуры; сколько памяти они стоят?

Перечисление занимает столько же места, сколько и int. Итак, если у вас есть набор из 10 элементов в enumобъявлении, это будет 10*sizeof(int). Кроме того, каждая переменная, которая использует перечисление, является просто int.

Для структур было бы легче использовать, sizeofчтобы узнать. Структуры занимают (минимальное) пространство, равное сумме его членов. Если компилятор выполняет выравнивание структуры, это может быть больше, однако это вряд ли в случае avr-gcc.

Существует программа под названием Arduino Builder, которая обеспечивает аккуратную визуализацию количества флэш-памяти, SRAM и EEPROM, которые использует ваша программа.

Конструктор Arduino является частью IDE- решения CodeBlocks Arduino . Его можно использовать как автономную программу или через IDE CodeBlocks Arduino.

К сожалению, Arduino Builder немного стар, но он должен работать для большинства программ и большинства Arduinos, таких как Uno.