Может знаковость char виновата?

Рекомендую выводить шрифты сразу на экран и не пихать в память

Микроконтроллеры - это секс там где ты его совсем не ожидаешь.

Вообще для stm32 справедливо вот что -

declaring them const does not force the compiler to put it in FLASH

Что значит что конст просто гарантирует что твои данные не будут созданы в рандомном месте и не должны создавать лишней фрагментации.Но они будут жрать память, да. Рекомендую проверить свой шрифт на чистом проекте где точно не будет ничего влиять на его работу. А так особо ничего посоветовать кроме этого не могу, писал только под xtensa lx106 и avr.

С чего ты взял, что массив виноват? Смотри, как у тебя в ld-скрипте память распределена. Ну и как malloc работает.

А вообще, не понимаю: на кой черт тебе malloc на микроконтроллере? Что за прикол такой?

Но они будут жрать память, да.

Чушь. Возьми это, сделай make list и посмотри, где будут переменные, обозванные const. Все они будут во флеше!!!

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

на одном маллоке

На эмбеддеде? Маллок? Мсье хочет лютой, бешеной фрагментации после 2-3х вызовов?

на гуглинге

Мог бы сразу результаты того гуглинга привести:

https://mcuoneclipse.com/2012/11/01/defining-variables-at-absolute-addresses-...

http://stackoverflow.com/questions/4962788/storing-structs-in-rom-on-arm-device

Проверь куда линкер тебе распихивает стек, кучу и rodata.

Если памяти с запасом, приличный аллокатор и не требуется жёсткий реалтайм - то ничего особо страшного.

А вообще, если хочешь чтобы у тебя что-то лежало именно там где надо, то лучше класть в отдельную секцию. Компилятор может и в RAM положить.

Всего прожка выходит в 130кб из 512кб.

512 кб у него памяти. Покажи приличный аллокатор, который не начнет жрать 2^X после пары аллокаций.

FreeRTOS'овский heap_4?

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

Что за треш с отступами в сорцах?

	ETS_INTR_LOCK();
	{
		/* If this is the first call to malloc then the heap will require
		initialisation to setup the list of free blocks. */
		if( pxEnd == NULL )
		{
			prvHeapInit();
		}

			if( xWantedSize > 0 )
			{
				xWantedSize = xPortWantedSizeAlign(xWantedSize);
			}

			if( ( xWantedSize > 0 ) && ( xWantedSize < xFreeBytesRemaining ) )
			{

Is very simple and allocated memory from a statically allocated array,

бгг.

смотри выравнивание массивов, в первую очередь доступ по uint16_t* и uint32_t* к нечетным адресам

Хммм, я подозревал это.

Ну ладненько, тогда тупо укажу область флэши для массивов в скрипте линкера.

Конечно маллок. Современная ембед разработка мало чем отличается от комповой. Как по задачам, которые ставят разработчику, так и инструментами.

И как прикажете тут прожить без маллока? Когда приборчик, например, должен иметь несколько режимов работы с разными объёмами данных и датчиков. К тому же вот с чем, с чем, а с маллоком проблем у меня никогда не было. Да, этот Фриртосовский хип_4 работает как часы.

бгг.

Это ж heap_1.

Просто таб бывает 4х пробельный.

В стмках с этим проблем нет - всё происходит хардварно, хоть в 2 раза и дольше по времени.

И как прикажете тут прожить без маллока? Когда приборчик, например, должен иметь несколько режимов работы с разными объёмами данных и датчиков.

Да тупо заводишь пул для своих данных и в них выделяешь память. Каждому типу данных (данные, обработчики датчиков и т.п.) свой пул. Как в lwip есть массив memp_pools структур memp_desc, и для этого массива функции memp_alloc и memp_free. Хотя по сути получается, что ты пишешь свой аллокатор.

А причем тут таб вообще если их там нет? Код с гитхаба, табы тут могли повлиять только если они в пределах одного файла разного размера.

Пардон, но все равно веселые ребята:

void *pvPortRealloc(void *mem, size_t newsize)
{
    if (newsize == 0) {
        vPortFree(mem);
        return NULL;
    }

    void *p;
    p = pvPortMalloc(newsize);
    if (p) {
        /* zero the memory */
        if (mem != NULL) {
            memcpy(p, mem, newsize);
            vPortFree(mem);
        }
    }
    return p;
}

Проверять соседний блок, расширить текущий без реаллокации... Пффф... Можно же тупо выделить ВТОРОЙ МАССИВ ОДНОВРЕМЕННО С ПЕРВЫМ, скопировать и убить первый. Т.е. realloc зафейлится если попытаться расширить блок в половину от занимаемой памяти.

Как же нету, если есть: http://i.imgur.com/CFLWrv1.png

С табом, длинной в 4 пробела было бы как раз.

если они в пределах одного файла разного размера.

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

ах, увидел.

Ну возможн кто-то недоглядел, а потом отдельный коммит для этого делать лень.

Т.е. realloc зафейлится если попытаться расширить блок в половину от занимаемой памяти

то тебе маллок в эмбедде не по нраву, то тебе реаллок подавай. нытик

Ну если делать обертку над статик массивом то делать нормально, а не этот пиздец.