LPC2103+FreeRTOS, проблемы malloc в libc библе CrossWork Опции

[klen]

Всем привет.
Засунул FreeRTOS в LPC2103. Первый раз не пришлось придумывать и обосновывать зачем я вставляю ОС в контроллер. Всетаки в природе попадаются такие задачи для микроконтроллеров...
Протрахался два дня c одной проблемкой. Была проблема с выделением памяти при инициализации задач и очередей. Вернее при выделении проблем не было - функция malloc исправно выдает указатели и тд. Но при некоторых вызовах, например
pbRes = xQueueSend(qhTwi_0_SignaledQueue, &pbTmp , portMAX_DELAY );
возвращался вместо результата 1 или 0 число позначение равное адресам попадавшим в кучу, стеки режимов процессора и тд. Тоест есть похоже чтото на чтото залазило. После такой ситуации есессено PAbort или DAbort.
Прикол в том что допишеш строку кода в какомнибудь любом модуле - работает, допишеш еще - глючит, и все в таком духе, закономерности поведения я не уловил.
Разгодать причину не получилось (стеки заведомо больше задавались чем нада - проверял ручным счетом, также при ручном выделении стало все работать безошибочно без изменения размеров). Поэтому взял попробывал ручное управление кучей а malloc из libc от CrossWork был послан нах, освобождение памяти мне не требуется, поэтому ручное выделение както проше, меньше жрет и так сказать я тут все регулирую.

Где проблема? я чето не понял как чтото работает или всетаки malloc у CrossWork кривой. Локально задачка решена, но не дает покоя вопрос ПОЧЕМУ? вдруг это почему вылезет потом в другом месте.

Сообщение отредактировал klen - Aug 18 2006, 04:33

[zltigo]

Где проблема?

Несколько сумбурно все изложено :-(. Собственно не совсем понятно из чего сделан вывод о проблеме именно с malloc(). Что такое "ручное выделение"?
Воообще-то я широко пользуюсь менеджером памяти по мотивам FreeRTOSсовского heap_2.c - изменено только статическое назначение размера heap - под heap выделяется вся оставшаяся память.
Может все проще? И нужно пользоваться, например, xQueueSendFromISR в том конкретном случае или
какая-то другая "промашка"?

[klen]

Может все проще? И нужно пользоваться, например, xQueueSendFromISR в том конкретном случае или
какая-то другая "промашка"?

Вы издеваетесь? это я про xQueueSendFromISR/xQueueSend.
Почему именно malloc ? а как тогда обяснить что при при heap_3.c (тоесть malloc из libc) проглюкавыет, а с heap_2.c работает как часики.
Я имел ввиду под ручным все то что не heap_3.c, тоесть не использует malloc из libc и соответственно секцию .heap . Заработало стабильно как раз после heap_2.c + немного напильником.
А как вы автоматом размер ручной кучи(остаток озу) в исходнике берете?

2_RRaptor
А это ИДЕЯ!! Ведь и вправду если хоть гдето в объектниках сохраняется константа-указатель на начало кучи то перекомпиляция другого модуля автоматом все двигает по озу, и получается каша, но с другой стороны этого вроде как не бывает - все абсолютные адреса после компиляния в линкере вычислюется и подставляются . Есть вариант что CW проглюкивает при генерации линковочного скрипта (относительно кучи) опятьже при не полной соборке. Поскольку при "ручном" выделении куча в понимании линкера уэже не секция кучи а просто данные-массив байт, то и глюков нет/другие

Еще вопрос до кучи.
Как правильно сказать компиллеру/линкеру GCC в CW засунуть функцию в ОЗУ.
... *Foo(...) __attribute__ ((section(".data_run"))) ;
... *Foo(...)
{....}
помогает, она размещается в ОЗУ, но код в ней кривой как коленвал.
И еще, допустим я засунул функцию в ОЗУ, но она дергает вызовы счета float, как указать чтоб из не моей библы конкретные только конкретные вызовы тоже в ОЗУ положить?

Сообщение отредактировал klen - Aug 18 2006, 08:48