Динамическое создание массивов и ошибки при работе с ними, Косяк, но не понимаю почему Опции

[Halfback]

Смысл в том, что данные приходящие по UART сбрасываю в буфер RS232_RX_BUFFER. Потом при его заполнении выставляю флаг. Главная программа если видит флаг, то создает динамический массив того же размера что и RS232_RX_BUFFER и начинает его декодировать. Зачем сделана двойная буферизация? - Отвечаю: так надо

В коде происходит так:

Код

uint8 *buf1;
.....

if(RS232_RX_BUFFER_OVERFLOW) {
            buf1 = (uint8*) malloc(RS232_RX_BUFFER_SIZE * sizeof(uint8)); // Сообразили 2-й буфер
            //if (buf==0) break; // Тут надо придумать обработчик если памяти на буфер не дали
            buf1 = (uint8*) memcpy((uint8*)buf1,(uint8*)RS232_RX_BUFFER,RS232_RX_BUFFER_SIZE);  
                        
            RS232_RX_BUFFER_OVERFLOW=0; // Обнулим флаг переполнения приемного буфера RS232
            RS232_RX_BUFFER_INDEX=0;
            if(UART_Decode_Package((uint8*)buf1,RS232_RX_BUFFER_SIZE)==0) RS232_TX_BUILD_MESSAGE_PACKAGE(30); // Пакет битый
            free(buf1);
            }

если же динамический массив не использовать то проверка на валидность пакета проходит без проблем. Вот так работает:

Код

if(RS232_RX_BUFFER_OVERFLOW) {                        
            if(UART_Decode_Package((uint8*)RS232_RX_BUFFER,RS232_RX_BUFFER_SIZE)==0) RS232_TX_BUILD_MESSAGE_PACKAGE(30);
            RS232_RX_BUFFER_OVERFLOW=0; // Обнулим флаг переполнения приемного буфера RS232
            RS232_RX_BUFFER_INDEX=0;
            }

Вот обработчик пакета:

Код

uint8 UART_Decode_Package(uint8 *rs232_rx_buf,uint8 Len) {
    uint16 crc16;    

    crc16 = (uint16) CRC16((uint8*) rs232_rx_buf,Len-2);  

    if (crc16!=((((uint16) rs232_rx_buf[Len-2])<<8) | rs232_rx_buf[Len-1])) { // Если пришёл битый пакет
        return 0; // Контрольная сумма не прошла
        }
    .......
    return 1;
    }

Вот считалка контрольной суммы. Функция - табличная.

Код

uint16 CRC16(uint8 *data, uint16 len) {
    uint16 crc = 0xFFFF;
    while (len--)
        crc = (crc << 8) ^ Crc16Table[(crc >> 8) ^ *data++];
    return crc;
    }

В общем если кто может сказать почему у меня возникли проблемы при обработки динамич. массивов - заранее огромное спасибо!!!

P.S. Контроллер: AT90USB162, у него RAM 512 байт.

Сообщение отредактировал Halfback - Jun 7 2009, 12:12

[sergeeff]

Складывается ощущение, что вы должны уложиться со всеми этими копированиями-декодированием за время от момента возникновения сигнала overflow до прихода следующего символа по rs232 (не так уж много). Это так, или com порт у вас с fifo? В любом случае попробуйте на время обработки буфера запретить прерывания и посмотреть, есть ли разница.

[zltigo]

....у него RAM 512 байт.
......
//if (buf==0) break; // Тут надо придумать обработчик если памяти на буфер не дали

Когда придумаете , тогда и пишите программы с менеджерами памяти для контроллеров с 512B
Заодно всякую ненужную галиматью типа buf1 = memcpy() уберите. Ну а дальше пойдут времена, правильная работа с флагами, критичесими секциями....

[sergeeff]

Кстати о двойной буфферизации. А кто мешает второй буфер сделать статическим, если он уж очень нужен?

[Halfback]

sergeeff

Складывается ощущение, что вы должны уложиться со всеми этими копированиями-декодированием за время от момента возникновения сигнала overflow до прихода следующего символа по rs232 (не так уж много).

Пакеты с ПК я выдаю вручную. Так что копирование-перекодирование успевает 100 пудов.

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

Кстати о двойной буфферизации. А кто мешает второй буфер сделать статическим, если он уж очень нужен?

