Освоение ARM контроллеров Опции

[maxntf]

Появилась необходимость в освоении ARM контроллеров.
Есть проект реализованный на PIC контроллере, который необходимо портировать на ARM. Это связано с тем, что в него нужно доработать реализацию воспроизведения аудио файлов.
Просьба помочь в выборе контроллера и отладочных средств к нему для изучения ARM, с учетом моих задач. Просто не хочется брать первую попавшеюся отладочную плату с установленным в нее контроллером. А выбрать тот набор оборудования и ПО, который поможет мне в изучении ARM и параллельно реализовать все мои задачи.
Основные параметры основываясь на старый проект:
1) Объем памяти программ не меньше 128kB.
2) Объем памяти данных не меньше 4kB. Учитывая что в старом проекте используется внешняя EEPROM для хранения параметров на 64kB, а в новом проекте еще и нужно хранить аудио треки. И насколько я успел поверхностно ознакомится, в ARM можно использовать внешнюю flash память и для памяти данных контроллера и для хранения треков и параметров. Если я прав, то тогда ARM можно брать вообще без внутреннего ОЗУ.
3) Большое количество портов. В старом проекте был PIC на 80 ног.
4) Нужно 17 АЦП для измерения напряжения, остальные GPIO.
5) 2 порта UART.
6) Желательно USB.
7) И самое главное возможность проиграть аудио ролики (не важно в каком формате хоть в “amr”) в аудио тракт GSM модема. Эти ролики будут подготовлены на ПК и записываться в цифровом формате во внешнюю flash (то есть никаких кодеков для записи аудио не нужно).
Есть под ARM готовые библиотеки для воспроизведения аудио файлов?
В качестве среды разработки хочу взять CooCox CoIDE (GCC Compiler) в виду того что она бесплатная. Вроде неплохие отзывы о ней. Кстати кто знает, в ней есть ОС под ARM.
ARM контроллер и отладочный комплект ST или NuVotone. Лучше ST так как на мой взгляд они наиболее популярны, а по второму производителю маловато информации в сети.
Заранее благодарен за любую помощь.

[maxntf]

Подключил FreeRTOS, пока практически пустой проект 3 задачи для теста - 1-я контроль кнопки, 2-я передача строки "Hello World" в UART и 3-я мигание индикаторами.
Хотя в FreeRTOSConfig.h и стоит #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 75 * 1024 ) ) , но в SRAM забрало очень много места, почти 60% всей ОЗУ.

Program Size:
12440 28 79288 91756 1666c main.elf
text data bss dec hex filename

Подскажите почему так? Смотрел в map файле я так понимаю что все жрет heap_2.c

*fill* 0x200001aa 0x6
.bss 0x200001b0 0x12c14 ..\obj\heap_2.o
*(COMMON)
COMMON 0x20012dc4 0xe ..\obj\main.o

[zltigo]

Смотрел в map файле я так понимаю что все жрет heap_2.c

Вообще в идеале heap должен занимать ВООБЩЕ ВСЮ свободную память. Посему любые константные дефиниции его размера в корне порочны. Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера.

[jcxz]

Вообще в идеале heap должен занимать ВООБЩЕ ВСЮ свободную память. Посему любые константные дефиниции его размера в корне порочны. Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера.

ЗАЧЕМ??? ...если куча не нужна и не используется нигде в проекте.
Во всех моих проектах размер кучи задан ==0 в конфигурационном файле компоновщика.
У меня везде так (для IAR):

Код

define block CSTACK with alignment = 8, size = 0x000 {};
define block HEAP   with alignment = 8, size = 0x000 {};

А далее:

Код

do not initialize  {section .bssStk};
do not initialize  {section .bssStkMain};
...
place in RAM_regionA {section .BITBAND_RAM, section .dma, section .ethernet};
place in RAM_regionA {rw, first block CSTACK, section .bssMemNoFill, block HEAP};

Стеки задач, основной стек (который указан в reset-векторе) и стек исключений определены подобно:

Код

#pragma data_alignment = 8
__no_init static OS_STK taskADEStk[64 + STK_SIZE_ISR_NFP] @ ".bssStk";

Иногда я объединяю все стеки (задач, основной стек и стек исключений) в единый сплошной блок через define block.
Имхо: определять размеры стеков в си-шных файлах гораздо удобнее, чем в едином конфигурационном файле компоновщика.

PS: Контролировать размер стеков конечно нужно. И выделять под них память, а не надеяться что "что-то не налезет на что-то".

[zltigo]

ЗАЧЕМ??? ...если куча не нужна и не используется нигде в проекте.

Ну вообще-то, совершенно очевидно, речь идет о случае, когда куча используется.

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

Чем? Есть одно место, где описаны все размеры блоков памяти конкретного проекта. Заходишь и смотришь, а не надо ползать искать. Когда пишутся, например, всякие демки на 999 вариантов, тогда в них приходится выносить и размазывать настройки по файлам и ключам. Но для конкретного проекта зачем?

[jcxz]

Чем? Есть одно место, где описаны все размеры блоков памяти конкретного проекта. Заходишь и смотришь, а не надо ползать искать. Когда пишутся, например, всякие демки на 999 вариантов, тогда в них приходится выносить и размазывать настройки по файлам и ключам. Но для конкретного проекта зачем?

Есть задача, у неё свой стек. Все переменные, дефайны этой задачи - в её файлах. Проект состоит из множества таких задач. Естественно что данные, нужные локально только данной задаче, должны быть локальны (описаны именно в её файлах, а не вкаком-то едином файле). А стек - это локальная сущность конкретной задачи. И размер его скорее зависит от данной задачи, а не от проекта в целом.
Или Вы и локальные переменные каждой задачи тоже в едином файле определяете?

[zltigo]

Есть задача, у неё свой стек.

Не передергивайте! Речь идет о статически распределяемой памяти.
Но, если-бы я с какого-то бодуна выделял стеки задачам статически, то, да и эти БЛОКИ памяти я бы ТОЖЕ описал под линкер, что-бы видеть общую картину в одном месте и сразу при проектировании, а не тогда, кода линкер выругается при линковке что памяти совсем нет. После чего придется ползать по куче файлов и думать где жертвовать.

А стек - это локальная сущность конкретной задачи.

Содержимое стека - несомненно. Но сам стек, как блок памяти, это уже элемент ВЕРХНЕГО, надзадачного уровня. Вот и его выделением и размещением занимается НЕ задача.

Или Вы и локальные переменные каждой задачи тоже в едином файле определяете?

К чему эта дурацкая фраза и усмешка?

[jcxz]

Вот и его выделением и размещением занимается НЕ задача.

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

Без комментариев, ибо рожденный ползать понять "лишнего" не может

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