Онлайн-программа оценивает использование Flash и SRAM в прошивке контроллеров, собирая данные из секций компоновки (.text/.rodata/.data/.bss/noinit), учёта загрузчика, стеков задач RTOS, DMA-буферов и кучи. Инструмент показывает круговую диаграмму по Flash и горизонтальную диаграмму по SRAM, даёт числовую раскладку, предупреждения и грубую модель пика использования кучи с учётом типа аллокатора и профиля аллокаций.
👉 Калькулятор полезен для быстрых прикидок на этапе проектирования, обзор компоновки и подбора МК: видно, что занимает Flash, сколько реально «съедает» SRAM (глобальные, стеки, DMA, куча) и какой остаётся запас.
Как пользоваться
- Выберите настройку микроконтроллера или вручную задайте Объём Flash и Объём SRAM, в байтах.
- При необходимости укажите Загрузчик, который также занимает Flash.
- В поле «Вставьте секции, JSON или «section:size» строки» вставьте вывод по секциям:
- .text — машинный код — отображается как Code в торе Flash
- .rodata — константные данные — RO Data
- .data — инициализированные глобальные — Data init в Flash; в SRAM учитывается как часть Globals
- .bss — неинициализированные глобальные — учитываются в Globals в SRAM
- .noinit — данные вне инициализации — учитываются в SRAM отдельно
- В блоке RTOS и задачи добавьте задачи, указывая оценку стека или глубину вызовов:
- Если поле Est stack пустое/0, размер стека оценивается от глубины: ≈ 40·CallDepth + 256, минимум — «Запас стека, байт мин.»
- Флаг Rec повышает рекомендацию для рекурсивных трасс (~×1.6).
- В разделе Куча и аллокатор задайте:
- Аллокатор: malloc, TLSF или Static pool
- Резерв heap (линкер) — общий размер кучи
- Профиль аллокаций: доля малых/средних/больших и ожидаемая Одновременность
Модель прогоняет ~800 шагов аллокаций/свободных и оценивает пиковое занятое в куче и грубую фрагментацию.
- В разделе DMA и буферы перечислите крупные статические/долгоживущие буферы.
- Настройте Запас безопасности — перестраховка поверх оценки SRAM, и минимальный запас стека.
Форматы ввода секций
Можно вставлять как несколько строк вида section:size, так и JSON.
Вариант 1 — построчно:
.text:8192
.rodata:1024
.data:512
.bss:512
.noinit:256
Вариант 2 — JSON:
{
«.text»: 8192,
«.rodata»: 1024,
«.data»: 512,
«.bss»: 512,
«noinit»: 256
}
Если поле пустое или в нём нет .data/.bss, строка «Глобальные (.data+.bss)» покажет 0 B, а на торе могут остаться только «Free» и те категории, у которых есть ненулевые значения. Чтобы появились Code, RO Data, Data init — впишите соответственно .text, .rodata, .data.
Что показывает результат
- Таблица «Общее» — суммарное использование Flash и SRAM (с учётом запаса безопасности), «Глобальные (.data+.bss)», резерв кучи и оценка её пика, сумма стеков всех задач, DMA и добавленный запас безопасности.
- Куча и аллокатор — выбранный тип, пиковое занятое по симуляции, оценка фрагментации (понижается для TLSF), сколько свободно в куче при текущем сценарии.
- Flash — вклад Code, RO Data, Data init, Bootloader и Free.
- Гистограмма SRAM — вклад Globals (.data+.bss), Heap peak (оценка), Stacks, DMA, Free.
- Предупреждения — о близком заполнении Flash/SRAM, нехватке SRAM, высокой фрагментации кучи при malloc и чрезмерной доле DMA.
Режимы работы
- Подробно — детальный: секции, задачи, куча (с симуляцией), DMA, запас.
- Упрощенно — быстрый: подставьте «использовано Flash», «SRAM занято (bss+data)», резерв кучи, сумму стеков и DMA, плюс запас — диаграммы и цифры обновятся мгновенно.
Справочники, подсказки и частые вопросы
- «Глобальные (.data+.bss) = 0 B» — добавьте в поле секций строки .data:<байт> и/или .bss:<байт> (или JSON-пары).
- «В круговой диаграмме только Free» — заполните хотя бы одну из секций .text/.rodata/.data/Bootloader, иначе долей просто нет.
- Длинные числа на осях — подписи автоматически сокращаются в KB/MB; реальные значения видны в таблицах.
- Куча «пик» меньше/больше ожиданий — это оценка по модели; скорректируйте профиль (доли малых/средних/больших), «Одновременность» и тип аллокатора.
- Стек задач — если знаете точную оценку стека, введите её в Est stack. Иначе укажите Call depth и выставьте минимальный запас стека — калькулятор посчитает рекомендацию.
| Секция | Назначение | Особенности |
| .text (Code) | Исполняемый код программы | Хранится во флеш; при прошивке полностью записывается |
| .rodata (Read-Only Data) | Константы, таблицы, строки | Занимает флеш; не влияет на ОЗУ |
| .data (Data Init) | Инициализированные глобальные/статические переменные | Хранятся во флеш и копируются в RAM при старте |
| .bss | Неинициализированные глобальные/статические переменные | Занимают место только в RAM; инициализируются нулями |
| Heap | Динамическое выделение памяти (malloc/new) | Размер задаётся вручную; при нехватке — сбой |
| Stack | Локальные переменные, вызовы функций, контексты прерываний | Растёт вниз; глубина стека зависит от рекурсии и вложенности вызовов |
| Flash ресурс | Циклы перезаписи (Endurance) | Обычно 10⁴–10⁶ циклов; износ распределяется по секторам |
| Семейство | Flash (ПЗУ) | SRAM (ОЗУ) | EEPROM / NVS | Ресурс Flash |
| AVR (ATmega) | 4 – 256 КБ | 0,5 – 8 КБ | 0,5 – 4 КБ | 10⁴ – 10⁵ циклов |
| PIC16/PIC18 | 2 – 128 КБ | 0,2 – 4 КБ | 256 – 1 КБ | 10⁴ – 10⁵ циклов |
| STM32 (Cortex-M0/M3/M4) | 16 КБ – 2 МБ | 4 – 512 КБ | эмулируется во Flash | 10⁴ – 10⁵ циклов |
| ESP8266 | 512 КБ – 16 МБ (внешняя) | 64 – 160 КБ | раздел NVS во Flash | 10⁴ – 10⁵ циклов |
| ESP32 | 1 – 16 МБ (внешняя) | 320 – 520 КБ | NVS / SPIFFS / LittleFS | 10⁴ – 10⁵ циклов |
| MSP430 | 1 – 256 КБ | 0,5 – 16 КБ | 128 – 4 КБ | 10⁴ – 10⁵ циклов |
| ARM Cortex-M7 (STM32H7) | 512 КБ – 2 МБ | 1 – 2 МБ | эмулируется | 10⁴ циклов |
Замечания
- Все величины — в байтах, если не сказано иное. Формат ввода секций устойчив к 0xHEX и десятичным значениям.
- Округление для вывода: KB = 1024 B, MB = 1024 KB; подписи на осях могут показывать сокращения для удобства чтения.
- Модель кучи — эвристика для планирования и оценки запаса, а не замена инструментам профилирования под реальной нагрузкой.
Итого, при работе с микроконтроллерами распределение памяти напрямую влияет не только на стабильность, но и на срок службы устройства. Особенно это касается флеш-ресурса: каждая запись во флеш имеет ограниченное количество циклов перезаписи, и при интенсивном использовании необходимо учитывать равномерное распределение данных или применять wear-leveling. При проектировании прошивки стоит заранее закладывать запас памяти под динамические структуры, так как стек и куча могут вести себя непредсказуемо при редких, но глубоких вызовах функций или при работе с большими буферами.
👉 Также важно помнить, что глобальные переменные размещаются в статической памяти, и их объём всегда «съедает» часть доступного ОЗУ, независимо от того, используются они в конкретный момент или нет. Код, занимающий область .text, не влияет на оперативку во время выполнения, но напрямую расходует флеш, которая может оказаться ограничивающим ресурсом при больших проектах.
Дополнительным фактором становится кэш и прерывания: они могут увеличить требования к стеку за счёт сохранения контекста, что нередко упускается при ручной оценке. Всё это делает важным использование калькулятора памяти не просто как средства визуализации, а как инструмент прогнозирования работы программы при реальных нагрузках.