Ничего не мешает. Причем опытные железячные программисты так и советуют сделать (в случае избежания случая если ОЗУ не хватит, а если делать статически - то компилятор хотя бы выдаст ошибку переполнения ОЗУ) - но тем не менее не понятно почему так происходит. Еще одна причина - у меня не только буфер по УАРТу но и по другим интерфейсам - поэтому в теле main была идея использовать один динамический массив чем несколько статических под каждый буфер.

zltigo

Заодно всякую ненужную галиматью типа buf1 = memcpy() уберите.

Да, ну так расскажите где тут "галиматья"? Или знаете как по-другому и по-быстрее скопировать один массив в другой (при одинаковых размерах)?

правильная работа с флагами

работаю последовательно. так что пальцы гните перед другими!

Сообщение отредактировал Halfback - Jun 7 2009, 15:40

[zltigo]

Да, ну так расскажите где тут "галиматья"?

Галиматья специально отцитирована "buf1 =" она и есть родная.

работаю последовательно...

Да хоть зигзагами, только думать и обрабатывать ошибки возвращаемые malloc() по любому надо.

..так что пальцы гните перед другими!

[Halfback]

zltigo

обрабатывать ошибки возвращаемые malloc() по любому надо

согласен. но на тот момент обработчика не придумал.
malloc(), кстати, возращает одну ошибку - это 0.
щас напишу обработчик malloc() и посмотрю что он возвращает.

Дополнил код вот так:

Код

