Размер структур, стек и куча, Максимальный размер структур, их копирование, стек и куча Опции

[kolobochishe]

Пишем программу для нового прибора. Коллега создает вот такие структуры:

Код

typedef struct    {
    REC_HEADER Header;
    WORD NoPT;
    WORD NoPL;
    WORD NoAD;
    WORD StationID;
    WORD ModelID;
    WORD ManufactID;
    char Ident[9];
    char Descript[41];
    WORD StatTime;
    WORD NoFR;
    WORD NoRT;
    WORD NoBL;
    BYTE NoKY;
    BYTE NoPR;
    BYTE UnitsCal[7];
    float Units0dB[7];
    char KeyId[3][5];
    char KeyDescr[3][41];
    BYTE KeyGrade[3];
    float Factor[3];
    BYTE KeyTStamp[3][8];
    float KeyNom[3];
    float RPM[3];
    char KeyNotes[3][241];
    char PrId[12][9];
    char PrDescr[12][41];
    char Units[12][7];
    BYTE PrGrade[12];
    BYTE PrTStamp[12][8];
    float PrNom[12];
    float PrVal[12];
    char PrNotes[12][241];
                } RTN;

и вот в таком вот месте программа "виснет"

Код

void make_TA(void)
{
    BYTE    get_status(BYTE);

    RTN train=TRAIN; // ТУТ ЗАВИСАЕТ

Увеличил размер стека и все заработало. Был 3кБ сделал 10кБ. Правда, из SCRTACHPAD пришлось перенести в L1 из-за размера.
Контроллер Blackfin BF-548.

Теперь вопросы:
1. Как вы контролируете переполнение стека?
2. Какой размер считаете оптимальным?
3. В какой памяти его лучше располагать?
4. Как реально происходит приравнивание структур? Это спрятанное от глаз memcpy? И используется ли при этом динамическое выделение памяти?
5. Мириться ли с тем, что коллега создает такие огромные структуры или надо сменить подход? Можно ли их располагать в функции или лучше глобально?

[Сергей Борщ]

1) Заполнением стека константой перед запуском программы и проверкой, что наверху стека осталось какое-то количество ячеек с этой незатертой константой. Работает не всегда, но чаще всего работает.
2) Достаточный.
4) Да, memcpy. Нет, куча не используется. А зачем она могла бы при этом понадобиться?
5) Если нужна именно такая структура, то что вы тут сможете поменять?

[kolobochishe]

4) Да, memcpy. Нет, куча не используется. А зачем она могла бы при этом понадобиться?

Не знаю. Подумал, может создается копия, а потом копируется для случая memcpy с перекрывающимися областями памяти.

5) Если нужна именно такая структура, то что вы тут сможете поменять?

Ну как-то сделать свою часть программы такой, чтобы не было таких огромных локальных переменных. Пусть они будут, но не локальными переменными же. Если подойти к этому с размахом то там и мегабайтные маассивы начнут локально объявлять. Так никакого стека не хватит.

А про размер - ну просто из опыта работы. Какой делали максимальным на приборе с МК такого класса и 32-64 МБ ОЗУ

[ASN]

jcxz
Как-то работали с профессиональным программистом: много серийных изделий (в том числе и для европейских заказчиков).
Так он для DSP (TMS320C55x), где внутренняя память - ценный ресурс, выделял под стек половину внутренней памяти и размещал там просто огромные массивы и структуры.
Меня это удивило и поинтересовался зачем так делают?
Оказалось, что стек используется как куча с автоматическим освобождением. Типа стековой машины. Для данных, которым нужен быстрый доступ, оказалось очень удобно - нет лишнего копирования из внешней памяти во внутреннюю.
Правда, структуры были достаточно "хитрые" - с выравниванием по границе массивов.

[jcxz]

Как-то работали с профессиональным программистом: много серийных изделий (в том числе и для европейских заказчиков).
Так он для DSP (TMS320C55x), где внутренняя память - ценный ресурс, выделял под стек половину внутренней памяти и размещал там просто огромные массивы и структуры.

Так на C55xx нету флешь, соответственно оставшейся половины хватало на код и всё прочее??? Очевидно программа была достаточно простая.
"Европейскость" программиста не говорит о его профессионализме Повидал и попеределывал достаточно кода после в том числе и "европейских" программистов...

Меня это удивило и поинтересовался зачем так делают?
Оказалось, что стек используется как куча с автоматическим освобождением. Типа стековой машины. Для данных, которым нужен быстрый доступ, оказалось очень удобно - нет лишнего копирования из внешней памяти во внутреннюю.
Правда, структуры были достаточно "хитрые" - с выравниванием по границе массивов.

А зачем в ембеддед устройствах куча? Зачем в автономном устройстве, в котором нет ОС, запускающей различные чужие, заранее неизвестные задачи выделять и освобождать память???
За более чем десяток лет работы в этой сфере и множество разработанных устройств, я ни разу не сталкивался с необходимостью кучи (под линух не писал). Большинство моих проектов содержат десятки тысяч строк кода.
Что мешало этому самому программисту объявить все эти "хитрые" структуры static?
Если на разных этапах работы ПО эта память используется для разных структур, то что мешает для каждого этапа объявить свою структуру и объединить их в union???

А для C55xx такой подход тем более ущербный, если вспомнить, что память в этих ядрах разбита на смежные блоки, каждый из которых имеет отдельную шину данных.
Соответственно - если например необходима обработка двух массивов одновременно (проход КИХ-фильтра например), то расположив их в разных блоках памяти, можно было добиться большей скорости работы кода, убирания stall-ов доступа к памяти.
Если например у Вас в один массив DMA пишет сэмплы принимаемые с SPI, в другом массиве - коэффициенты фильтра, в третьем - выходные данные фильтра и Вам надо обработать это КИХ-фильтром высокого порядка как можно быстрее (желательно по два порядка фильтра за такт CPU или по два сэмпла за такт), то Вам нужно все эти три массива расположить желательно в 3-х разных блоках ОЗУ. А код чтоб был в 4-м блоке.
Как Вы это сделаете зафигачив стек на полпамяти??? Как Вы в стеке будете определять где закончился один блок памяти и начался другой?
А вот разложить эти массивы определив их в static и назначив каждому свой блок посредством компоновщика - всё красиво и аккуратно и работать будет на максимальной скорости и без stall-ов.

На C55xx у меня практически весь тяжёлый код сигнальной обработки использовал все шины CPU по максимуму, за счёт раскидывания рабочих массивов по разным блокам ОЗУ.
И я немало повидал говнокода из DSPLIB C55xx, который на простых алгоритмах использовал ядро C55xx всего процентов на 30 его возможностей. И попереписывал его.