В среде Atmel Studio во время компиляции в окне Output появляются такие строки:

Судя по цифрам, можно сделать вывод, что первая - это место, занимаемое программой во флеше контроллера, а вторая - это объем используемой SRAM.
Больше интересует вторая строка. На сколько это точные показания и как они определяются?

Второй вопрос. Программа для STM32, написанная в CoIDE (CooCox). Есть ли там возможность увидеть информацию об объеме используемой SRAM?

И третий вопрос. Всё та же CoIDE.

Помогите понять, что значат эти цыфры? Я так понимаю, что "dec" - это размер занятого флеша, а "hex" - то же самое, только в шестнадцатиричном формате. Могу предположить, что "text" - это количество команд в программе. Поправьте, в чем не прав и поясните, что есть "data" и "bss"?

text - размер сегмента с кодом, векторами прерываний и константами только на чтение (rodata, text, isr_vector)
data - размер сегмента с инициализированными переменными, НО инициализированными НЕ нулём.
bss - размер сегмента с не инициализированными переменными или инициализированными нулём.
стек включается либо в bss либо идёт отдельно в оставшейся памяти, надо смотреть скрипты линковки (*.ld). В Вашей среде раньше включался в bss.

А так же есть служебные метки (на границе секций) для компилятора и линковщика, а так же выравнивание секций по границе в 2-4 байта. В сумме это не более пары десятков байт.

Итог:
Занимаемое флеш = text + data + 10..50 байт
Занимаемое ОЗУ = data + bss + 10..50 байт

Контроллер у меня STM32F407VG. Вот описание выделенной памяти в том самом скрипте линковки:

Правильно ли я понимаю, что в этом случае под сегменты data + bss остается 0x00020000 - (0x2000 + 0x8000) = 0x16000 или 90112 байт памяти?

И еще один момент, учитывают значения data и bss память, выделяемую функциями calloc или malloc?

да


нет, не учитывают, т.к. определяются во время работы программы а не во время компилирования.
Дин память выделяется из кучи, которая 32кб, у тебя же всё там написано:

Если bss - размер сегмента с не инициализированными переменными или инициализированными нулём, то поидее если я не меняю ничего в программе, должен оставаться постоянным. Так?
Я меняю размер кучи в скрипте линковки, и вижу странную зависимость - при увеличении размера кучи увеличивается значение bss после компиляции проекта. Что здесь не так?

Ну так и получается - растет неинициализируемый участок ОЗУ, часть которого выделена под кучу

Внимательно читай все *.ld файлы, ищи ГДЕ и КАК используется HEAP_SIZE т.к. в разных версиях кокоса по разному организована куча.
Можно только самому разобраться, потому что я не знаю и не имею всех версий среды и не знаю что за проект и что за настройки и скрипты в нём.
Да и если разобраться - пригодится и не раз. Можно считать что это лаба. И затрагивает она не только МК. Очень полезная лаба
А так же ознакомься с форматом *.ld файлов, это не так сложно как может показаться.

Согласен. В целом уже разобрался что да как. Спасибо за правильный вектор, куда смотреть.
Вся проблема у меня была в том, что не хватало размера кучи, для динамического выделения. Остался еще один вопрос. Если сильно увеличить размер кучи, до такой степени, что не хватит под статически выделяемую память, компилятор сообщит об этом?

Компилятор делает код. Компилятору всё равно - он наделал код в объектные файлы и всё. Далее объектные файлы передаётся системой сборки в линковщик
Линковщик собирает объектники, связывает их, и размещает по регионам памяти делая elf файл из которого уже получается бинарник или что там надо.

В лд файлах указан размер озу, если в озу не влезет то линковщик выдаст типа этого (переполнение региона ram на X байт)
http://prntscr.com/40jh5a
в примере конфигурация для 4к озу.