IAR + SAM7S, Как узнать размер свободной SRAM? Опции

[KAlex]

Есть проект, в котором надо динамически выделять под массив данных область в памяти. Желательно как можно большего размера.
Как на стадии компиляции узнать размер свободной SRAM?
Возможно ли определить это в уже работающей программе?

[zltigo]

Возможно ли определить это в уже работающей программе?

А в чем проблемы - начальный адрес Вашего массива Вам известен. Размер RAM у контроллера тоже.
Вычесть из второго первое .

[KAlex]

А в чем проблемы - начальный адрес Вашего массива Вам известен.

Неизвестен, в этом то и вопрос.

[zltigo]

Неизвестен, в этом то и вопрос.

Ерунду какую-то сказали если есть обьект, то естественно во время исполнения у него есть адрес.
Для Вашего случая заводите сегмент (можете в нем и какой-нибудь минимальный массивчик завести), линкуете его в конец. Адрес сегмента (или массива известен) размер RAM тоже. Все.

[KAlex]

Для Вашего случая заводите сегмент (можете в нем и какой-нибудь минимальный массивчик завести), линкуете его в конец.

А как сказать IAR-у, что этот массив надо линковать последним. Я с этим ни разу не сталкивался.

[zltigo]

А как сказать IAR-у, что этот массив надо линковать последним.

Явно указав его имя в списке для линкера последним. Конкретика зависит от версии IAR - у 4.x и 5.x линкеры разные.
Если 4.x то например в XCL файле добавляем:

Код

-D_HEAP_RTOS_SIZE=1000  // 4Kb - Dummy minimal space for My Memory Manager
-Z(DATA)HEAP_RTOS+_HEAP_RTOS_SIZE=RAMSTART-RAMEND     // For My memory manager

Ну а дальше:

Код

extern ulong RAMEND;
extern ulong RAMSTART;
#pragma segment="HEAP_RTOS"

    printf( "\tRAM use:%lu Heap:%8X Size:%lu\r",
                                 (ulong)(__segment_begin( "HEAP_RTOS" ))-(ulong)&RAMSTART,
                                 __segment_begin( "HEAP_RTOS" ),
                                (ulong)&RAMEND - (ulong)(__segment_begin( "HEAP_RTOS" )) + 1 );

[Kitsok]

zltigo

А вот немного не в тему.

Есть девайс на SAM7, общающийся через USB с хостом, и хочется сделать через тот-же интерфейс сделать обновление прошивки.

Приложение работает под FreeRTOS.
Так вот идея такая:
Получаем по USB команду на апгрейд прошивки, получаем собственно прошивку, запрещаем наглухо прерывания, копируем прошивку в heap, в heap-же копируем функцию записи во флеш, делаем необходимые проверки и передаем управление на эту функцию.

Криво или можно так сделать?

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

копируем прошивку в heap, в heap-же копируем функцию записи во флеш, делаем необходимые проверки и передаем управление на эту функцию.

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

[Kitsok]

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

Спасибо за ссылку, почитаю.

С опасением полностью согласен.
Причина, по которой я не горю желанием писать полноценный бутлоадер (для поиска: загрузчик, bootloader, бутлодырь ) - необходимо реализовать весь стек USB - других интерфейсов у устройства попросту нет...

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

необходимо реализовать весь стек USB - других интерфейсов у устройства попросту нет...

А ОЗУ внешнее? Внутреннего-то не хватит, чтобы всю прошивку в heap поместить. Для прошивки достаточно держать в ОЗУ функцию из нескольких команд

Код

__ramfunc __arm void FlashCommand_RAM(uint32_t command)
{
    AT91C_BASE_MC->MC_FCR = command;
    while(!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY));
}

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

[Kitsok]

А ОЗУ внешнее? Внутреннего-то не хватит, чтобы всю прошивку в heap поместить. Для прошивки достаточно держать в ОЗУ функцию из нескольких команд

Код

__ramfunc __arm void FlashCommand_RAM(uint32_t command)
{
    AT91C_BASE_MC->MC_FCR = command;
    while(!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY));
}

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

ОЗУ встроенное, SAM7S256, но прошивка ограничивается размером в 16 кб, больше мне и не надо.

Рассматриваю возможность дописывания аппликухи и организации dual firmware.

А вот глупый вопрос - можно ли работая из флеша писать другие сектора этого флеша, или обязательно копировать себя в RAM и запускаться оттуда?

Потому как если можно, то изменения будут касаться исключительно проверки версии и CRC с дальнейшей передачей управления.

Хотя криво это все, по-хорошему, надо бутлоадер писать а-ля SAM-BA и не выпендриваться.

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

А вот глупый вопрос - можно ли работая из флеша писать другие сектора этого флеша, или обязательно копировать себя в RAM и запускаться оттуда?

Все, кроме приведенной мной выше функции может работать из флеша. На время выполнения этой функции флеш блокируется (поэтому либо запрещайте прерывания, либо переносите обработчики и вектора в ОЗУ).

Хотя криво это все, по-хорошему, надо бутлоадер писать а-ля SAM-BA и не выпендриваться.

Тем более что в USB есть (специальный класс?) возможность загрузки firmware. У атмела в апликухах кажется что-то было. Может и не так страшно?