Отправлено Jolik 01 декабря 2004 г. 03:53

может тоже руки кривые? Но...
Пишу:

unsigned char *databuf;

main
{
...
databuf = (unsigned char*) сalloc(DATA_SIZE, sizeof(char));
...
}

CMD файл проекта
-------------------------------------------------------------------
MEMORY
{
PAGE 0:

/* MMR : origin = 0000000h, length = 00000c0h
SPRAM : origin = 00000c0h, length = 0000040h */
VECS : origin = 0000300h, length = 0000100h
DARAM0 : origin = 0000500h, length = 0003B00h
DARAM1 : origin = 0004000h, length = 0004000h
DARAM2 : origin = 0008000h, length = 0004000h
DARAM3 : origin = 000c000h, length = 0004000h

SARAM0 : origin = 0010000h, length = 0004000h
SARAM1 : origin = 0014000h, length = 000C000h
/* SARAM2 : origin = 0018000h, length = 0004000h
SARAM3 : origin = 001c000h, length = 0004000h */
SARAM4 : origin = 0020000h, length = 000C000h
/* SARAM5 : origin = 0024000h, length = 0004000h
SARAM6 : origin = 0028000h, length = 0004000h */
SARAM7 : origin = 002c000h, length = 000F000h
/* SARAM8 : origin = 0030000h, length = 0004000h
SARAM9 : origin = 0034000h, length = 0004000h
SARAM10 : origin = 0038000h, length = 0004000h */
SARAM11 : origin = 003c000h, length = 0004000h
SARAM12 : origin = 0040000h, length = 0004000h
SARAM13 : origin = 0044000h, length = 0004000h
SARAM14 : origin = 0048000h, length = 0004000h
SARAM15 : origin = 004c000h, length = 0004000h

CE0 : origin = 0050000h, length = 03b0000h
CE1 : origin = 0400000h, length = 0400000h
CE2 : origin = 0800000h, length = 0400000h
CE3 : origin = 0c00000h, length = 03f8000h

PDROM : origin = 0ff8000h, length = 07f00h
/* VECS : origin = 0ffff00h, length = 00100h */ /* reset vector */
}

SECTIONS
{
.vectors : {} > VECS PAGE 0 /* interrupt vector table */
.cinit : {} > SARAM0 PAGE 0
.text : {} > SARAM1 PAGE 0
.bss : {} > SARAM4 PAGE 0

.stack : {} > DARAM1 PAGE 0
.sysstack: {} > DARAM1 PAGE 0
/* .sysmem : {} > DARAM2 PAGE 0 */
.sysmem : {} > SARAM7 PAGE 0
.cio : {} > DARAM3 PAGE 0
.data : {} > DARAM3 PAGE 0
.const : {} > DARAM3 PAGE 0

.csldata : {} > DARAM0 PAGE 0
/* dmaMem : {} > DARAM0 PAGE 0 */
}
---------------------------------------------------------------------

Компилятор размещает databuf в DARAM1 - на месте стеков!!!
В другом месте программы тот же код размещает нормально память в .sysmem.
Объясните - глюк это, или я что-то не то делаю?
В результате пришлось сделать

unsigned char databuf[DATA_SIZE];
Только после этого заработало...

• Как вариант:-) — -=ВН=-   (01.12.2004 19:53, 569 байт)
  • модель large - похоже глюк в реализации... Ведь в другом модуле работает calloc-же... — Jolik   (02.12.2004 11:52, пустое)
• Вообще, возможен банальный баг. — st256   (01.12.2004 19:01, 373 байт)
• Все четко - локальная переменная (в твоем случае указатель на буфер) размещается в стеке. Не боись - по сравнению с размером буфера, размер указателя для стека не страшен ;) — Harbour   (01.12.2004 09:22, пустое)
  • Я конечно проверю еще раз... — Jolik   (01.12.2004 10:42, 357 байт)
    • ;) Все могет быть - тогда следует внимательно почитать про alloc стратегию для CCS реализации динамической памяти, хотя как уже совершенно справедливо замечено в треде, аллоки на embdded платформах это обычно распальцовка. — Harbour   (01.12.2004 11:15, пустое)
    • Кстати, меня давно мучает вопрос - а зачем вообще использовать динамически выделяемую память? В каких случаях это может быть оправдано? Никак не могу сконструировать пример. Ну для Windows-программирования понятно, а для TMS-платформы? Это ж еще ко всему прочему надо лезть в библиотечные исходники, посмотреть, чего там все это маллоки\каллоки\фрее творят. Статический раз и навсегда определенный буфер куда как более удобно... — GRD   (01.12.2004 11:04, пустое)
      • Да, связанные списки... Придеца че-та придумывать... — Jolik   (01.12.2004 12:03, 331 байт)
        • Ответ: (+) — Harbour   (01.12.2004 13:24, 265 байт)
        • Нечего делать в техасовских библиотеках:-) — -=ВН=-   (01.12.2004 13:02, пустое)
        • Да нечего придумывать (+) — SM   (01.12.2004 12:23, 118 байт)
          • Забыл, а у Техасов разве хип может попасть в секцию? Разве это не то, что после этих секций остается? — st256   (01.12.2004 18:51, пустое)
          • ну куча то в sysmem по умолчанию? И как он ее может толкнуть, зная что там стек? (причем память такого размера затерла оба стека ) — Jolik   (01.12.2004 14:29, пустое)
            • Опять боюсь наврать из-за долгого отсутствия отношений с TI, но как раз не в system, а в совершенно отдельном месте. Вне секций. — st256   (01.12.2004 19:03, пустое)
      • Да вот пришлось мне (+) — SM   (01.12.2004 11:41, 359 байт)
        • И все-тки мое эстетическое чувство страдает. Да и руками как-то спокойнее. Тем более, что если я буду делать разные манипуляции со статически расположенным массивом, то это тоже можно гордо назвать собственным менеджером кучи :) — GRD   (01.12.2004 15:11, пустое)
          • Руками не всегда удобно, да и затруднительно бывает. — -=ВН=-   (01.12.2004 17:35, 3011 байт)
            • Посмотреть, как другие делают, никогда не помешает(+) — GRD   (01.12.2004 18:35, 742 байт)
              • Так это ж хорошо, что довольный сидите:-) — -=ВН=-   (01.12.2004 18:49, 468 байт)
                • Короче, консенсус :) — GRD   (01.12.2004 18:52, пустое)
        • Ага, я тоже делал такую штуку:-) — -=ВН=-   (01.12.2004 12:58, 116 байт)
• Да, кстати, это все происходит на CCS... — Jolik   (01.12.2004 03:54, пустое)