if(RS232_RX_BUFFER_OVERFLOW) {
            buf1 = (uint8*) malloc(RS232_RX_BUFFER_SIZE * sizeof(uint8)); // Сообразили 2-й буфер
            if(buf1==0) { // Тут надо придумать обработчик если памяти на буфер не дали
                RS232_TX_BUILD_MESSAGE_PACKAGE(99);
                }
            else {
                buf1 = (uint8*) memcpy((uint8*)buf1,(uint8*)RS232_RX_BUFFER,RS232_RX_BUFFER_SIZE);
                if(UART_Decode_Package((uint8*)buf1,RS232_RX_BUFFER_SIZE)==0) RS232_TX_BUILD_MESSAGE_PACKAGE(30);
                free(buf1);
                }                          
            RS232_RX_BUFFER_OVERFLOW=0; // Обнулим флаг переполнения приемного буфера RS232
            RS232_RX_BUFFER_INDEX=0;

По УАРТу когда отослал пакет в контроллер вернулся код 99. Т.е. malloc() память не выдел. При компиляции вот что выдается:
Bit variables area: 2h to 2h
Bit variables size: 1 byte(s)

Data Stack area: 100h to 17Fh
Data Stack size: 128 byte(s)
Estimated Data Stack usage: 42 byte(s)

RAM Global variables area: 180h to 1D4h
RAM Global variables size: 85 byte(s)

Hardware Stack area: 1D5h to 2FFh
Hardware Stack size: 299 byte(s)

Heap size: 0 byte(s)

EEPROM usage: 0 byte(s), 0,0% of EEPROM
Program size: 2927 words (5854 bytes), 35,7% of FLASH

Слабо вериться что в ОЗУ не нашлось куска в 10 байт.

Сообщение отредактировал Halfback - Jun 7 2009, 16:16

[sergeeff]

А куча (heap) вообще-то существует? И размер ее?

[Halfback]

sergeeff

А куча (heap) вообще-то существует? И размер ее?

не знаю что это такое но после компиляциии и линковки пишет что

Код

Heap size: 0 byte(s)

[zltigo]

malloc(), кстати, возращает одну ошибку - это 0.

Вообще-то он возвращает NULL, что в 'C' (void *)0.

щас напишу обработчик malloc() и посмотрю что он возвращает.

Это и так ясно было с самого начала.

buf1 = (uint8*) memcpy((uint8*)buf1,(uint8*)RS232_RX_BUFFER,RS232_RX_BUFFER_SIZE);

Ну и зачм по прежнему болтается это присвоение buf1 и ненужные письмена для явного преобразования buf1 и чего-то (зачем-то коcящего под макрос) к указателю на байт, хотя он buf1 сам по жизни такой, а аргументы memcpy() вообще универсальные void *

А куча (heap) вообще-то существует? И размер ее?

Написано-же, что не существует, как класс:

Heap size: 0 byte(s)

[sergeeff]

Раз не знаешь, что такое heap, не пользуйся функциями выделения/освобождения памяти или разберись с этим вопросом. Похоже, что динамический массив в данной задачи на фиг не нужен, как, впрочем, и двойная буферизация, особенно учитывая дефицит RAM.

[zltigo]

Раз не знаешь....

Ну все когда-то чего-то не знали... Динамическее выделение памяти во многих случаях весьма эффективно в том числе и для экономии памяти, однако делить остатки микроскопических 512 байт стандартым неуклюжим менеждером требующим и ресурсов и, что еще более неприятно, требующим явного резервировния хипа, сколее всего очень неудачная идея. При необдуманом использовании предстоит познакомится и со словом дефрагментация . Для микроскопических контроллеров в большинстве проще и много эффективнее размещать (при необходимости) динамические объекты в стеке. Ну недостаток, конечно, отсутствие штатных средств конроля, но зато минимум накладных и равноправный доступ к столь ограниченным ресурсам, как память.

[sergeeff]

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

[Halfback]

Жаль что тут никто реальным советом не помог. "Раз не знаешь - то мол не трогай" - это ко мне не относиться и к подобным высказываниям в свой адрес отношусь негативно т.к. не учился на домохозяку. А раз так то пришлось разобраться самому с этим heap.
Heap - как я понял почитав пару статей в инете - это и есть область памяти где работает malloc и смежные ей функции при динамическом распределении ОЗУ. Но чтобы было всё хорошо её надо определить в компоновщике. В своем компиляторе (CAVR) я ей (свалке) выделил 20 байт - и вуаля, всё заработало!!! malloc теперь NULL не возвращает. Другое мне не понятно - почему компилятор на счет примененного мной malloc() ничего не вякнул.

Код

Hardware Stack area: 1D5h to 2EBh
Hardware Stack size: 279 byte(s)

Heap area: 2ECh to 2FFh
Heap size: 20 byte(s)

Отсюда следует - что 20 байт компоновщик отнял от области памяти стека. ВОт это уже интересно!

Сообщение отредактировал Halfback - Jun 7 2009, 19:50

[zltigo]

Жаль что тут никто реальным советом не помог.

Вы так считаете . Тогда Вы зря чрезмерно дистанциируетесь от домохозяйки

Heap - как я понял почитав пару статей в инете ....

Другое мне не понятно - почему компилятор на счет примененного мной malloc() ничего не вякнул.

Потому, что Вы описали сегмент heap, хотя и нулевого размера. Уберите сегмент и будет вякать.

Но чтобы было всё хорошо её надо определить в компоновщике.

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

Отсюда следует - что 20 байт компоновщик отнял от области памяти стека. ВОт это уже интересно!

А Вы полагали, что он материализует их из окружающего пространства . 20 байтовый heap это точно профанация идеи, может создаваться ну разве только для нужд библиотечных функций типа time().

[singlskv]

то создает динамический массив того же размера что и RS232_RX_BUFFER и начинает его декодировать.P.S. Контроллер: AT90USB162, у него RAM 512 байт.

Забудьте как страшный сон попытки использовать динамическое распределение памяти на таких контроллерах,
это возможно только с памятью ~8Kб+ хотя я например и на 32Кб стараюсь все в статике распределить.

[defunct]

Забудьте как страшный сон попытки использовать динамическое распределение памяти на таких контроллерах,

Не стоит только этот один козий библиотечный malloc и встроенный heap ассоциировать со всем многообразием "динамического распределения" памяти.

Пусть есть некий пул состоящий из 5-ти буферов, объявленный статически:
TBUFFER pool[5];

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

надо только написать свои:
TBUFFER *pool_alloc();
pool_free( TBUFFER *);

[sergeeff]

Совершенно никакой разницы нет в том, как именно вы собираетесь выделить память под heap. А автору топика, вместо того, чтобы "накатывать" на форумчан, что "мало" помогают, неплохо было бы разобраться в том, как современные с/с++ компиляторы распределяют сегменты RAM для различных типов данных. А heap на 20 байт - это полная и бессмысленная фигня. Вы прикиньте, сколько места сожрали программы для ее обслуживания.

[SasaVitebsk]

А heap на 20 байт - это полная и бессмысленная фигня. Вы прикиньте, сколько места сожрали программы для ее обслуживания.

Кроме того, при использовании heap, у вас и озу было потрачено. При чём соотношение затрат к размеру кучи в % уже говорит в пользу отказа от такого подхода.
Даже в учебных целях, размер кучи (собственно выбор камня) неудачен.

В тоже время, это совершенно не значит, что для работы с динамической памятью нет места в однокристалках. Многие используют динамическую память. Есть кристаллы с 4/8/64к оперативки. Там это применимо. В одном случае я применял динамику в м88 (1к). Там, конечно, нет полной работы с кучей, а только выделение памяти и освобождение её всем куском, но всё-же.

[Dog Pawlowa]

В одном случае я применял динамику в м88 (1к). Там, конечно, нет полной работы с кучей, а только выделение памяти и освобождение её всем куском, но всё-же.

Ну, тогда по большому счету и запись переменных в union тоже можно назвать динамическим ну если не распределением, то использованием памяти.
Флаги занятости добавить - и гордое слово "распределение".

[SasaVitebsk]

Ну, тогда по большому счету ...

Нет там было честное выделение памяти. Работа с датчиками 1-ware. При соединении - выделялась память для датчика и туда заносился номер его. А вот удаление не по штучно, "а разом"
Ну так задача стояла. Никто по большому счёту не мешал и полному управлению с поштучным удалением и дефрагментацией. Не такие уж накладные расходы.

Например, по такому принципу, можно построить работу с таблетками или RFID картами.

[sergeeff]

На мой взгляд если говорить о динамической памяти, то она должна, как минимум поддерживать malloc/free.

[singlskv]

На мой взгляд если говорить о динамической памяти, то она должна, как минимум поддерживать malloc/free.

Я бы перефразировал это в что-нить типа:
... должна иметь эффективный алгоритм отведения/освобождения памяти для элементов РАЗНОГО размера.

[sergeeff]

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

[singlskv]

Эффективность алгоритма - дело десятое.

Под эффективностью я имел в виду не только скорость алгоритма но и то что под 5 байт не будет выделяться 100байт.
Такой "обобщенный" параметр сводящийся к общей эффективности решения.

[Rst7]

Под эффективностью я имел в виду не только скорость алгоритма но и то что под 5 байт не будет выделяться 100байт.

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

Код

DISABLE_INTERRUPTS();
result=*top;
*top=result->next;
ENABLE_INTERRUPTS();

и

Код

DISABLE_INTERRUPTS();
chunk->next=*top;
*top=chunk;
ENABLE_INTERRUPTS();

А остальная обвязка выполняется в незаблокированном состоянии.

[defunct]

... должна иметь эффективный алгоритм отведения/освобождения памяти для элементов РАЗНОГО размера.

Я бы не стал перефразировать и конкретизировать.
Динамическое распределение, как было сказано, - это возможность захватить и освободить ресурс - alloc/free.
Размеры это уже дело десятое.

Под эффективностью я имел в виду не только скорость алгоритма но и то что под 5 байт не будет выделяться 100байт.
Такой "обобщенный" параметр сводящийся к общей эффективности решения.

Если знаете что там всегда 5 байт, то выделите себе 5 байт статически.
А если не знаете сколько, то чем не устраивает брать по 100?

[Halfback]

мда, как говориться - начали за здравие и заканчиваем - за упокой.
Не надо на меня наговаривать что мол "гоню по чём зря" - как всегда народ тут отвечает общими фразами не предлагая никаких конкретных мыслей. Причем сопровождая "пальцевращением"

Поскольку malloc() аппаратно контроллером не поддерживается то создам статический буфер т.к. его размер и когда/кем будет использован знаю.
Вопрос на счет "материализовался": почему когда создается куча то память отбирается у области ОЗУ где Hardware Stack а не, скажем, у Data Stack ? Почему так?

[zltigo]

мда, как говориться - начали за здравие и заканчиваем - за упокой.
Не надо на меня наговаривать что мол "гоню по чём зря" - как всегда народ тут отвечает общими фразами не предлагая никаких конкретных мыслей. Причем сопровождая "пальцевращением"

Извиниться не хотите, перед теми, кто тратил на Вас свое время?

[Halfback]

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

[ReAl]

Поскольку malloc() аппаратно контроллером не поддерживается то создам статический буфер т.к. его размер и когда/кем будет использован знаю.

кстати, решение проблемы нашел сам

Сам?
Значит, этого так таки и не читали:

Кстати о двойной буфферизации. А кто мешает второй буфер сделать статическим, если он уж очень нужен?

Похоже, что динамический массив в данной задачи на фиг не нужен,

Забудьте как страшный сон попытки использовать динамическое распределение памяти на таких контроллерах, это возможно только с памятью ~8Kб+ хотя я например и на 32Кб стараюсь все в статике распределить.

Если знаете что там всегда 5 байт, то выделите себе 5 байт статически.

мдя...
Таки гоните. Причём нагло.

Вопрос на счет "материализовался": почему когда создается куча то память отбирается у области ОЗУ где Hardware Stack а не, скажем, у Data Stack ? Почему так?

Так навскидку - в используемом Вами инструментарии где-то задан размер стека данных. Стек данных просто пошёл на правах статически выделенного массива, а стеку управления было отдано всё, что осталось. После выделения памяти для кучи осталось меньше. Т.е. стек управления просто получает то, что осталось от всех остальных.

Только вот думаю - был ли смысл отвечать, если аффтар "не читатель, а писатель"? И опять заявит, что

Жаль что тут никто реальным советом не помог.

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

Только вот думаю - был ли смысл отвечать, если аффтар "не читатель, а писатель"?

Особенно понравилось у автора про аппаратную поддержку malloc()

[sergeeff]

Аппаратный malloc - это гениальная идея не менее гениального автора. Успехов вам, дорогой товарищ!

[SasaVitebsk]

На мой взгляд если говорить о динамической памяти, то она должна, как минимум поддерживать malloc/free.

Именно об этом мы и говорим. И я конкретно.
Только если мы говорим об AVR, то кроме этого практически ничего нет. То есть функциональность диспетчера нулевая. Если у меня будет "дырка", то он даже не вставит.
Именно по этому некоторые присутствующие писали свой диспетчер и приводили его фрагменты на форуме. Например, zltigo. Тоже себе ставлю такую задачу, но это длительная работа. Желательно оценить надёжность работы перед активным применением, а времени не хватает.

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

С точки зрения программы, если не один раз - то дальше без разницы - 2,3... Если речь о функциональности. А если о эффективности, - тогда дело другое.
Если рассматривать общий случай, то производительность системы будет падать, так как на работу с динамикой придётся затратить ресурсы. А вот с точки зрения эффективности потребления памяти - выигрыш может оказаться решающим.

Особенно очевидным, является применение динамики там, где размер объектов, помещаемых на кучу, имеет переменное значение.

Например станок с ЧПУ. Имеет 5 инструментов. Из внешнего источника подгружается прога с операциями. Операция может иметь много полей (одним сверлом - 10 отв). Я могу динамически размещать операцию и удалять по исполнению. А размещать для того, чтобы эффективней расчитать работу инструмента.

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

[sergeeff]

Именно об этом мы и говорим. И я конкретно.
Только если мы говорим об AVR, то кроме этого практически ничего нет. То есть функциональность диспетчера нулевая. Если у меня будет "дырка", то он даже не вставит.

Вы для интереса почитайте про такой аллокатор TLSF (http://rtportal.upv.es/rtmalloc/). Там проблемы "дырок" во многом решены и работает он шустро и эффективно. Для AVR можете попробовать портировать. Он целиком на С.

[singlskv]

Особенно очевидным, является применение динамики там, где размер объектов, помещаемых на кучу, имеет переменное значение.
Например станок с ЧПУ. Имеет 5 инструментов. Из внешнего источника подгружается прога с операциями. Операция может иметь много полей (одним сверлом - 10 отв). Я могу динамически размещать операцию и удалять по исполнению. А размещать для того, чтобы эффективней расчитать работу инструмента.

У Вас таки не динамическое распределение получается а нечто
очень похожее на оверлеи, а это совсем другая задачка и там все(ну почти все) можно заранее предусмотреть(в статике)

З.Ы. Собственно мое ИМХО заключается в том что это 2 совсем разные задачки
- распределение(и возврат) памяти(по требованию)
- распределение расположения данных в ранее распределенной памяти

и у каждого способа есть свои + и -
но для процов с маленькой памятью первого способа просто нет...

[sergeeff]

но для процов с маленькой памятью первого способа просто нет...

Так про это самое все и говорят, что не фиг придумывать себе проблемы, там где их нет.

[Halfback]

ReAl
гона тут не было. На тот момент времени проблема была решена размещением в ОЗУ "кучи". И имейте разницу понимать такие определения как "подсказка" и "решения". Подсказку дали, за что огромное спасибо, решение наковырял сам. Статический буферный массив был мной применем с самого начала но захотелось поэкспериментировать и для уменьшения используемой ОЗУ (так предполагалось) применить динамический - и цель создание темы - разобраться почему динамика не работала. Не высасывайте из пальца того, чего не было. Это нагло

Сергей Борщ крутите пальцем в другом месте. Если Вы не заметили - то тут раздел называется В помощь начинающему а не Раздел для профессионалов/гуру.

Аппаратный malloc - это гениальная идея не менее гениального автора. Успехов вам, дорогой товарищ!

Спасибо!!! И предлагаю на этом закончить!

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

Сергей Борщ крутите пальцем в другом месте. Если Вы не заметили - то тут раздел называется В помощь начинающему а не Раздел для профессионалов/гуру.

Даже начинающие должны подкреплять фактами свои утверждения. Итак, пожалуйста, приведите пример хоть одного процессора с аппаратной подержкой malloc(). Ну или хотя бы опишите функциональность этой самой аппаратной поддержки. Заметьте - вы это не спрашивали, вы утверждали. Поэтому ссылка на начинающих не катит. Утверждаете - отстаивайте свое утверждение, даже если вы и начинающий. В противном случае вы будете считаться балаболом.
Что мне писать в каком разделе - позвольте я буду решать сам. Или вы хотите, чтобы в разделе для начинающих ответы писали только начинающие?
P.S. и постарайтесь не использовать дворовый жаргон. Тут это не принято.

[ReAl]

На тот момент времени проблема была решена размещением в ОЗУ "кучи".

О! Так вот в чём была "ПРОБЛЕМА"!
Попытались жарить рыбу без рыбы, не вышло, народ повыяснял насчёт наличия рыбы (Вы сами не смогли проинтерпретировать выдачу используемого Вами компилятора)

А куча (heap) вообще-то существует? И размер ее?

Написано-же, что не существует, как класс:

Код

Heap size: 0 byte(s)

и Вы таки догадались посмотреть, где у Вас рыбу берут.

И имейте разницу понимать такие определения как "подсказка" и "решения". Подсказку дали, за что огромное спасибо, решение наковырял сам.

"огромное спасибо" появилсь только сейчас, до этого было, как раз в ответ на выяснение наличия места под кучу:

Жаль что тут никто реальным советом не помог.
...
В своем компиляторе (CAVR) я ей (свалке) выделил 20 байт - и вуаля, всё заработало!!!

Кстати, что Вы понимаете под "реальным советом" и "решением"?
"подведи мышку к такому-то пункту меню, войди на такую-то страничку, в таком-то поле ввода набери число 20, нажми кнопку ОК"?
Так, во первых, это и невозможно было сказать, так как до этого Вы не удосужились указать какой у Вас инмтрумент.
А во вторых - это даже не "для начинающих", это в детсад.
Начинающему должно было хватить вопроса "а куча-то выделена?" - и хватило, не спорю, так не опускайте же сами себя до более низкого уровня!

[SasaVitebsk]

У Вас таки не динамическое распределение получается а нечто
очень похожее на оверлеи, а это совсем другая задачка и там все(ну почти все) можно заранее предусмотреть(в статике)

Нет ну вы не совсем меня поняли. Я применил слово "программа", в смысле программа для станка с ЧПУ. То есть там, к примеру, координаты отверстия занесены. Это я так условно задачу привёл.
Никто не будет в станок ЧПУ передавать прогу на AVR для запуска оверлея.
Это уж через чур.

З.Ы. Собственно мое ИМХО заключается в том что это 2 совсем разные задачки
- распределение(и возврат) памяти(по требованию)
- распределение расположения данных в ранее распределенной памяти

и у каждого способа есть свои + и -
но для процов с маленькой памятью первого способа просто нет...

Где граница "малой памяти"? В одном моём проекте на м640 используется куча 5.8 кб. И применить там другое решение даже себе не представляю.

[ReAl]

Где граница "малой памяти"? В одном моём проекте на м640 используется куча 5.8 кб. И применить там другое решение даже себе не представляю.

Дык понятное дело - по задаче надо смотреть и головой думать. Вот выделение/освобождение буфера фиксированного размера из пула буферов, как тут сказано, было частью ОС iDCX-51, которая вообще в 192 байтах ОЗУ в i8044 жила.

[_Pasha]

Дык понятное дело - по задаче надо смотреть и головой думать.

+1 Можно все навороты свести к функциям memavail(), maxavail() и defrag(void **ptr, size_t size) и пущай в тексте будет явно указано, какие указатели подлежат "перетрахиванию", а какие и трогать не надо. И с ограничением времени исполнения сего действа.

[SasaVitebsk]

Дык понятное дело - по задаче надо смотреть и головой думать. Вот выделение/освобождение буфера фиксированного размера из пула буферов, как тут сказано, было частью ОС iDCX-51, которая вообще в 192 байтах ОЗУ в i8044 жила.

Вот о том и речь. Есть инструмент - можно им пользоваться. Но надо умело им пользоваться. И не фиг на зеркало пенять, когда рожа крива. (Это безотносительно к выступавшим)